When a company asks me for a senior engineer, the first thing they usually want to know is where the person is based. I think the more useful question is who decided they were senior. At a lot of staffing firms that call is made by a recruiter with a checklist: years of experience, a list of frameworks, a short call to confirm the English is good. None of that tells you whether someone can take responsibility for production software when nobody is looking over their shoulder.
Here’s how I do it. Every engineer Softronic places goes through three interviews that I run myself: 90 minutes of live coding in the client’s stack, 60 minutes on a system they kept running in production, and 45 minutes on communication and ownership. Then come two weeks of paid probation on real work before they join a client team. No recruiter screens them before I do.
It’s slower, and it limits how many people I can place. I’m fine with that. This post covers what each stage is for and why it’s there. The questions themselves, with the answers I score as strong or weak, are in a separate post: senior engineer interview questions and red flags.
| Stage | Length | What I score | Who runs it |
|---|---|---|---|
| 1. Live coding in the client’s stack | 90 minutes | How they debug, whether they ask before assuming, how they reason about trade-offs | Me |
| 2. A system they ran in production | 60 minutes | Whether they can name a decision they’d undo, how they think about load and failure | Me |
| 3. Communication and ownership | 45 minutes | Clear writing, disagreeing politely, owning mistakes | Me |
| 4. Paid probation | 2 weeks | Whether the interview signal holds up on real work | Softronic, on work it pays for, before any client team |
Why does every candidate get the same questions?
A 2022 reanalysis of decades of selection research by Sackett and colleagues ranked structured interviews as the best predictor of job performance among the methods reviewed, with a mean validity of .42, ahead of general cognitive ability tests at .31 (SIOP’s summary of the paper). In a structured interview, every candidate for a role gets the same questions and every answer is scored against the same rubric. Google’s re:Work guide to structured interviewing covers the practical side, including writing down what a poor, borderline, solid and outstanding answer looks like before you ever talk to a candidate.
Most technical interview loops I’ve seen skip this part. Each interviewer improvises, the questions drift from one candidate to the next, and the decision comes down to whoever argues hardest in the debrief. Consistency fixes that far better than harder questions would.
My rubric is short. Before each call I write down what a senior answer should include for every question, and I score against those notes right after. Everyone applying for the same kind of role gets the same questions.
Stage 1: live coding in the client’s stack (90 minutes)
I don’t use algorithm puzzles. Inverting a binary tree on a whiteboard says very little about whether someone can figure out why a checkout endpoint times out once a week.
Instead we pair for 90 minutes on a problem that looks like the client’s real work. If the team runs Next.js and Postgres, the exercise is in Next.js and Postgres. If it’s a set of Go services, it’s in Go. The problem is small enough to finish, and it has gaps on purpose: a requirement I left out, an input the description never mentions. The client’s tickets will have gaps like that too, and I want to see whether the candidate notices and asks, or picks an interpretation silently and builds on top of it.
Working code is the minimum. Two candidates can both finish, and only one of them will have explained a plan before typing, handled the empty list without being prompted and said what they would test next. That’s who I’m looking for. The prompts I use and how I grade each one are in the question bank.
A long résumé at a well-known company predicts this stage less than people expect. Engineers who have always received detailed specs sometimes stall when the problem is underdefined, while people who’ve worked on small teams, making product decisions themselves, tend to be comfortable with it.
Stage 2: a system they kept running (60 minutes)
The second interview is about architecture, anchored in something the candidate kept alive in production. I ask them to walk me through it: the data model, where it got slow, what broke, what they’d change if they started again. I start from a real system because a hypothetical design mostly measures how much someone has read, and the client is paying for someone who has operated things.
The strongest signal in this hour is regret. A candidate who can name a specific decision they would undo, explain what it cost and describe the alternative has lived with a system long enough to see the consequences of their choices. Someone who stays at the level of “we scaled it to millions of users” and can’t say where the bottleneck was has usually read more about that system than they operated it.
The last part of the hour is load and failure: where the system breaks first as traffic grows, and how they’d find out before their users do. Good answers here almost always start with “it depends,” and then say on what, specifically.
Stage 3: communication and ownership (45 minutes)
This is the shortest interview and the one that turns away the most people who did well in the first two. There’s no code in it.
A LatAm engineer working inside a US team spends a big part of the day writing: pull request descriptions, Slack threads, design docs, updates for a manager they might speak to live once a day. If that writing is vague, the client notices within a week, however good the code is.
The exercise that teaches me the most is a short written status update for a project that’s running late. A good one says the project is late in the first sentence, explains why without blaming anyone and proposes a next step. A weak one buries the delay under three paragraphs of context. The rest of the hour is conversation about past disagreements and past mistakes, and I’m listening for whether the candidate can disagree politely. An engineer who agrees with everything the lead says is giving the client senior hours without senior judgment.
Then two weeks of paid probation
Interviews are samples, and even careful ones get it wrong sometimes. Before anyone joins a client team, they spend two weeks on real work that Softronic pays for. If what I saw in the interviews doesn’t hold up, that cost stays with me instead of landing on the client. Of everything in the process, it’s the step I’d least want to give up, and I think it’s a big part of why placements last.
What the client sees
Most of this happens before you meet anyone. You tell me about the role and the stack, I run the interviews against that stack, and I show you candidates within 14 days of the first call. Nobody joins your team before the probation is done, and the probation isn’t billed to you. If the fit turns out wrong later, you give 30 days’ notice and the engagement ends, with no claw-back.
How can you check a vendor’s vetting?
I don’t publish a pass rate, because I don’t keep an applicant funnel careful enough to defend a number like “top 3%.” What I can tell you is that working this way means I place few engineers.
Whether you work with me or with someone else, two questions about vetting tell you a lot:
- Who runs the technical interview, and have they worked in the stack they’re evaluating?
- Is there a written rubric, and can you see it?
A vague answer to either one is informative on its own. The rest of what I’d ask a vendor, from who owns the code to what it costs you to end the engagement, is in my nearshore partner checklist. If you’re weighing the big marketplaces against a small shop, I compared Toptal, Andela and the smaller alternatives.
And if you’d rather hand the whole process to someone, tell me about the role.