Interview Questions to Ask a Software Engineer — 12 Behavioural and Psychometric Probes

The 12 questions

Each one anchored in trait literature (Big Five, Holland Codes, Goleman EQ, DISC quadrants). Use as a structured probe set; pair with the psychometric bundle to validate signals.

1. 01

   Approaching an unfamiliar codebase — the silent test

   “Walk me through the last time you had to debug or extend code you did not write. What was your first move, and how did you decide where to dig?”

   Why ask

   High Openness (Big Five) surfaces first in how engineers approach novel problem domains. This question probes openness to experience and willingness to learn without immediate mastery. It also surfaces Conscientiousness — whether the person methodically maps the territory before acting, or jumps in.

   What to listen for

   Listen for a systematic approach: they read the relevant tests, traced calls backward from the symptom, or asked teammates for the architecture overview before guessing. They name specific tools (debugger, logs, test output). Weak answers jump straight to 'I just changed it until it worked' or blame the original code.

   Red flags

   Vague hand-waving ('I figured it out'); blame-shifting ('the code was badly written'); no mention of how they verified the fix; treating each bug as isolated rather than understanding the system.

2. 02

   Technical trade-offs under constraint — reading the room

   “Tell me about a time you had to choose between a 'right' solution and a 'ship-this-week' solution. What was the trade-off, and how did you make the call?”

   Why ask

   This surfaces mature Conscientiousness married to realism. High Conscientiousness paired with pragmatism — the ability to read stakeholder needs and technical reality — predicts people who ship, document the debt, and revisit it later.

   What to listen for

   They name the constraint (shipping timeline, legacy system, team skills). They explain why the simpler solution worked ('we did not need X yet'). They say what they documented or what they planned to clean up later.

   Red flags

   Regret or defensiveness about shipping 'bad code'; no mention of trade-off visibility to the team; code debt not captured anywhere.

3. 03

   Learning from failure — growth versus defensiveness

   “Describe a production bug or deployment failure caused by your code. What went wrong, and what did you change about how you work?”

   Why ask

   Low Neuroticism paired with high Openness predicts engineers who learn from mistakes without shame spiraling. This question separates engineers who own failure, extract lessons, and rebuild from those who rationalize or ghost.

   What to listen for

   They name the root cause without hedging ('I did not test the edge case'; 'I deployed without running migrations'). They describe what changed after ('now I pair-review migrations'; 'I added a test for that').

   Red flags

   Blame pushed to QA, ops, or the framework; no change in behavior after; never actually experienced a production failure.

4. 04

   Code review — the hidden collaborative signal

   “Walk me through a code review you gave recently. What did you focus on, and did you find yourself pushing back? How did you frame it?”

   Why ask

   Code review reveals both technical depth and emotional intelligence. Engineers high in Agreeableness + Conscientiousness write reviews that improve code without ego. Low Agreeableness can mean brutal feedback that damages morale.

   What to listen for

   They name specific concerns. They describe how they phrased feedback ('I would lean toward X here because...'). They mention learning from the author's perspective. They distinguish between 'must-fix' and 'nice-to-have' feedback.

   Red flags

   Dismissive tone ('the code was sloppy'); personal critique instead of code critique; no examples of how they frame feedback; treating reviews as gatekeeping rather than teaching.

5. 05

   Estimation and scope reality — conscientiousness under pressure

   “Tell me about a feature you estimated and the estimate was way off. What did you miss, and how do you estimate differently now?”

   Why ask

   High Conscientiousness tends to underestimate (perfectionism + low self-deception), while lower Conscientiousness tends to overestimate (optimism bias). This question separates engineers who learn from estimation failure from those who repeat it.

   What to listen for

   They identify the blindspot ('I did not account for the legacy system integration'). They explain what changed ('I now break work smaller'; 'I add 50% buffer for unknowns').

   Red flags

   Blame on interruptions or scope creep alone; no structural change to estimates; never admits being wrong; estimates remain unreliable but they shrug it off.

6. 06

   Technical curiosity and growth — openness and agency

   “What is the last technical thing you learned on your own, outside of work-assigned learning? Why did it grab you?”

   Why ask

   High Openness predicts engineers who stay sharp because they explore. This separates engineers on autopilot from those who drive their own growth.

   What to listen for

   They name something specific ('I built a Rust CLI because WASM compilation fascinates me'). They describe why it mattered — a real problem or curiosity that drove the learning.

   Red flags

   Cannot name anything recent; defaulting to 'I read the docs' or 'I did a course'; treating learning as box-checking; no genuine curiosity signal.

7. 07

   Architectural thinking — systems beyond the ticket

   “Describe a system or feature you designed from scratch. Walk me through how you decided on the architecture, and what you would change if you built it again.”

   Why ask

   This surfaces Holland Code dominance: Investigative (systems thinking) paired with Conventional (standards) predicts strong architects. This question also reveals humility: do they see future-improvements or do they think they nailed it?

   What to listen for

   They describe the constraints they optimized for. They name tradeoffs. They describe what surprised them during implementation. Most importantly: they would change something.

   Red flags

   Over-engineered for the actual problem; no mention of team skill or org constraints; no tradeoffs articulated; 'I would do it the same way' suggests no learning.

8. 08

   Legacy system triage — pragmatism and judgment

   “You inherited a legacy system with no tests and confusing code. You have three weeks to add a feature. How do you approach it?”

   Why ask

   This is a real scenario and separates thoughtful engineers from reckless ones. High Conscientiousness without judgment leads to 'I rewrite it properly' (misses deadline). Low Conscientiousness leads to 'I hack the feature in' (breaks something).

   What to listen for

   They ask clarifying questions. They might add one test for the new path, run the old code to understand flow, or pair with someone who knows the system. They describe a minimal-risk approach.

   Red flags

   Charging in without understanding the system; 'I would rewrite it' (unrealistic timeline); no mention of test coverage or safety.

9. 09

   Working across skill boundaries — growth mindset and collaboration

   “Tell me about a time you had to work on something outside your depth. How did you approach it, and who did you lean on?”

   Why ask

   This measures Openness (willingness to be a beginner), Agreeableness (reaching for help), and Conscientiousness (following through). Engineers who admit boundaries and ask for help scale faster than those who pretend mastery.

   What to listen for

   They name a real skill gap. They describe how they learned ('pair sessions with X'; 'I read the docs with Y reviewing my understanding'). They credit the people who helped.

   Red flags

   Never works outside their lane; treats asking for help as failure; does not follow up on lessons learned.

10. 10

    Handling ambiguous requirements — ownership and communication

    “You receive a vague requirement from a non-technical stakeholder. How do you turn it into something you can build?”

    Why ask

    High Conscientiousness without Agreeableness leads to passive handoff. High Agreeableness without Conscientiousness leads to scope creep. Mature engineers high on both drive clarity upfront.

    What to listen for

    They ask specific questions before coding ('What does success look like?'; 'Who is the user here?'). They propose a phased approach if scope is unclear. They document the understood requirement and get sign-off.

    Red flags

    Jumps to coding based on assumption; blames stakeholders for unclear specs; does not surface ambiguity early.

11. 11

    Diversity of approach — learning multiple paradigms

    “Have you worked in different programming paradigms — functional, object-oriented, reactive? How did switching affect how you think about code?”

    Why ask

    High Openness to Experience predicts engineers who learn multiple languages and paradigms, making them adaptable when a new problem demands a different tool.

    What to listen for

    They name specific shifts: 'Learning Haskell made me rethink state management even in Python'. They see paradigms as mindset expansion, not just different syntax.

    Red flags

    Only ever worked in one paradigm; cannot articulate why you would choose one over another; treats other paradigms as 'weird' rather than legitimate.

12. 12

    Sustaining quality under deadline — discipline and realism

    “You are three days from deadline and discover a design flaw that would take a week to fix properly. How do you handle it?”

    Why ask

    This is a Conscientiousness stress-test. High Conscientiousness under pressure can break in two directions: either perfectionism (misses deadline), or cutting corners without strategy. Mature high-Conscientiousness engineers navigate by making the tradeoff visible.

    What to listen for

    They escalate immediately. They propose a solution in writing ('We ship the partial fix and track the debt in an issue'). They estimate the real cost of waiting versus patching. They document the shortcut.

    Red flags

    Misses deadline trying to fix it perfectly; hides the problem; ships the flaw undocumented; panic without escalation; no plan for revisiting the debt.

Move from gut feel to signal

The 12 questions above anchor your interview to trait science. Pair them with psychometric data to reduce interviewer noise. The Technical & Analytical Aptitude bundle combines cognitive aptitude, logical reasoning, abstract reasoning, and work-ethics screening in one 40-minute assessment ($79/candidate at JobCannon's Team tier). Run it after phone screening and before full technical interviews to get a data-driven baseline.

Or email hello@jobcannon.io. Self-serve via Stripe at $0 / $29 / $79 / $199 per month. EU data residency, GDPR-compliant.