The Pair Programming Interview
Why Leetcode & what works for whiteboard interviews might fail you
Welcome, Avatar!
First off, a special thank you to the readers who pay to make this newsletter possible.
Your kind words, success stories, and support go a long way.
– Fullstack
Some have asked for tactics on interviews and getting hired.
Today, your wish is granted!
Specifically, we’ll be looking at a specific type of coding interview becoming more prominent at big tech firms since 2020: the pair programming interview.
There are many nuances around how to perform well.
If your only prep is grinding through Cracking the Coding Interview 6th Edition and all of Leetcode, then you might be in for a surprise.
There are a lot of critical tactics you need to nail a pair programming interview beyond your actual coding solution.
Even for autists like you, the nuance of the pair programming interview can be cracked.
Success is yours to grasp.
Soon, your only worry will be which offer letter to sign.
Evolution of the Coding Interview
Interviews in the tech industry have evolved over the decades.
Hiring bad talent is costly.
This has incentivized continued experimentation on format.
First, there were question & answer interviews. A casual discussion with an engineer or hiring manager.
While this may work for some jobs, they were deemed insufficient in evaluating coders. How could you judge someone’s technical talent from just Q&A?
This led to the whiteboard coding interview.
Candidates were given a canvas to flex their coding chops against an often computer science-y algorithms or data structures problem. Think reversing a binary search tree or writing the merge sort algorithm.
While these whiteboard interviews did provide some signal on coding abilities, they had some downsides.
Whiteboard style algo interviews can be gamed.
Given the traditionally more predictable set of question material, anyone who grinded through problem sets from Cracking the Coding Interview 6th Edition or Leetcode could perform well IF the question matched what they had practiced.
Practice isn’t fool proof though.
Candidates who couldn’t think on their feet and tried to rely on rote regurgitation could still be lured in by questions which initially look like trivial Leetcode classics, but then have a twist which breaks the memorized solution.
Hook, line, and sink’er.
The whiteboard algo interviews model setup a cat & mouse game of coming up with more and more obscure questions which hadn’t yet been leaked to study books or Leetcode.
The hiring signal from whiteboard coding interviews often turned out to have significant error bars.
Some candidates who performed well from their practice, turned out to be far less effective at thinking on their feet once in the job.
Other candidates, who performed poorly at a whiteboard away from their keyboard, would have performed excellently in the actual job, where engineers can take full advantage of IDE code editors, Google, Stack Overflow, language documentation, and even AI like ChatGPT.
The high false positive and false negative rate of whiteboard CS heavy algo interviews helps to explain the selection biases of Google, Microsoft, and other companies which rely on them.
Employees could be superb at abstract algo or CS problems but fail to be productive or effective when tasked with shipping a compelling product to customers.
Other companies have now experimented and adopted a new interviewing model: the pair programming interview.
What is Pair Programming?
Pair programming as a concept is fairly self-explanatory.
Instead of one person sitting at a computer writing code, two (or more) will.
While this can intuitively seem less efficient, two brains on the same task can lead to surprising synergy.
Pair programming can be especially useful as seen in the following arrangements:
Sr dev with Jr dev: perfect setting for mentorship, knowledge & productivity transfer
Debugging a hard bug or SEV outage: multiple engineers in the same call can sometimes collaboratively spot the bug and come up with a fix faster
New technology: an engineer with experience in a new technology can help others ramp up by coding a new part together
The Pair Programming Interview
For pair programming interviews, the goal is for the experience to be similar to that of actual pair programming with colleagues during a regular day of work.
Like during a regular day of work, interview candidates are often given access to an IDE (with code completion), Google, Stack Overflow, language documentation, and even ChatGPT to help simulate the environment of a regular day at work.
For interviews, this pair programming model offers some additional signal which is harder to get from whiteboard coding interviews.
Specifically, as an interviewer I am looking for the following signal which I incorporate in my final written candidate review submitted after the interview.
Productivity: At a keyboard and with an IDE, you quickly get the sense of the candidate’s real world capabilities. There’s no intermediary entropy to the signal introduced by asking candidates to write code that can compile on a whiteboard – something that nearly never happens in the job.
Unblocking Collaboration: With both interviewer and candidate having keyboard access, you can quickly get a sense of how candidate respond to feedback and can even step in to help fix bugs, share pre-written test fixtures to speed up the process, or otherwise help unblock the candidate as they move towards a working solution.
Problem Solving: Since candidates have access to IDE and internet, the gotcha CS algo questions popular with whiteboard interviews are less impressive. You can just go copy the top comment in Stack Overflow for your merge sort algo, write a test, and you’re done. Not impressive.
Instead of effective lowest common denominator question filtering, pair programming questions often have a much wider domain and variety to see how candidates think on their feet when given new technical primitives (web sockets) or business domain modeling questions. These questions can either be obscure or be more practical.
Across a few interviews the hiring committe can get much better signal on how they handle different more diverse questions than simple 3–5 classic algo questions.
Debugging & Troubleshooting: Since the candidate has a full IDE, they can actually run their code. The full REPL loop is at their fingertips, like it would be at work.
This means, when they write bugs or errors, you can see how they react when it fails on run. Do they calmly work through line by line to find the fix? Do they frantically add println statements everywhere? This is the behavior that will be present at work, so it is judged carefully.
Code Maintainability: In a full IDE, there is less tolerance for sloppy variable names, code organization, and haphazard documentation.
While easy to let slide on a whiteboard where refactors are harder, in an IDE: renaming variables, rewriting documentation, and refactoring methods is possible, some would say easy, and thus expected.
If you don’t at least verbalize that you’re thinking of doing these improvements, even if you run out of time to do them in the interview, red flag.
Structure & Overview
What does a pair programming interview look like in practice?
Well it likely has a structure as follows:
10m: Intros and ice-breaker questions on past experience, past technical stack, why you want to work at the company
“why you want to work at the company” is one you should always prepare for. Show that you’ve done some research on the company and products. Come up with some compelling emotional tie in to show how much of a “believer” and “company man” you’d be in the company mission if you got hired.
45m Pair Programming Question
The question will be shared, some will be multi-part, and sometimes starter code or test data objects copied over to get you started.
Stay aware of the time, but anxiety is a bad look. Calm, collected, problem solving, even if you’re not as fast, can be rewarded more highly than some hysterical candidate who gets one extra part completed.
Talk through what you’re thinking, issues you run into, different approaches you’re considering, why you’ve chosen this path forward.
Ask the interviewer clarifying questions on the problem space, acceptable short cuts or first iteration solutions.
5m: Questions for the Interviewer
Candidate is given the chance to ask the interview questions
Again, a good opportunity to show you’ve done some research on the company, products, and ask some thoughtful questions about eng culture…etc
How to nail first impressions
Speaking frankly, I usually have a gut feeling of how the interview is going to go within the first 10 mins of the question section.
And honestly, rarely does my view on the candidate changes over the next 40 minutes.
Your initial impressions matter a lot.
Stay calm as you read through initial test fixtures and grasp the problem. Re-read anything given 2–3 times before asking follow up questions.
Candidates frantically barking out questions when they clearly haven’t read or parsed the given prompt is a red flag. That candidate would risk being an annoying future colleague who would be unable to solve their own problems by reading.
Once you’ve read everything a few times, ask follow up questions to clarify your understanding. Jumping straight into your implementation and starting to build the wrong solution is a red flag. Only move on once you feel you have a solid understanding of the problem space.
Convert any given test fixtures to your language or create an example yourself.
Figure out an initial code structure for your solution. Setup a test bed or main function.
Pair programming platforms aren’t Google Docs. You can run your code! Take full advantage of it. Iterate on your implementation and re-run your code frequently to see that you’re making progress. Don’t wait until 50 minutes in to run your code for the first time.
Talk through what you’re thinking and writing. The interviewer can’t know that you’re smartly wrestling with tradeoffs, considering refactors, realizing mistakes, or thinking ahead to future improvements if you’re silently typing away. Verbalizing throughout your interview factors heavily into communication and collaboration review scores.
The above tactics should help you make a steller first impression in the first 20 minutes of your interview.
With a good impression, the interviewer will unconsciously grant you the benefit of the doubt and be more helpful and generous than if you started rough but turned it around by the end.
For the rest of the interview, you’ll want the following tactics:
Some companies let you use Google, Stack Overflow, language documentation, or other resources during your interview. If you jump out of the pair programming tab to do research, verbalize and tell the interviewer what you’re looking up so they don’t think you’re just silently starting at the screen.
If you get stuck, stay calm.
Spend a minute talking through why you think you’re stuck and rubber duck through what you know and what you are stuck on. In verbalizing it through once, you often will stumble across the solution you need. Only after talking it through once out loud should you ask the interviewer for help to unblock. Show the interviewer that you aren’t going to be a barnacle on their ass if you get hired, always asking for help fixing your own bugs.
Obviously, collaboration is great, most colleagues are happy to help each other. But, you need to constantly work to increase the threshold of “stuckness” that you reach out to others for. Get better. You’ll be less annoying, more productive, and can help more inexperienced employees which generates “mentorship” and “team building” promo packet evidence.
If you don’t generally feel confident in a language and in your problem solving skills, do Leetcode or other practice questions. You should get to the point where you can handle whatever they throw at you. Over the course of the hour, work through towards a working, inline documented, maintainable, tested, well communicated solution.
3–5 minutes before the end of the interview, there will usually be time for questions. This is your time to interview the interviewers. Prepare some questions. Do some research on the company and its eng culture. Do they have an engineering blog? Publish OSS libraries? Have they been in hot water over their work culture? Work/life balance? Interviewer’s favorite, least favorite part of the job? Come up with a few good questions so you can better understand if you really want this job.
Go back and re-read the above.
If you internalize them and consistently apply them, there’s little reason why you can’t go get top tier software engineering jobs very quickly.
Get past fear by getting better
Work on the above skills, practice in interviews, repeat, and you will soon have a new problem.
You’ll be stuck choosing between so many high paid offers to places you want to work.
Get over your fears by getting better.
Let me know how your next interview goes applying these tactics.
If you want the critical tactics for getting promoted quickly once you’re hired, you’re going to want to become a paid subscriber.
An absolute guidebook of proven tactics continues to grow in the archives.
This blog has already gotten many colleagues and anons promoted. Do you want to join their ranks with your own success story?
Once you’ve got your promotions locked down, it’ll be time to switch that KVM switch and build wifi-money during your day job.
If you want to achieve BowTied Bull Step 1 (high income from your career in tech), then you’ll probably want to subscribe.
A coffee a month for proven tactics and strategies to land your next promo faster… that sounds like its worth the price of admission.
My colleagues smiling at their bigger paychecks after following my advice and getting early promotions certainly seem to think so.
There’s a lot more we need to cover if you’re going to make it.
Stay toon’d.
- BowTied Fullstack
Some links to books or products are affiliate links which help support the continued publishing of this newsletter.