Good interview questions for developers do not come only from clever questioning, but from good interview questions for developers based on a work sample. This text is aimed at engineering leads and team leads who interview developers and want to separate technical substance from self-presentation.
Questions alone are often not enough when answers sound polished but are not grounded in real work. A work sample makes the conversation more concrete, comparable and traceable than a CV, self-description or isolated claims. If you want to assess competence remotely, you need more than standard questions.
What follows covers a practical interview structure, specific types of questions and clear criteria that help you assess answers against real work more effectively.
Why good interview questions often fall short without a work sample
Many developer interviews fail not because there are too few questions, but because the questions are too general. Someone who can explain terms, processes and architectural principles well will quickly come across as convincing. But that still does not automatically show how that person actually works, prioritises, tests or deals with risks.
Standard questions often reward three things above all:
- verbal confidence
- good preparation
- familiarity with the interview setting
That is not worthless, but it is something different from reliable evidence of real contributions in day-to-day development work. This is exactly where a work sample changes the framework of the conversation. Instead of talking about hypothetical situations, you talk about specific commits, decisions, tests, dependencies or pull requests over time.
That does not make good interview questions harder, but more precise: What was built? Why was it solved in exactly that way? Which risks were known? What was deliberately not implemented? What role did the person themselves play? Topics such as unit tests in context or the quality of reviews in the process can also be assessed far more concretely this way.
For interviewers, this means less gut feeling and more traceable examples. A work sample does not have to be an isolated algorithm test. Real development work is usually easier to see when the context in which it emerged is also visible. If you want to explore further how competence can be assessed without relying purely on self-reporting, you will find additional thoughts on this in the guide on assessing competence remotely.
How to build a developer interview around real work
A robust developer interview does not need complicated staging. In most cases, a clear sequence with four blocks is enough: first understand the context of the work sample, then discuss technical decisions, then assess quality and risks, and finally examine responsibility and ability to learn.
In the first block, you open up the frame. Useful questions include:
- What problem needed to be solved?
- What exactly was your role in it?
- What business or technical constraints were there?
- How was success measured in this case?
Then move on to decisions. This is where it becomes clear whether someone is only describing an outcome or can explain the path that led to it. Ask why this architecture was chosen, what alternatives were considered and where trade-offs between speed, maintainability and complexity were necessary. Especially now, when there is so much discussion about tools, AI assistance or real work behind output, the reasoning matters more than the buzzword.
In the third block, you assess quality indirectly. Talk about tests, defect detection, dependencies, reviews and changes after merge. Pull requests and review histories are often helpful here because they make thinking, communication and iteration visible. A look at the Proof Engine methodology can also help sharpen your focus on authorship, security aspects and the development process.
Finally, the discussion turns to ownership: What was your own contribution, which parts came from others, and what would you do differently today? Good interview questions need follow-up questions here. It is only when you dig deeper that it becomes clear whether decisions were really understood, made independently or merely observed. So assess answers not only for correctness, but also for clarity, prioritisation and awareness of the problem. It can also be useful to interpret evidence properly from a free repo audit for developers, verification for companies, the pricing model without a subscription, employment references by comparison or prompt engineering in everyday work.
Which interview questions really help when using a work sample
A conversation about a work sample becomes useful when the questions are not mixed together at random, but organised by topic. That way, you are not only assessing knowledge, but also contribution, way of working and judgement through real traces in the work.
1. Authorship and contribution Start by asking about the candidate’s own share of the work. Who initiated the change? Which parts did they implement themselves, and which were done jointly or by others? How can their own signature be seen through commits, reviews or follow-up changes?
2. How the code came about Then it is worth looking at the progression. Did the solution grow step by step, or were larger blocks introduced all at once? What does that say about the working process, team coordination and the risk of misunderstandings or blind spots?
3. Business impact Then talk about impact rather than just implementation. What problem was actually solved? What consequences did the change have for users, the product or the team? How were priorities set when not everything could be done at once?
4. Security and care Questions about security often show how seriously someone takes responsibility. How were secrets handled? Why were particular libraries chosen? Were there known vulnerabilities, risky configurations or places where safeguards were deliberately put in place?
5. Tests and safeguards Here the issue is not only whether testing happened, but how. What types of tests were in place? Which gaps were consciously accepted? How was it decided what was sufficiently covered and where residual uncertainty remained?
6. Tech stack and consequences The choice of tools also says a great deal. Why was this framework, this language or this infrastructure chosen? What consequences did that have for maintenance, complexity and performance?
7. Reflection and learning Finally, you should target the ability to learn. Which decision would be made differently today? What was learned from mistakes, near-incidents or review feedback? These answers in particular often show whether someone sees development as delivery or as responsibility.
How to assess answers on work samples fairly and reliably
Fairness in an interview does not mean asking everyone the same trivia questions. A conversation becomes fair when you apply the same assessment criteria to comparable evidence. Someone from a small product team will bring different examples from someone in a heavily regulated platform environment. What matters is not identical career paths, but consistency of criteria.
Define these criteria before the interview. Useful examples include:
- technical judgement
- depth of personal contribution
- security awareness
- testing mindset
- handling of trade-offs
- clarity of explanation
During the interview, then look for signals of substance. These include concrete examples, understandable reasoning, consistent details and a clear picture of the candidate’s own contribution. Someone who can explain why a decision was made one way rather than another usually shows more than just recall of buzzwords.
Warning signs are just as important. Be cautious with vague statements, evasive answers on details, unclear authorship or claims that have no visible connection to the work you can see. It is often precisely there that you can tell whether someone carried real responsibility or merely witnessed the outcome.
Real work cannot be read only in the final code either. Traces in the development process are also revealing: commits, changes over time, review responses, follow-up improvements, tests and the handling of dependencies.
One example of this kind of evidence-based assessment is Acquispect. Instead of auditing the CV, a developer’s Git repository is examined. In Stage A, the Ghostwriter Detector analyses the .git history forensically, looks at authorship, detects possible code dumping in larger blocks and calculates an impact score. In Stage B, the Safety Check scans for leaked secrets, known vulnerabilities in dependencies, test coverage and the tech stack.
How verification can work without disclosing the raw data
Many teams want to use a work sample as the basis for good interview questions. But that does not automatically mean they need permanent access to raw data, internal details or a complete repository. For the interview, what often matters less is every individual artefact than a reliably explained assessment result.
That result can be issued as a W3C Verifiable Credential via did:web and stored in the developer’s wallet. The credential therefore belongs to the developer themselves. It is not held permanently by a company.
If a company wants to check it, it verifies it when needed. In doing so, it sees the verdict rather than the raw data. At the same time, the assessment remains traceable because a complete audit log explains how the judgement was reached, without giving up the basic idea of selective verification.
For interviews, this is practical:
- the conversation can build on an explainable judgement
- the verdict comes with a confidence score
- ownership remains with the developer
The model is also clearly separated: developers can be audited free of charge. Companies pay per verification, with no subscription model. You can sign in either with a crypto wallet or as a guest.
Frequently asked questions about good interview questions for developers with a work sample
Which good interview questions help when a candidate speaks very convincingly?
Good interview questions move the conversation away from self-presentation and into observable work. Ask the candidate to explain a specific part of the work sample: starting point, decision, resulting problem.
Useful questions include:
- Where was the most difficult trade-off?
- Which assumption later turned out to be wrong?
- What could have broken with a small change?
- How would you yourself have recognised poor work here?
Someone with substance will become more precise. Someone who merely appears polished will often remain general.
Which good interview questions reveal risk and security thinking?
Do not ask only about features. Ask where the uncertainty lay and how it was limited. That lets you see whether someone thinks in terms of responsibility.
Examples:
- Which part seemed risky from your point of view?
- How did you assess secrets, dependencies or tests?
- What was deliberately left unprotected?
- Which side effect was acceptable, and which was not?
If there is also an audit, Acquispect can examine a Git repository in three stages: Stage A for the .git history, Stage B for secrets, known vulnerabilities in dependencies, test coverage and tech stack, and Stage C with five AI expert personas and a consensus verdict with confidence score.
How do I use a verification result in the interview?
Do not use the verdict as the end point, but as the starting point for follow-up questions. The result is stored as a W3C Verifiable Credential via did:web in the developer’s wallet. The credential belongs to the developer. A company verifies it when needed, sees the verdict rather than the raw data and can read the full audit log.
In the interview, this mainly helps with two things:
- asking more targeted questions about unclear points
- comparing the candidate’s statements with traceable evidence
Conclusion: good interview questions improve when they are tied to real work
Good interview questions only come fully into their own when they relate to real work rather than just convincing self-presentation. It is only the link to a work sample that turns general questions into a reliable basis for discussion.
Good interviews do not come from putting on more pressure, but from:
- more context
- more precise follow-up questions
- clear assessment criteria
This makes technical depth, care and responsibility more visible. Instead of assessing answers only by their form, you can make a better judgement about how someone actually decides, puts safeguards in place, prioritises and explains their own contribution.
In the end, the standard is simple: if you hire developers, you should spend less time checking claims and more time reading, assessing and discussing reliable signs of actual work.