Hire and Vet a Developer
Hire on evidence. Not on a good interview.
Supply is not the scarce thing on this market. Judgement is. Five questions, and the tell that separates a real answer from a fluent one, published below so you can run them before you speak to me.
You leave with a role definition and an evaluation plan you can run yourself.
Five questions, and what to listen for
Evaluating a developer without being one means judging the reasoning rather than the code. The tell is always the same: a method beats a story.
The bad answer is fluent, not obviously wrong. That is the entire difficulty.
- Tell me about a bug that took you more than a day to find.You want a method, not a war story. What they observed, what they suspected first, how they narrowed it. A story with a villain and an all-nighter is fluent and contains no method.
- What would you build differently on your last project?A real reversal has a cost and a date attached. "I would write more tests" is humble, modern, commits to nothing, and could be said by anyone who was never there.
- Walk me through how one request travels through your last system.Stated uncertainty is the single most reliable seniority signal in the interview. A confident recital of the stack with no failure path is the weak answer.
- What would you need to know before you could estimate this change?Questions before numbers. An immediate confident figure reads as decisiveness and is the opposite: confidence with no conditions attached is a sales response, and you will be holding it when it is wrong.
- Tell me about a decision you argued against and lost.Ask when they were the one who turned out to be wrong. If nothing comes back after a genuine pause, you are hiring someone whose model of themselves does not update. Costly in a team of three, unrecoverable in a team of one.
Written, comparable, yours
A verbal read cannot be compared across candidates and cannot be handed to a co-founder who was not on the call. Everything here leaves the room in writing.
- A role definition written as outcomes, with the judgement work separated from the hands work
- The interview rubric above, filled in for your role and your stack
- A written read on each candidate, naming the one to hire — including when that is nobody yet
- The ninety-day scorecard, in signals a non-technical manager can check alone
- The contract terms that stop a named engineer being swapped for an "equivalent resource"
The ninety-day scorecard
Written before the advert goes out, because if you cannot say what ninety days should produce, no hire can succeed and every outcome will feel like a disappointment you cannot explain.
Day 30
Has anything real happened?
Something they wrote is in production, small is fine. They can describe your system back to you more accurately than you described it to them.
Day 60
Are they compounding, or consuming?
Documentation has appeared that nobody asked for. They have reversed one of their own decisions and can say what changed their mind. Estimates and reality have started to converge.
Day 90
Can this be left with them?
Given an ambiguous problem they return a decision with a reason, not a list of questions for you. At least one other person on the team is measurably more effective.
If a team is the answer, not a hire
The difference is who holds the priorities. Embedded means you still do. Scoped means somebody else is accountable for a defined outcome, which is the Build page.
Monthly, per engineer · Rolling, starts with a trial week
Embedded Engineer
A named engineer working your backlog inside your team, judged on real output before you commit to anything.
- One engineer embedded in your standup
- A trial week on your repo and your backlog before commitment
- Vishal accountable for technical direction, not delivery hours
- Scale up, scale down, or stop between months
Fixed scope, quoted · Defined outcome, defined end
Scoped Delivery
A named deliverable built to an agreed definition of done, priced before it starts rather than billed as it runs.
- Scope, acceptance criteria and end date agreed in writing first
- A team assembled for the shape of the work
- Vishal accountable for architecture and the release decision
- Everything produced is yours, whatever happens next
I have engineers to place. Here is the protection.
ViitorCloud, the company I co-founded, has engineers, and the section above sells them. An advisor with a bench cannot say "buy six weeks of senior time instead" and stay in business, so asking me to promise independence is worthless. The order is the protection instead.
The standard is published before the offer is, on this page, so you can run my own rubric on my own people. The written output names the candidate you should hire, including when that is nobody yet. And if one of my engineers is ever a sensible candidate for your role, I will say so out loud, put them through the same five questions, and tell you to discount my read on them because I benefit.
One credential is relevant here specifically: since September 2024 I have sat on the board of the Laravel Certification Program, which decides what a certified developer has to know. Deciding a standard for other people is the same work as applying one to your candidate.
No project commitment. No predetermined technology. No pressure to proceed when the evidence says stop. And no figure quoted for work that has not been scoped.
Questions people ask first
How do I judge a developer when I cannot do the work myself?
You do not judge the code. You judge the reasoning about the code, which a non-technical person can absolutely assess once the questions are the right ones. Every question in the rubric above is answerable in plain language by a strong engineer, and every one has a tell that does not require you to read a line of source. A structured comparison beats an impression, and an impression is what an unstructured interview produces.
Can you just sit in on the interview?
Yes, and it is the cheapest useful version of this. I join the technical portion, ask the rubric questions, and send you a written read afterwards that names what was strong, what was fluent but empty, and what I would ask next. What I will not do is give you a verbal "he seemed strong" and leave. A verdict you cannot compare against another candidate is not a verdict.
Are you going to sell me your own engineers instead?
Possibly, and you should discount my read on them accordingly. ViitorCloud has engineers, and on this page you can hire them. The protection is the order: the standard is published before the offer is, so you can run my own rubric on my own people. The written output names the candidate you should hire, including when that is nobody yet.
Is hiring offshore a false economy?
It is a management question wearing a cost question’s clothes. What decides the outcome is whether anybody on your side can tell good work from plausible work, and whether the person you interviewed is the person who commits. Both are fixable, and both are contract terms rather than hopes: named individuals in the agreement, a substitution clause with notice and a right of refusal, allocation stated as a percentage, and a commit-log check in week one.
Run the rubric yourself first
It is on this page and it is free. Bring me the candidate you cannot read, or the offer you are about to make on Friday, and you leave with a written role definition and an evaluation plan you can run without me.
In the age of AI
The advantage was never the model. It's knowing what to build with it — and having a team that can actually ship it.
That's the part I help with: finding where AI genuinely makes your business faster, deciding what's worth building, and standing behind it once it's live.
Four offices, one very full passport
Every dot on this map is a conversation I still remember.
- Where I've spoken
- Office
