Common Mistakes When Hiring Software Engineers

This might be an unpopular opinion, but I wouldn't want to work at a company that doesn't value whiteboarding or doesn't know how to conduct a whiteboard interview. Whiteboards are excellent tools for conveying abstract ideas, and physically, they're easier to collaborate on. Pen and paper is difficult to observe and contribute as a collaborator; so me, that feels more like I'm proctoring an exam instead of doodling with a candidate. If I wanted to proctor an exam that's an approximation of the work environment, I'd just ask you to bring in a laptop and HDMI dongle.

During an on-site, I'm very much evaluating abstract and interpersonal skills. I'm evaluating how well they communicate, how well our personalities mesh when collaborating, and how well they solve our engineering problems. I'm not evaluating how well they can code; they've already been screened for that before the on-site, typically on a Coderpad in the comfort of their own home with whatever language, tools, and resources they prefer.

I would argue that some of your "solutions" to these "common mistakes" are just as bad as the initial mistakes themselves.

Whiteboarding: Why would you replace a whiteboard with a pen and paper? Many programmers have hardly touched a pen and paper in years. They live and die by their keyboards and monitors. Would you take a master carpenter's tools away and then judge them on their ability to build something using nothing but a spoon? Maybe we should give people a real world problem (not a trick problem), and let them solve it using their tools of choice?

Staged Collaboration: "Design your interview question to be missing important details. This will give candidates the opportunity to discover the need for these details when they get to them and ask for them at that time. If the candidate never asks questions, great! You just identified a serious red flag you would have been hard pressed to find otherwise."

When someone is in an interview under pressure, they are often very nervous. They are being judged on how quickly they can solve a problem, and you (as the test giver) are the authority in the room. Focus tends to narrow under stress. This means many people will simply take your questions at face value. But it sounds like you are essentially penalizing them for not being cynical enough, and you are penalizing them for not understanding that your trick questions are trick questions. That doesn't really seem fair. It sounds like a good way to weed out timid candidates (and potentially lose out on a very talented engineer), though.

Conversational Relationships: I agree with this

Open-Ended Discovery: I agree with this

> What are some traits shared by the best programmers you know? I'd wager things like introversion, thoughtfulness and detail orientation show up on your list.

I would not put introversion on that list. Great engineers can be either extroverted or introverted. It is irrelevant to quality of coding.

> Whiteboarding

Stop using the term "whiteboarding". Judging from the confusion the discussion here, some hate it because it means writing code at a whiteboard (which is obviously a horrible idea) while some love it because they think of discussing some conceptual issues while drawing arrows and waving arms (which is great).

Just say what you mean. Whiteboards aren't a problem if you use them right.

> Better yet, design your interview question to be missing important details. This will give candidates the opportunity to discover the need for these details when they get to them and ask for them at that time. If the candidate never asks questions, great! You just identified a serious red flag you would have been hard pressed to find otherwise.

This is just another way to ask trick questions. You are purposely leaving out important information. I don't think this is a bad thing, but it is stressful to answer these questions.

I haven't asked a whiteboarding question to candidates in years. In fact, the only questions I ask are based on real-world problems I ran into that can be solved (or at least started) in an hour and can evolve over time.

One way to source these questions is to observe whenever you have a small product ticket that requires some algorithmic or systems design complexity. Strip away all of the proprietary data and IP and see if you can create a problem around the real-world thing you experienced. If you can constrain it to a solution in 10-25 lines that takes less than an hour to create, you can feel good knowing you've got a real problem with a real solution to give to your candidates.

Also: let them use Stack Overflow/MDN/Google. We use it everyday at work, why should you hold that back from your candidates?

>Whiteboarding is a practice borne from what i can only assume is equal parts social ignorance and intellectual dick-waving.

This article nails it precisely. After interviewing dozens and dozens of devs (as a peer), the sweet spot is still demonstrating coding ability, but not on a whiteboard.

Load a repl (like repl.it) in one browser tab, and in another have MDN or whatever official docs.

Give a unique/novel challenge, but keep it simple without any trick questions or brain puzzles. Be forgiving if candidate overlooks something obvious.

Once we settled on this, much fewer post-hire surprises.

I feel like the whiteboard coding interview happens not because we want to put them in a hot seat and create a reality show, but rather that there is no other "obvious" way to test their coding skill in a short time.

Usually with whiteboard code interviews I focus on concepts and ability to break down and solve a problem, and don't focus on syntax or other things that I know they could figure out in 2 seconds from Googling. For example in C or C++:

* While I won't care if they forgot which #include was needed for a particular function or if they invent their own hypothetical string class with usual plausible methods, or if they wrote "v.append" instead of the correct "v.push_back", it is important to understand when and why memory leaks happen.

* It's reasonable to assume certain components exist in order to piece them together to create a higher-level task. If the task is to multiplex data from 3 sockets and de-multiplex them on the other side, for instance, it's reasonable to assume that a good socket library exists and assume some methods; I'm more interested in the multiplexing logic.

That said, I'd love more feedback about how to structure an interview in a better way to test software engineering ability. A lot of people say "whiteboard interviews are bad" -- and I agree -- but they don't really offer a good alternative. I'd love to hear what the good alternatives are.

From the article:

Whiteboarding is a practice borne from what i can only assume is equal parts social ignorance and intellectual dick-waving.

Another helpful approach to gauging candidates thought process is to stage your interview problems so there are a series of asks and check-ins. Breaking large problems into Ask, Check-in, Review, Repeat allows you to keep each info block confined

We do the thing in the 2nd paragraph. We use the thing in the 1st paragraph to do it. So there's something that doesn't quite add up for me, reading this.

Never ask trick questions or intentionally leave critical information out of a question or problem. Let them ask you questions about any problem you give them to solve.

If you are going to ask them to code, give them a computer with Internet access. Since we look stuff up all of the time in real life, let them do that during the interview. Then talk to them about their answer. If they have a github account, talk to them about what the have in their. Check it out, and have them walk you through what they code does.

Interviewing is hard, being interviewed is harder, try to make it as easy and productive as possible.

Software developers come in all sorts. Some are gregarious and outgoing. Some are introverted and shy. Some like being the star while others like being in the shadow. Being an effective software developer can manifest in any of those types of people.

As someone with pretty strong social anxiety, I can nod my head at some of the points in this (except the pen and paper bit...trying to write out something with a pen is torturous), but at the same time I realize my quirks shouldn't define the process. I do wish it was more of a "choose your own adventure" process where you could select the path that will best allow you to demonstrate your values.

I like being asked to solve a problem, by email. I bang out a solution, send it in, and provide responses for queries. That's a process I love, and it has worked great for consulting gigs. Those companies that do multiple phone screens, and then a show and tell in front of a group on a whiteboard I just pass on, however, and they are selecting for sales qualities. If you're hiring for technical sales or an evangelist it might be perfectly suited, but it does filter out a lot of people who might be perfect for the role. On the flip side, gearing a process purely for the socially anxious makes the same mistake in the other direction.

Imho whiteboarding(solve this trick question by using well known algo/datastruct...) was introduced because when hiring fresh grads/no-experience people, one can not expect them to know enough about any language or any domain related problem an experienced person can solve, so only way to check if they are good learners is asking ds and algo they learned at college which they still retain or revised recently added with their favorite language of choice in basic form. Unfortunately, this has spilled over to experienced hires as well & gained the bad rep as experienced people retain their memory/experience of solving a real world problem related to the job at hand rather than ds and algo they learned long time ago. Depending on which type is being hired the interview could be adjusted. So probably if an applicant has no experience at all, give them ds and algo problems, but if the candidate has some experience, focus on that may be and go deep from there.

I generally agree with a lot of what's suggested - incremental problems, open-ended questions, conversational tone - but don't think this post describes particularly effective ways of doing them. And while I disagree on the value of introversion as a indicator of engineering skill, the suggestions here seem worse for introverts than the "standard" google-type interview, IMO.

Leaving information out, or railroading apparent open-ended questions down to a single thing (like in the SQL example) could easily frustrate and confuse someone, especially if they're not comfortable with challenging an interviewer, but feel more like "they asked me about this thing, but then left out a bunch of important details" or "they asked me about performance overall but then didn't care about anything I knew about performance outside of SQL."

I agree that whiteboarding is terrible but this doesn't seem like much of a fix.

The issue with whiteboarding (or pen and paper) is that programmers use editors or IDEs. We had good luck just moving interviews into a clean slate editor - candidates felt more at ease with more normal tooling.

The issue is not so much white boarding as that is a broad term like others have mentioned. Using a whiteboard is a common part of many jobs. But it is not often that we have to write 100% correct code that compiles on whiteboards quickly.

What whiteboards should be testing for is problem solving, and whether a candidate can use a whiteboard to illustrate, communicate and collaborate towards solving a problem.

So if the question becomes whether or not problem solving should be evaluated, i think the answer is obviously yes, and algorithms have a place here. However, algorithms should not be the ONLY way to evaluate this attribute.

Question to the HN crowd here: What are successful strategies that scale with increased applicants? It seem relatively simple to determine deep/wide conversational knowledge once someone's face to face with the team, but this takes the time of the team. There's also significant time that needs to be spent figuring out who should take up the engineering team's time. How is that done?

When you want to hire a senior software developer you are the one being interviewed.

If we step back and think about software development and interviews, we might see two high-level ideas.

First - the interview should probably be a lot like how work is done by the employer. The details of the requirements probably are murky, but they'll be clarified later. The deadline may or may not be arbitrary. The goals are different - you don't need a useful, profitable end product. You need a demonstration of the ability to make such a thing (within the limitations imposed by the employer.)

Second - to be kind to your fellow human taking the interview, you shouldn't place them under undue stress. I enjoy David Rock's work on the brain and the chemical processes in our bodies. (I won't attempt to speak on them nearly as eloquently as the original author.) In short, there are five major things that affect our brains in a very similar way to immediate physical danger; the S.C.A.R.F. acronym, for Status, Certainty, Autonomy, Relatedness and Fairness. In an ideal workplace, and an ideal interview, you wouldn't be threatening those things more than you need to.

Status is already threatened in a way - the interviewee likely desires the job to improve their status in life. But you shouldn't be forcing inferiority down their throat.

Certainty - well this is almost in direct opposition to the reality of doing work in many workplaces, but it shouldn't be. In this case, what you're asking the interviewee to do and to demonstrate should be laid out in clear, understandable terms. You should try to remove some of the barriers to getting them to focus on the core abilities you need them to demonstrate. Of course, understanding communication is a valid skill to test, and you might hope to simulate your real workplace environment by being vague and using insider terminology, but you also have to remember that they have 0 days on the job in your particular place of employ. So they have yet to learn shared terminology. Knowing esoteric insider information shouldn't be tested!

Autonomy - while the above means you should be giving hints as to what you want them to do, and perhaps some suggestion of methodology, they should still feel like they are in control of their choices. You're testing for an ability to reach a conclusion, and you will observe the methods used to get there, but you shouldn't remove all sense of self-direction.

Relatedness - this is controversial, because we've always relied on "people like us" in interviews, only too well. You should want to connect interviewee and interviewer on some shared values and interests, but de-emphasize any focus on likeness determined by birth lottery. That is, they should feel like they can fit in, regardless of superficial differences!

Fairness - this just makes me think about the potential pitfalls. Openly mentioning "better" candidates, your buddy, your niece that's applying, doing a group interview and showing favoritism. Maybe someone else can think about this one and offer up suggestions.

What do you think about applying the above mental framework to how you design and conduct interviews?