I recently agreed to co-organize the Puget Sound* Programming in Python (PuPPy) Interview Practice Night. It has had much more attention than I expected and I’ve found that I’ve honed my message considerably; which is a benefit for me and my audience. This is a work in progress and I expect this will move in several different directions as we host an increasing number of events. However, I want to put this out there for groups that want to implement a similar practice paradigm. I’ll skip the discussion of finding locations and advertising. That will be entirely different for each group. Rather I will focus on my philosophy for the evening, starting with the problem as I see it.
A caveat I’d like to add is that this is not entirely my project, though I do get to be one of the two or three hands on the steering wheel. I have the impression that others involved with IPN have similar feelings but I can’t guarantee every event will be run the same way. I can guarantee that the events I host will be run this way and I’ll encourage the other hosts to adopt this philosophy.
Most whiteboard interviews seem to follow a pattern: A relatively new to the field developer** applies to a job; Now “Applicant,” this person is told there’s a tech interview scheduled; Applicant freaks out and deep dives into Cracking the Coding Interview; Applicant arrives and is put in front of one or more engineers who ask them to perform a coding exercise that is out of context (these typically lack a use case and are divorced from the tools of the software developer); Applicant’s mouth dries as they stammer and piece together some code on the board; Interviewer says “thanks for your time” and Applicant leaves, having no idea how they performed; Applicant (maybe) receives an email informing them that Company is not moving forward with the interview process.
Interview Practice Night hopes to develop the skill of performing a whiteboard interview. I want attendees to practice a nerve-wracking skill in front of relative strangers, but in a low-stakes environment. Ideally after a few attempts at coding in front of strangers, attendees will lose a lot of that performance anxiety. Our foundational texts are McDowell’s Cracking the Coding Interview as well as Elements of Programming Interviews in Python. Problems that attendees have encountered in technical interviews or on a code-challenge website are also encouraged (so long as the person bringing the problem has a reasonable path to solving their problem).
For the person writing, I encourage thinking out loud, writing out givens and assumptions, and pseudocoding. I understand that frequently the (un)stated goal of tech interviews is to learn how the applicant thinks and communicates about code. I encourage the person writing to work until they’re actually stuck, take a moment to think about their solution and if they can go no further, ask for a hint. I have heard both sides of this argument, but I’m of the opinion that: if I’m stuck on a problem, not moving forward doesn’t work in my favor; asking for help shows both an understanding of my abilities and their limitations; asking for help demonstrates that my ego is not more important than solving this problem; asking for help is what I would actually do in real life; and if asking for help is a mark against my candidacy for a job, that tells me a lot about the culture of the company in question.
For the people who are not writing, I strongly encourage them to act like they are the teammates of the person writing. We live in a world where professional code is written by a team; in real life teammates wouldn’t let the person at the whiteboard drown when they became stuck and they also wouldn’t let their teammate follow a wrong path (assuming the team identifies that the solution is heading in a non-optimal direction). I want the writer to solve the problem on their own if they’re able. But if teammates notice there’s a drop in production (written or spoken) I want the non-writers to ask if the writer wants a hint; or wants to share what’s happening in their internal dialog. If the team sees the writer moving in the wrong direction, I want the team to offer gentle encouragement back to a “correct” path. Much to my pleasant surprise, once a problem is “solved” I’ve witnessed great conversations about optimizing solutions and iterating on solutions to solve related, but different, problems.
Related Interview Skills
Whiteboarding is a useless skill if the applicant never gets to the room with the board and the pen. My future plans include résumé review, behavioral interview practice and remote coding interview practice. All of these initiatives are in parallel with whiteboarding; not everyone at a practice night will be participating in these events at the same time.
Résumé review is what it sounds like. The key here is to avoid a situation of “the blind leading the blind”. I can review your resume. But I haven’t looked at dozens or hundreds of resumes while trying to hire for an open position. Hiring managers and HR professionals can work with attendees to revise résumés, in particular looking for spelling and grammar errors that will turn off a potential employers. Ideally our professional volunteers will help “punch up” the document to make the verbiage more attractive to potential employers. In some cases, something as simple as rearranging the bullet points in a section can make it more enjoyable to read.
Behavioral interviewing is yet another skill that people don’t have a lot of opportunity to practice, outside of “throwaway” interviews (which is not an ideal situation for either side of the table). My vision for this is to have the interviewer ask STAR/”tell me about a time when” type of questions. The ‘interview” should last about ten minutes, with about five minutes for feedback. The interviewee will get practice with their storytelling, honing the details and narrative. The stories should only have the details needed to tell the story without meandering, but also avoiding “stories” that don’t offer any details (the dreaded monosyllabic answer to the open-ended question). In addition to narrative feedback, the interviewee should expect to learn about tics and distracting mannerisms ( “um…”, “…like…”, “… you know? …. you know?” as well as face touching, not making eye contact, etc.)
My dream for this project is to set up remote coding interviews. For many these are the worst scenario. The interview is conducted over the phone, which not only has the as-of-yet unsolved telephony issues but calls lack the non-verbal communication cues that we rely on. In addition, many people don’t have experience coding in a web-based IDE much less a shared web-based IDE. I would like to have the interviewer set up in one space with the interviewee in a separate space. The coding problem doesn’t have to be complex, this is a good use case for fizzbuzz or Fibonacci. The interviewee needs to practice with the interpreter/REPL and they should receive similar feedback as they would from a behavioral interview.
If you are in the Puget Sound region and would like to join us, please find the Interview Practice Night group through the PuPPy Meetup group, below.
Please bring this to your group and try it out. It can be your coding bootcamp, your CS cohort, the informal coding group you’re a part of. If you find this useful, please let me know. If you tried this and found a different method that worked really well for your group, let me know. Good luck out there.
“*” PuPPy understands there needs to be some poetic license taken with the acronym.
“**” It is my observation that mid- and senior-level developers do not face this same challenge. Often whiteboards, if they’re used at all, are used to write out ideas collaboratively during interviews that feel like chat sessions.