Two Key Questions for Evaluating Engineers and Tech Leads in Interviews
In today's competitive development market, hiring managers struggle to identify engineers who can reliably deliver tasks to production. AI can generate code, design architectures, and fix bugs, but it doesn't ensure the long-term viability of systems. A specialist's true value lies in their accountability for outcomes, not just their knowledge of patterns or SOLID principles.
Experience shows that instead of lengthy technical interviews, two simple questions can reveal the level of engineering thinking in minutes. These questions don't test syntax; they uncover a candidate's approach to problem-solving.
Question 1: Who is responsible for the task?
This question distinguishes between developers who own outcomes and those who act merely as role-based executors. Consider two scenarios from a large project involving multiple teams.
In the first case, a ticket about outdated data in a mobile app gets passed around between support, mobile developers, backend, and infrastructure teams. Each team closes the task with "not our problem," without reproducing the scenario or analyzing logs. The user is left without a solution.
In the second scenario, a backend developer tackles incorrect form validation: they check the payload, identify discrepancies with frontend logic, coordinate the fix, and create a tech debt ticket to standardize validation on the backend.
Response patterns:
- "I am" — the owner's mindset: clarifies requirements, raises risks, tests independently, and considers post-release stability. Such engineers are resilient to layoffs and outperform AI in accountability.
- Role-based division ("code is my zone, QA handles testing") — requires more organizational effort from the team and reduces overall value.
Drawing the line of responsibility at the commit stage leads to "orphaned" issues in production. This question quickly reveals whether a candidate will take ownership of a task end-to-end.
Question 2: Do you write unit tests?
This isn't about dogma; it's an indicator of treating code as a living system. In projects without tests, simple changes like pagination can drag on for days due to copy-paste and hidden dependencies — classic tech debt.
Candidates' code often mirrors such patterns: functionally working but not maintainable.
What this question uncovers:
- Attitude toward quality — focus on system behavior in the long run.
- Design approach — tests require modularity, loose coupling, and manageable dependencies (DI, inversion of control).
- Handling changes — refactoring with tests is safe and fast.
- Team culture — promotes principles of extensibility over fragility.
A developer who writes tests builds code for evolution; one who doesn't builds for quick fixes.
Applying to Tech Leads
For engineers, "I am responsible" is a plus. For leads, it's a red flag. Example: a strong full-stack lead took everything upon themselves (architecture, bugs, prioritization). The team became dependent on them, vacations caused disruptions, and it led to burnout. Moving them to an architect role and replacing them with a lead who distributed responsibility stabilized the system.
A good tech lead answers: "The task has an owner within the team. I ensure the process, remove blockers, and maintain focus." Not an executor, but an organizer.
This question checks whether a leader builds delegation or becomes a bottleneck.
Key Takeaways
- End-to-end task ownership distinguishes proactive engineers from role-based executors.
- Unit tests indicate modularity, resilience to change, and long-term quality.
- For tech leads, the focus is on distributing responsibility, not personal execution.
- High correlation with probation success — these questions save hiring time.
- Advantage over AI lies in delivering to a working production state.
These questions apply at any level: from mid-level to senior, from developer to lead. They filter for real value to the team.
— Editorial Team
No comments yet.