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.
Hire
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.
Vishal stays close to a limited number of consequential engagements at a time. If the fit is not right, he will say so early.
15 yrsCo-founding and running an engineering company, since October 2010
500+Projects delivered by the ViitorCloud engineering team
$46M+Value of the platforms built for enterprise and Fortune 500 clients
10K+Monthly active users on software the team shipped
The rubric, published
Five questions, and what to listen for
Evaluating a developer without being one means judging the reasoning rather than the code. Ask for a bug they hunted, a decision they reversed, a request path through a system they built, an estimate they cannot yet give, and an argument they lost. The tell is always the same: a method beats a story.
- 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, and the hypothesis that turned out to be wrong. 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 and nothing they admit to not understanding 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.
The bad answer is fluent, not obviously wrong. That is the entire difficulty, and it is why an unstructured interview produces an impression rather than a verdict.
What you get
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 you are considering, 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
After the offer
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 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. The release process is something the team runs.
Two ways to work
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.
Embedded Engineer
Monthly, per engineer · Rolling, starts with a trial week
A named engineer working your backlog inside your team, judged on real output before you commit to anything.
- One engineer from the line-up below, embedded in your standup
- A trial week on your repo and your backlog before commitment
- Vishal accountable for technical direction, not for delivery hours
- Scale up, scale down, or stop between months
Start with a trial week: Discuss an embedded engineer
Scoped Delivery
Fixed scope, quoted · Defined outcome, defined end
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
Or a defined outcome instead: Scope a delivery
The conflict
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.
Before you book
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 is a thing 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 of them has a tell that does not require you to read a line of source. Brandon Hall Group found employers without a standardised hiring process were five times more likely to make a bad hire, reported via SHRM on 9 May 2017 and now dated. The finding that holds is about the process, not the year: 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, or hand to a co-founder who was not on the call, 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 further down 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. If one of them is a sensible candidate for your role I will say so out loud, put them through the same rubric, and tell you that I benefit. 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. The rate is the visible variable and it is rarely the one that decides the outcome; what decides it 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 rather than as the word full-time, and a commit-log check in week one. That last one takes five minutes and almost nobody does it.
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.
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.