Interview

Interview questions on learning how to learn probe whether you have a real, evidence-based system for acquiring skill — or just vibes. Interviewers (especially for senior/staff roles) care most about: how you ramp on an unfamiliar codebase, how you stay current under delivery pressure, and whether you can tell robust learning science from popular myths. Answers below are concise with the traps and follow-ups that separate strong candidates.

Q1. What's the single most effective study technique, and what's the evidence?¶

Active recall (retrieval practice): testing yourself on material strengthens memory far more than re-reading. The canonical evidence is Roediger & Karpicke (2006) — students who recalled a passage crushed re-readers on a delayed test, despite the re-readers feeling more confident. Pair it with spacing (distributing study over time).

Trap: saying "re-reading" or "watching videos." Those feel productive (fluency illusion) but are the weakest methods. Follow-up: "Why do people stick with re-reading if it's worse?" → because it feels fluent and effortless; learning that works feels harder.

Q2. Are learning styles ("I'm a visual learner") real?¶

No. The "match teaching to your style" claim has no credible empirical support — Pashler et al. (2008) reviewed it and found no well-designed studies showing the predicted benefit. What actually matters is matching the method to the material (geometry is visual, pronunciation is auditory), and using multiple modes helps everyone.

Trap: confidently endorsing learning styles — it signals you haven't checked the evidence. Follow-up: "So what does determine the best way to learn something?" → the nature of the material and using retrieval + spacing regardless of "style."

Q3. How do you ramp on a 2-million-line codebase you've never seen?¶

Don't read it top-to-bottom. Concretely:

1. Map first — find the architecture docs/ADRs, build a one-page diagram of major components and data flow.
2. Trace one real path end-to-end (e.g., "what happens on login?"), running it locally with a breakpoint — active, not passive.
3. Learn the why via git log/blame and design docs, not just the what.
4. Ship a small change through the full build/test/review/deploy loop — nothing teaches faster.
5. Talk to the people who built it; extract the model in their heads.

Trap: "I'd read through the whole codebase." That doesn't scale and you'd forget the start by the end. Follow-up: "What if there are no docs and no original authors?" → traces and tests become your documentation; git history and small experiments reconstruct intent; you write the map you wished existed.

Q4. When do flashcards (Anki) help an engineer, and when are they useless?¶

Help for stable, atomic facts you need from memory in flow: API signatures, CLI flags, HTTP semantics, SQL isolation levels, Big-O of common ops. Useless or counterproductive for procedural skill (you can't flashcard "good API design"), volatile facts (config that changes each release — bookmark it), and understanding (a memorized one-liner ≠ a mental model).

Trap: claiming flashcards make you a better engineer broadly — they only address declarative recall. Follow-up: "How would you write a good card?" → one atom, recall-forcing not recognition, your own words.

Q5. Explain deliberate practice. Isn't 10 years of experience enough?¶

Deliberate practice (Ericsson) = practicing at the edge of your ability, with a specific goal and immediate feedback, isolating the weak sub-skill. The key finding: experience alone doesn't create expertise — people plateau by repeating what they already do well. So 10 years can be 1 year repeated 10 times.

Trap: equating "years on the job" with skill, or quoting "10,000 hours" as a magic number (Ericsson disowns that framing). Follow-up: "How is this different from your day job?" → day job is mostly doing what you can already do; deliberate practice means deliberately taking the thing you can't yet do.

Q6. Feedback is central to deliberate practice, but engineering feedback is slow and noisy. How do you handle that?¶

You manufacture feedback loops: tests/types/linters compress year-long delays into seconds; predict-then-measure (write your expected outcome, then check — the gap is the lesson); blameless post-mortems; and observability to see the effects of decisions that are otherwise invisible. The predict-then-measure habit is the one that most directly fixes a wrong mental model.

Follow-up: "Give an example." → "Before a perf change I predict '30% CPU drop,' then profile. When I'm wrong, I've found a flaw in my model of the system."

Q7. Why does the second programming language take so much less time than the first?¶

Transfer of deep structure. Syntax doesn't transfer, but concepts do: iteration, types, concurrency, error handling, memory model. Your first language teaches the ideas; the next is mostly remapping known ideas to new syntax. Most of what you "know" was never language-specific.

Trap: attributing it to "I'm just smarter now." Follow-up: "So how should you learn a new language fast?" → focus on its model (memory, concurrency, errors, build/dep tooling), treat syntax as a lookup table, write something real.

Q8. What does "T-shaped" mean and why does it matter?¶

Broad literacy across many areas (the horizontal bar) plus genuine depth in one (the vertical). Breadth lets you collaborate, evaluate, and know when to defer to an expert; depth makes you valuable and forges transferable deep structure. The anti-patterns are all-breadth-no-depth (trusted to own nothing) and all-depth-no-breadth (brilliant but siloed). The depth bar should shift over a career.

Follow-up: "Where are you on the T right now, and where do you want the bar to move?" → tests self-awareness and intentional growth.

Q9. What is the Feynman technique and when do you use it?¶

Explain a concept in simple plain language as if to a beginner; wherever you stumble or fall back on jargon you can't unpack, that's a gap; go fill it and explain again. Use it to find what you don't actually understand — it's impossible to fake a simple explanation.

Trap: describing it as just "summarizing." The point is the simplicity constraint that exposes gaps. Follow-up: "How does this connect to teaching?" → teaching is Feynman at scale; the protégé effect means teaching deepens your own understanding.

Q10. What's "tutorial hell" and how do you get out?¶

Completing endless tutorials, feeling like you're learning, but freezing on a blank file. It's the fluency illusion — following a tutorial is recognition, not recall. Escape by manufacturing difficulty: build the same project with the tutorial closed, then build something the tutorial didn't cover. The test: can you build a different version without the guide?

Follow-up: "How do you know when you've actually learned something from a tutorial?" → when you can apply it to a problem the tutorial never showed you.

Q11. Just-in-time vs. just-in-case learning — how do you decide?¶

Just-in-time: learn it when a real task needs it (specific libraries, configs, one-off integrations) — it sticks because you immediately apply it. Just-in-case: invest up front in foundations that are broad, slow to learn, and long-lived (data structures, concurrency, how systems fail, your primary language). Decide with half-life (long-half-life knowledge is worth up-front investment) and frequency × cost-of-being-wrong.

Trap: "always learn everything up front" (wasteful) or "always just-in-time" (leaves foundational gaps). The answer is allocation.

Q12. How do you stay current under constant delivery pressure, with no free quarter to learn?¶

Embed learning in delivery rather than adjacent to it: pick stretch tasks that also need shipping; treat code review, design review, and post-mortems as learning loops that cost no extra time; protect a small consistent slice (spacing beats cramming); and budget ramp time honestly into estimates. The engineers who plateau are the ones waiting for things to "calm down."

Follow-up: "How do you decide what to learn given limited time?" → leverage: frequency × cost, and the org's actual problems, not the shiny new framework.

Q13. Why can a chess master memorize a board in seconds but a novice can't — and how is that relevant to engineering?¶

Chunking (Chase & Simon, 1973). Masters see a few meaningful patterns, not 25 individual pieces — but only on real positions; on random boards they're no better than novices, proving it's pattern recognition, not raw memory. In engineering, experts read a whole retry-with-backoff or producer-consumer setup as one chunk. The lesson: deliberately study patterns (design/algorithmic/architectural) to build chunks so new problems become "oh, that's just X."

Follow-up: "What does the random-board result imply for experts?" → expertise is pattern-bound; outside familiar patterns, an expert's advantage shrinks (and can mislead — expertise blindness).

Q14. As a staff engineer, how do you multiply learning across a team, not just yourself?¶

Convert your learning into reusable assets: the architecture map you wished existed, ADRs capturing the why, mentoring (predict-before-reveal pairing), and — highest leverage — better feedback systems (fast CI, good observability, blameless post-mortems) plus psychological safety so "I don't know, let's find out" is normal. A team's learning rate is a real, improvable system.

Trap: answering only about your own learning — at staff level, impact is the team's learning rate. Follow-up: "How do you measure if it's working?" → onboarding time-to-first-commit, fewer repeated incidents, knowledge spread (bus factor).

Q15. How do you know when you've actually learned something versus just feeling like you have?¶

The reliable test is production under difficulty: can you recall it without the source, explain it simply (Feynman), apply it to a novel problem, and predict the system's behavior in a scenario you haven't seen? Feeling fluent while the book is open proves nothing — that's the fluency illusion. Learning is verified by retrieval and transfer, not by recognition.

Follow-up: "How do you build that into your routine?" → close the source and self-test; predict-then-check; teach it to someone; build the un-guided version.