Published
How to Vet an Engineer When You Can't Read Code
You cannot assess whether someone’s code is any good. Stop trying. Assess something you can actually evaluate: whether they can explain their own decisions when you push on them.
The standard advice for hiring an engineer assumes you can read a code sample. If you could, you would not be hiring one. So the usual checks get replaced with proxies — years of experience, a polished portfolio, a confident call — and none of those distinguish an engineer from someone who has been generating code for six months and has never read it.
There is a better test, and it does not require you to understand a single line. Ask someone to explain why a specific piece of their own code is written the way it is. Then listen to the shape of the answer. People who understand what they wrote answer immediately and get specific. People who did not read it produce fluent generalities. That gap is obvious once you know to listen for it.
This guide is a set of questions built on that principle. They work on freelancers, agencies, and full-time hires. They work on us, and the last section says what to do if we fail them.
The commit walkthrough
If you only do one thing from this page, do this one.
Ask the candidate to open a specific piece of code they wrote — a commit, a pull request, a file, whatever they can show you — and answer three questions about it:
- Why is it written this way, and what else did you consider?
- What would break if I changed this part?
- What happens when this fails? Who finds out, and how?
You are not grading the technical content. You are grading the shape of the answer, which is why this works without you understanding any of the code.
What a good answer sounds like
It arrives fast, because they are recalling rather than constructing. It gets specific quickly, naming a particular line, a particular case, a particular thing that went wrong. It includes a trade-off: they chose this approach and gave something up for it, and they can say what. It includes at least one thing they are not happy with, because everyone who reads their own code closely finds something. When you ask what breaks if you change it, they answer with a consequence, not a reassurance.
What a bad answer sounds like
It is fluent and stays general. It describes what the code does rather than why it is that way — “this handles the user authentication flow” is a restatement, not an explanation. Pushing for specifics produces more of the same register at a slightly lower altitude. The failure question gets answered with confidence rather than detail: it is handled, there is error handling, it is covered. Nothing that went wrong is ever named, because nothing was ever debugged.
The tell is the pivot. Ask why, and a bad answer quietly converts your question into what, then answers that instead. Once you have heard it, you cannot unhear it.
Six questions, and how to grade the answers
Same principle as the walkthrough. You are listening for specificity and for whether the answer costs them anything to give.
1.Who owns the code, and where does it live?
A good answer sounds like
It lives in a repository under your account, and you are the admin. They have access because you granted it, and you can revoke it yourself in about thirty seconds. If your code is currently inside a hosted builder, a good answer includes getting it out into a repository you own before anything else starts.
A bad answer sounds like
The code lives in their organization, their workspace, or their account, and ownership transfers on final payment. Anything that makes access to your own software contingent on being current on invoices is a leverage arrangement described as a process.
2.What will you not do? What is out of scope?
A good answer sounds like
A specific list, offered without being pushed. Something like: no penetration testing, no compliance certification, no mobile app, no design work, no changes to the payment provider you chose. Someone who has done this work before has a ready answer because they have been burned by an assumption before.
A bad answer sounds like
"Whatever you need." That is not flexibility. It means scope has not been thought about, and it will get decided later during an argument about an invoice.
3.If I want to leave, what does the handover look like?
A good answer sounds like
A concrete description: where the documentation is, how environments are set up, what credentials you would need to rotate, and how long a walkthrough with the next team would take. Ideally it is written into the agreement rather than promised in a call.
A bad answer sounds like
Discomfort at the question, or a vague reassurance that it would not be a problem. Also bad: knowledge that lives only in one person's head, with no documentation, described as a feature of how tightly they know your system.
4.How will I see progress week to week?
A good answer sounds like
Something you can verify without them. Commits in your repository that you can see landing. A staging environment you can click through. A short written update naming what shipped and what did not. You should be able to check the claim against the artifact.
A bad answer sounds like
Progress reported only in percentages or status colors. "We're about 80% done" is not information. It is a feeling, and it is the number that stays at 80% for six weeks.
5.What are your actual working hours in my timezone?
A good answer sounds like
Real hours, stated as hours. "10am to 6pm your time, Monday to Thursday, and I answer messages within the working day." Then it goes in writing, and you hold them to it.
A bad answer sounds like
"We have overlap with your timezone" or "we're flexible." Overlap that exists on paper and not in practice is the most common failure in remote engineering arrangements. Ask for the hours. If the answer stays vague after you ask directly, that is the answer.
6.What would you tell me if the honest answer is that I don't need you?
A good answer sounds like
A real example of when that is the case, described specifically. "If your app has no users and no sensitive data, most of what I'd fix isn't urgent yet." Someone who has turned work down can usually describe the situation in which they did it.
A bad answer sounds like
The premise gets deflected. Every version of your situation turns out to need their help, and the recommendation was already formed before they read anything.
Contract and commercial red flags
These have nothing to do with technical skill. A genuinely good engineer can still offer you terms worth refusing.
| Red flag | Why it matters | What to ask |
|---|---|---|
| Findings are withheld unless you buy the remediation | You paid to learn what is wrong with software you own. Holding the findings hostage converts a review into a sales funnel, and it means you cannot take the work to anyone else for a second opinion or a cheaper quote. | Do I receive the full written findings whether or not I hire you for the fixes? |
| A full rebuild is recommended before anyone reads the code | A rebuild is the largest invoice available in this market. Recommending one from a description rather than from the repository is a guess that happens to be the most expensive guess. | What did you read that led you there, and what would change your mind? |
| Scope will not go in writing | Verbal scope is remembered differently by each party, and the difference surfaces at the point where it is most expensive to resolve. Anyone who has finished a project before expects to write scope down. | Can you put what is and is not included in the agreement before we start? |
| Repository admin access requested on day one | Read access is enough to review code. Write access is enough to do the work. Admin lets someone change permissions, delete branches, and remove your collaborators, which is not needed to fix your app. | What is the least access you need to start, and when would you need more? |
| No named individual is accountable | If the contract names a company and never a person, nobody is responsible for the outcome, and the engineer who is actually working may not be the one you spoke to during the sales call. | Who specifically is doing the work, and can I talk to them before I sign? |
| Pricing that cannot be explained | A price is either based on time, on a defined deliverable, or on a fixed scope. If nobody can tell you which, the number came from what they think you will pay rather than from what the work is. | What is this price based on, and what would make it go up or down? |
Why the same work costs $20 or $50,000
The spread in this market is real and it confuses people into comparing prices for four different products.
Search for help fixing an AI-built app and you will find offers from about $20 on freelance marketplaces up past $50,000 at agencies, described in language that is nearly identical. The descriptions are the problem. The underlying products are not the same thing.
- A single bug fix. One defined defect, reproduced and corrected. Cheap because the scope is one thing and nobody is reading the rest of your codebase. Right when you know exactly what is broken and it is isolated.
- A fixed-price audit. Someone reads the code and writes down what they found, in priority order. You get a document. No code changes. Right when you do not yet know what you have, which is the most common situation.
- Multi-week remediation. Actually doing the work the audit found: access rules, authentication, the paths that keep breaking. Priced by the amount of work, which is why an honest quote comes after a read rather than before it.
- A rebuild. Starting again with the existing app as the specification. The most expensive option available, occasionally the correct one, and the one a vendor has the most incentive to recommend.
Most people arrive believing they need the fourth and turn out to need the second. Work out which product you are buying before you compare two prices, because a $20 bug fix and a $20,000 remediation are not competing offers. We broke the pricing down further in a separate guide, including what drives a quote up.
“How do I know you aren’t just vibe coding it too?”
The right question to ask, and the honest answer is not the one you might expect.
Competent engineers use AI coding tools in 2026. Refusing to would make someone slower without making the work better, and a candidate who tells you they never touch these tools is telling you something about their judgment rather than their standards.
So the line is not whether AI was involved. It is whether a person read the output, tested it, and can defend it. That distinction is not visible in the code to someone who cannot read code, which is precisely why the commit walkthrough is the test. Generated code that nobody reviewed cannot be explained. Reviewed code can.
There is measured reason to care about the review step specifically. The defects that AI assistance introduces are not the shallow kind that a compiler or a linter catches.
AI-assisted developers produced three to four times more code and ten times more security findings. Privilege-escalation paths rose 322% and architectural design flaws 153%, while syntax errors fell 76% and logic bugs fell 60%.
45% of AI-generated code samples failed security testing, introducing OWASP Top 10 vulnerabilities. Syntactic correctness improved sharply from 2023 to 2025 while security pass rates stayed flat at 45–55%.
Across 2.23 million generated code samples, 19.7% referenced a package that does not exist, producing 205,474 unique fabricated package names. 43% of hallucinations repeat across runs.
Read those carefully, including the limitations printed under each one. Two of the three come from companies that sell security tooling and therefore have an interest in the finding, and the Apiiro result sits in tension with other research on developer productivity. What survives the caveats is the direction: the errors that get through are the ones a machine check does not catch and a reading human does. Whether someone read it is the thing you are hiring for.
Including us
Everything on this page should be run on us. Ask us to walk you through a commit and explain why it is written that way. Ask what we will not do. Ask what the handover looks like if you leave, and what our working hours are in your timezone. If we answer any of it in generalities, or get uncomfortable being asked, walk away.
Our conflict of interest is straightforward and worth naming: we sell the services this guide helps you shop for. A page that teaches you how to evaluate vendors is also a page that makes us look like the careful option. Read it with that in mind. The test is only worth anything if it can come back negative for the people who published it.
We also have no published track record to point you at, so none of this rests on reputation. Run the questions.
Vetting an engineer — questions
Can I really judge an engineer without understanding the code?
Yes, because you are judging the answer's structure rather than its content. Someone who wrote and read a piece of code answers questions about it immediately and gets specific about a particular line, a particular failure, a particular trade-off they made. Someone who generated it and moved on produces fluent, general language and restates what the code does instead of why it is that way. That difference is audible in any language, including ones you do not speak.
How do I know the people I hire aren't just using AI too?
They almost certainly are, and in 2026 that is not the problem. Competent engineers use AI tools because refusing to would make them slower without making the output better. The distinction that matters is whether a person read the result, tested it, and can defend each decision under questioning. That is exactly what a walkthrough of a specific commit tests, and it is the reason the walkthrough is the single most useful thing you can ask for.
What if a candidate refuses to walk me through their code?
Treat a refusal as a completed test with a clear result. There are legitimate limits — code written under a confidentiality agreement for another client cannot be shown — but someone in that position offers an alternative, such as an open-source contribution or a small piece written for the purpose. A flat refusal with no alternative is information.
Should I ask for a paid trial task instead of interviewing?
A small paid task is a good test and works well alongside the questions rather than replacing them. Keep it genuinely small, pay for it, and make it something real from your own backlog. Then ask them to walk you through what they wrote, which turns the task into the same test with better material.
How much should I expect to pay to have someone look at my app?
Work described in nearly identical language sells across an enormous range in this market, from about $20 on freelance marketplaces to $50,000 and above at agencies. The spread is real, and it mostly reflects genuinely different products rather than markup: a single bug fix, a fixed-price written audit, several weeks of remediation, and a rebuild are four different purchases. Work out which one you actually need before comparing prices.
Run these questions on us.
Tell us what you built and what's worrying you, and ask us to walk you through code we've written. If the honest answer is that you don't need us, we'll say so.