Technical Interviews From Both Sides: What I Learned Interviewing and Being Interviewed

I have conducted over 100 technical interviews as a hiring manager and been through at least 30 as a candidate. This dual perspective revealed something uncomfortable: most technical interviews are poor predictors of job performance. But some interview formats genuinely identify strong candidates. Here is what I have learned from both sides.

What Traditional Interviews Get Wrong

Algorithm puzzles on a whiteboard (or CoderPad) test: memorization of specific patterns, performance under artificial time pressure, and ability to code without IDE support. They do not test: collaboration, code maintainability, system design thinking, debugging ability, or learning speed.

The correlation between "can solve leetcode mediums in 30 minutes" and "writes excellent production code in a team" is weak. Some of the best engineers I have worked with struggle with algorithm puzzles. Some developers who ace algorithms write unmaintainable code in production.

What Actually Predicts Success

Through tracking hiring decisions and six-month performance reviews: the interview signals that best predicted on-the-job success were:

Code review ability: giving the candidate code to review and discussing what they would improve. This tests: reading comprehension (understanding unfamiliar code), quality standards (what they notice), communication (how they articulate feedback), and pragmatism (do they focus on important issues or nitpick style?).

Pair programming on a real problem: work together on an actual task from the codebase. This tests: collaboration (how they communicate while working), learning speed (how quickly they understand unfamiliar code), problem-solving approach (methodical vs chaotic), and coding fluency (can they translate thoughts to working code?).

System design discussion: describe a real system you are building and ask them to design it. This tests: architectural thinking, trade-off reasoning, experience with real systems, and communication of complex ideas.

What I Look For as an Interviewer

Technical competence: can they write working code at a reasonable pace? Not perfect code — working code that solves the problem and can be refactored later.

Communication: can they explain their thinking? When they are stuck, do they articulate why? Can they ask clarifying questions? Communication matters because software development is a team activity.

Debugging approach: when their code does not work, how do they debug? Systematic approaches (check inputs, add logging, isolate the problem) predict better job performance than "stare at the code and hope to see the bug."

Intellectual honesty: when they do not know something, do they say so? Or do they guess and pretend confidence? The best developers say "I do not know, but here is how I would find out."

What Impresses Me as a Candidate

Clear problem statement: "Here is the problem we want you to solve, here is the context, and here is what success looks like." Not ambiguous puzzles where I have to guess what you want.

Realistic environment: IDE access, documentation access, and the ability to search for syntax. Nobody memorizes API signatures. Testing memorization is testing the wrong thing.

Relevant problems: tasks that resemble actual work at the company. If I am applying for a frontend role, show me a frontend problem — not a graph algorithm.

Feedback regardless of outcome: a brief email explaining why I did not get the role helps me improve. "We went with another candidate" tells me nothing.

My Interview Format (As a Hiring Manager)

I use a three-stage process:

Stage 1 — Async take-home (2-3 hours): a realistic task that resembles work at our company. Build a small feature, review a PR, or design a system. The candidate does this on their own time with full IDE and internet access. I evaluate: code quality, problem-solving, and communication (in their README or PR description).

Stage 2 — Pair programming (45 minutes): work together on extending their take-home or tackling a new small problem. I observe: how they collaborate, ask questions, handle feedback, and debug issues.

Stage 3 — System design and culture (45 minutes): discuss a system design problem relevant to our work. Then non-technical conversation about work style, team preferences, and career goals.

Total candidate time: about 4-5 hours including the take-home. This is respectful of their time while giving us enough signal.

Preparing for Interviews (As a Candidate)

What actually helps: build real projects (the best preparation is consistent coding practice on real problems), practice explaining your work (describe past projects, technical decisions, and their trade-offs), prepare questions (thoughtful questions about the team, codebase, and challenges demonstrate genuine interest), and review fundamentals (not leetcode — but understand complexity, common patterns, and your framework's internals).

What wastes time: grinding 500 leetcode problems (unless the company specifically uses that format), memorizing obscure language trivia, and practicing "behavioral question" scripts (authenticity is obvious).

Red Flags When Being Interviewed

The company that: asks you to solve algorithm puzzles for a CRUD web development role (misaligned assessment), requires 8+ hours of unpaid take-home work (disrespectful of your time), cannot clearly describe what the job involves (they do not know what they need), has interviewers who are dismissive or rude (culture indicator), or ghosts you after multiple rounds (disrespectful and indicative of organizational dysfunction).

These red flags predict: a company that does not respect developers, has poor internal processes, or does not know what good looks like.

Red Flags When Interviewing Candidates

The candidate who: cannot explain their own resume projects in depth (potential resume inflation), becomes defensive when asked clarifying questions (difficulty receiving feedback), writes code that works but cannot explain why it works (memorization without understanding), or speaks negatively about every previous employer (pattern of externalizing blame).

Making Interviews Better

For companies: use realistic assessments that test relevant skills, respect candidate time (no 10-hour take-homes), provide feedback to all candidates, pay for significant take-home work (over 3 hours), and make the process transparent (explain stages, timeline, and evaluation criteria upfront).

For candidates: be honest about your experience level, ask questions that help you evaluate the company (it is mutual evaluation), follow up professionally regardless of outcome, and remember that interview performance is a skill separate from engineering skill — practice both.

The Uncomfortable Truth

Interviews are imperfect. The best interview process still misses great candidates and occasionally hires poor fits. The goal is not perfection — it is improving the signal-to-noise ratio.

The best predictor of job success is: past demonstration of similar work. Portfolio projects, open-source contributions, previous job performance, and recommendations from colleagues who worked with the candidate daily. Interviews can only approximate these signals in a limited timeframe.

Use interviews to: verify that the candidate can do the work (basic competence), evaluate collaboration style (cultural fit), and assess communication and problem-solving approach. Do not use interviews to: rank candidates against each other on artificial problems or test knowledge that can be learned in the first week on the job.