Framework knowledge matters. But a candidate who remembers every React hook and waits to be told what to do can be less useful than one who asks the uncomfortable question. That question saves three weeks of wrong work.
Frameworks can be learned. Ownership is how someone behaves when the answer is not in the ticket.
Trivia is easy to interview and easy to overvalue
Interviews drift toward questions with clean right answers because they are easy to score. Explain the event loop. Name React lifecycle behaviour. Write a SQL join. Those confirm baseline knowledge. They say little about how someone handles a messy product problem.
Real project work is full of vague requirements, half-finished APIs, conflicting priorities and trade-offs no documentation can settle.
Give candidates a problem with missing information
Instead of asking only for an implementation, hand over a feature with important details missing. Strong candidates start asking. Who is the user? What does failure look like? What scale does it have to handle? Does a system we already run solve part of this? How will the team know the feature works?
The questions are part of the answer.
Look for consequence thinking
Ownership means thinking about what happens downstream. A candidate changing a database schema should ask how the existing data moves across. A payment flow should raise idempotency: what stops the same charge going through twice? A mobile feature should raise permissions, and the people still on an old version of the app.
You are not testing whether they know every edge case. You are testing whether their thinking runs past the happy path, where everything works and nobody makes a mistake.
Use a realistic code review
Give a small pull request with realistic problems in it, not a puzzle. See what the candidate notices: naming, structure, security, tests, product assumptions. See how they disagree with the author, too.
Good reviewers do not just find faults. They improve the decision without humiliating the author.
Evaluate communication as engineering
In small product teams, engineers have to explain what they are unsure about, ask for decisions and sometimes push back. Communication is not a soft extra bolted onto technical ability. It is part of how the technical work becomes correct.
The best candidate does not have to be the loudest. Clarity matters more than performance.
Do not punish honest uncertainty
Candidates who say ‘I do not know, here is how I would find out’ can be safer than candidates who confidently invent an answer.
Production work rewards people who know where their knowledge stops. Interviews should too.
Hire for the next problem, not only the current stack
Stacks change. Script Lanes itself grew from mobile work into web, cloud, data and AI. A team that hires only exact framework matches can become brittle when the work changes.
Hire for fundamentals, ownership and speed of learning. Then look for deep framework knowledge where the role genuinely needs it.