ReferenceSoft Skills

Interview Playbook

Technical skills get you in the door. These soft skills determine whether you close the deal.

Before You Type (2-3 min)

Say This

  • "Let me make sure I understand the requirements..."
  • "What should happen if the input is empty?"
  • "Should I handle error states, or focus on the happy path?"
  • "Is there a specific data structure you'd like me to use?"
  • "Let me talk through my approach before I start coding..."

Avoid This

  • Immediately start typing without discussing
  • "I think I know what you want..." (then building wrong thing)
  • Assuming requirements that weren't stated
  • Asking zero clarifying questions
  • Spending 10+ minutes asking questions

The Clarifying Question Sweet Spot

Ask 3-5 targeted questions. This shows you think before you code, but don't overdo it. Great questions reveal edge cases the interviewer wants you to consider. If they say "don't worry about that for now," you've shown good instincts without wasting time.

Skeleton-First Approach

Before writing any real logic, lay out the structure with TODO comments. This gives you a roadmap and shows the interviewer your thought process.

skeleton-first.py
1def process_order(order_data):
2    # TODO: Validate input data
3

4    # TODO: Check inventory availability
5

6    # TODO: Calculate pricing with discounts
7

8    # TODO: Process payment
9

10    # TODO: Update inventory
11

12    # TODO: Send confirmation
13

14    return result

Why This Works (Even If You Don't Finish)

  • Shows you can break down complex problems into steps
  • Interviewer sees your mental model of the solution
  • Easy to discuss tradeoffs: "I'd implement this part next..."
  • Partial credit for demonstrating the right approach
  • Reduces blank-page anxiety - you always have something to work on

Talking While Coding

Good Phrases

  • "I'm creating this function to..."
  • "This handles the case where..."
  • "I'm choosing X over Y because..."
  • "Let me add error handling for..."
  • "This could be optimized later by..."

When to Pause

  • Complex logic that needs focus
  • Debugging a tricky issue
  • Remembering exact syntax
  • "Let me think for a moment..."
  • "Bear with me while I work this out..."

Avoid

  • Complete silence for 5+ minutes
  • Narrating every keystroke
  • Apologizing constantly
  • "I'm so bad at this..."
  • Excessive filler words

The 30-Second Rule

If you've been silent for 30 seconds, say something. Even "I'm thinking about how to handle the edge case where..." keeps the interviewer engaged and shows your thought process.

When You're Stuck

1

Say It Out Loud

"I'm stuck on how to connect these two pieces. I know I need to transform the data, but I'm not sure of the best approach..."

2

Write Pseudocode

If you can't remember exact syntax, write what you mean in comments. "I'd use a dictionary here to track seen values..."

3

Ask Strategically

"I'm considering two approaches: A or B. A is simpler but B handles edge cases better. Which direction would you prefer I explore?"

Don't Spin Silently

The worst thing you can do is stare at your screen in silence. Interviewers can't help you if they don't know where you're stuck. They're often looking for an excuse to give hints - give them that opening by verbalizing your blocker.

Time Management

For a typical 45-minute coding session, aim for this distribution:

25%
50%
25%
~11 min
~22 min
~11 min

Get It Working

First 25% - Clarify requirements, plan approach, get basic structure in place.

  • - Ask clarifying questions
  • - Write skeleton/pseudocode
  • - Set up basic structure

Core Features

Middle 50% - Implement the main functionality. This is where most coding happens.

  • - Implement happy path
  • - Handle main edge cases
  • - Get it running end-to-end

Polish & Demo

Final 25% - Clean up, handle remaining edge cases, prepare to demo.

  • - Add error handling
  • - Clean up code
  • - Prepare walkthrough

The Perfection Trap

Don't spend 30 minutes perfecting one component while leaving others unstarted. A working end-to-end solution with rough edges beats a perfect half-solution. Interviewers want to see you can ship, not that you can polish forever.

Finishing Strong

Wrap-Up Script

  1. 1"Let me walk you through what I built..." (30-second overview)
  2. 2"Here's a quick demo..." (show it working)
  3. 3"Given more time, I would..." (shows you know it's not perfect)
  4. 4"I made this tradeoff because..." (shows intentional decisions)
  5. 5"Any questions about my approach?" (invites dialogue)

Demo Like This

  • Show the happy path first, then edge cases
  • Explain what each part does as you demo
  • Point out where you'd add improvements
  • Be honest about what doesn't work yet
  • Thank them for the interesting problem

Avoid This

  • "Sorry it's not finished..." (they know)
  • Rushing through without explanation
  • Pointing out every flaw unprompted
  • Making excuses for your solution
  • Ending abruptly without summary

The Mindset Shift

You're not defending your code - you're having a technical discussion with a future colleague. They want to see how you think, communicate, and collaborate. A candidate who handles feedback gracefully and thinks out loud is more hireable than one who writes perfect code in silence.

Quick Reference Checklist

Before Starting

  • Clarify requirements
  • Ask about edge cases
  • Discuss approach briefly
  • Confirm expected output

While Coding

  • Think out loud
  • Write skeleton first
  • Handle happy path
  • Add error handling

Time Checks

  • 25% - Have a plan
  • 50% - Core working
  • 75% - Edge cases
  • 100% - Ready to demo

Finishing

  • Walk through solution
  • Demo functionality
  • Discuss tradeoffs
  • Mention improvements