Pair Programming Interview: What Not To Do
Some anons find counter-examples useful, here’s some pitfalls to avoid
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
Last we met, I handed down a deep value guide on how to ace your next pair programming interview.
Old school Q&A interviews and mythic whiteboard interviews are on the decline. If you want the tactics for how to succeed in the new world, give it a read.
tl;dr you’ll need more than study books and Leetcode to get your next job.
Remember, these skills not only will help you get your next job, but conducting interviews is often part of any position. Get good at doing them, then giving them. It can even help your next promo.
As always, once you’ve got your job, then promotions locked down, it’ll be time to hit that KVM switch and build wifi-money during your day job.
For today, we continue to refine our understanding of interviews.
Some people need something to run towards, a positive example.
Others, need something to run away from, a negative example.
Today, we have some practical examples of what not to do in your pair programming interviews.
Make a good first impression
Clean up your room or add a virtual background.
Look presentable. Work out. Shower. Put on a nice shirt or blouse.
Be ready early so you are calm and collected by the time you login.
Prepare a good answer to “why do you want to work here?”
Prepare brief answers to “describe your last position” and “what tech stacks have you used”.
None of the above is rocket science, but so many candidates fumble early in their interview and kill their chances before they’ve even written a line of code.
Talking too little
Pair programming interviews are not collaboration sessions between peers.
But that doesn’t mean you can just silently code away with no consequence.
“Collaboration” is often one of the criteria that interviewers are collecting signal on.
So, make sure you are talking through: - what you’re thinking - what you’re coding - what you plan to do next - what you are blocked on - tradeoffs you’re considering
I’ve failed candidates who were silent the entire interview.
Remember, the job is not exclusively coding. Communication and collaboration is an equally important skill.
If you find this awkward, practice verbalizing out loud to yourself while doing practice problems.
Get past the awkwardness by yourself, then with an interviewer present it won’t feel so weird.
Talking too much
A notorious candidate I had would not stop talking.
I received multi-minute rambling lectures on typed vs dynamic languages, language test framework options, downsides to the annotation processing of the language…etc.
Instant fail.
If I’m annoyed by you during the interview, I will look for reasons to fail you.
I will do my sworn duty to the company (selfishly myself) to avoid hiring any candidate that would make my job worse if I had to work with them.
In social settings, do people seem to get bored when you talk?
Do you have friends that seem normal? How do they react to you?
Self-awareness is difficult but critical.
Find you if you are an annoying rambler. If you are, find a way to stop. For the sake of your career, and everyone who interacts with you.
Less is more.
Not asking clarifying questions
Asking questions is neither a sin nor sign of weakness.
Too many candidates seem afraid to ask clarifying questions.
They stumble ahead towards a solution, making silent assumptions along the way that back them into a corner come part 2 or 3 of the problem.
Just ask.
If you’re verbalizing through your thoughts, it’s easy to slip clarifying questions in to engage the interviewer and check that you’re assumptions are correct.
I routinely will correct or offer hints if people earnestly ask or check their assumptions.
It is what I’d expect in a colleague and is a positive signal in a candidate.
Don’t plead for help
If you feel like you’re truly stuck, don’t freak out.
Many a candidate I’ve failed who starts freaking out and then pleads with me, begging for a hint or the solution.
That is an approach for weak and feable losers.
You can do better, anon.
Instead of begging, rubber duck.
Rubber ducking stems from the phenomena where by in the act of formulating your thoughts to speak to a colleague about your problem, you often end up solving it. So, instead of wasting colleague’s time, talk to a rubber duck on your desk first and see if you can solve it yourself.
Rubber duck your problem in a calm voice.
Talk through any approaches you think won’t work, and any you think could maybe work.
If you’re still stuck but have remained calm and earnestly trying to find a solution, I will often give a hint or leading question to unblock you.
The interviewer is rarely some villain.
If you earn their respect, they will want to see you succeed and will often help you get there.
Not enough urgency to solve the problem
Some candidates are so satisfied with their rambling lectures or with “cleaning up their code” or writing “one more test case”, that they can blow the whole hour and look like a fool.
When you get your question, never assume that it is the only part. Most interview questions have multiple parts.
They may be new or often will build on the previous parts. This adds signal to see how you can adapt existing code to new requirements.
Without freaking out or getting stressed, keep an eye on the clock.
You are like an elite athlete, let the adrenaline keep you focused and performant.
You should not end up feeling surprised when the interviewer lets you know that the coding time is up and you can ask them any questions about the company or position.
Quickly work to get a working solution to the problem. Briefly talk through how you might clean it up or productionize it. Then wait for further instruction.
Have good questions for the interviewer
Show that you’re engaged.
Have a good answer for “why do you want to work here?”
Have good questions for the interviewer.
What is the best and worse part of the job?
What does a day in the life look like for you?
What is your favorite and least favorite part of the engineering culture?
How has the organization changed since you joined?
What worries you about the company trajectory?
Do you see yourself here in 5 years?
Under no circumstances should you end the interview early because you have no questions.
That shows that you are lazy and unengaged and are so low status that you will take any job.
Anyone who respects themselves will use the time to interview the company and figure out if it is a good match for them.
Act like an alpha gigachad candidate, interview the company.
Don’t be unhinged and give the interviewer feedback
You have to be a narcissist of epic proportions to think it is a good idea to berate the interviewer in the final Q&A time for something they did during the past hour.
And yet, I’ve had multiple candidates try and correct my interviewing style, complain I wasn’t engaged, didn’t help them, that I reflect poorly on the company.
Tough shit mate. Instant fail. And GFY.
I could care less what you think. I work here. You don’t. You want to to work here. Keep your feedback for your cats.
Before you accuse me for lacking empathy, I don’t care. But truly, I have deep empathy for candidates.
I’ve been in horrible interviews as a candidate where the interviewer gave the question as I stood at a whiteboard and then 55 minutes later looked up from their email to tell me I did it wrong and escort me out.
I’ve had embarrassingly weak resumes, a derth of experience, and faked my way through recruiters to fall on my face in interviews. It sucks.
But, it is the game. Get used to it.
I learned that I could complain, or I can learn to win. I chose to learn to win.
I multitask during interviews but still remain relatively engaged and give candidates an earnest shot at earning my positive feedback.
Unhinged candidates are red flags who I hope to never work with or inflict on any of my colleagues. Instant fail and I write very detailed negative feedback.
Be Better
While some of these sound outrageous, remember that under stress we all have parts of our personality and composure that can slip.
Work on your self-awareness so you can recognize when you’re feeling stressed, and manage it productively.
Maintaining composure and executing under pressure is how you will stand out at work too.
When everyone else is running around like a chicken with their head chopped off at the latest bug, outage, or SEV, people will remember how you step up calmly to get things under control.
Even if you ship a bug which breaks the user experience for 30 million customers, you can still flip that into a win on your next promo packet.
I did, and in an upcoming post you’ll get the tactics so you can too.
Until then, get hired, get promoted, then hit that KVM switch and build wifi-money during your day job.
You best believe that’s what I’m continuing to do this week.
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
For folks trying the newsletter out for free, I hope you get value from the free posts! There’s a lot of alpha there, and even more waiting for you if you join as a paid sub.
Want a few free months as a paid sub? Get your personal referral link and start ranking on the Leaderboard as others join from your recommendation.
You’ll earn free months, and you can feel good knowing you helped more people start to break free of their W2 slavery.
Learn more and get your referral link at the Leaderboard.
Some links to books or products are affiliate links which help support the continued publishing of this newsletter.