Hiring Without Whiteboards

Agreed.

It's always surprising to read people complaining about spending even 8 hours on a take-home problem in the comfort of their home, with no one looking over their shoulder, finished at their leisure. Meanwhile, anyone serious about applying to the same company wouldn't hesitate to take PTO and leave work to go on-site for a similar amount of time for an interview.

Apple did this in one of the sessions last time I interviewed there. They handed me a project in Xcode that had a number of bugs with varying degrees of difficulty — some caused crashes, others were UI glitches, etc. The assignment was to identify the problems and fix them. If you have more than a couple years’ experience the issues were pretty straightforward.

I really enjoyed this session, but I can see how it could be stressful to others.

I agree with this. I work at a FAANG that does whiteboard coding interviews (opinions my own, etc etc).

When I interview people, I give pretty straightforward questions. My goal is not to run some algorithm guessing game. If I'm interviewing for a senior FE position, I make sure they know enough about async patterns in JavaScript that I feel confident that they could build an event handler without dropping promises on the floor.

A back end position? Can they use (not implement, just use) a hashmap efficiently and do they think about boundary conditions in input sets (you'd be surprised how many people ignore punctuation when breaking sentences into words - they just do a split(' ') and call it a day.

This is really basic stuff. I'm always able to (a) filter out people who just need more time learning to code (or are too nervous to perform well, which is still a problem with even these whiteboard activities) and (b) prompt a discussion about engineering practices.

My criterion is simple: do I think I could see this person submitting code to my project without me needing to constantly fix what they write? It isn't about memorizing algos or anything.

Aaalso: I didn't study leetcode, and managed to get my job just fine. I know there's a reputation of the process being just algos, and I'm sure a lot of the interviews are. But not all of them, even at the FAANG.

I don't think you're crazy, but if their work and your work are detached enough from BFS and linked lists, why use them as the assessment criteria?

It's not really that difficult to make quotidian software engineering tasks into interview questions. I've at least seen it done successfully before.

More anecdotes: a nontrivial number of the "algorithmic trick" interviews I've done were questions I knew the answer to beforehand – and often the interviewer didn't care when I told them ("I just want to see how you think" or "Just show me how you'd code it" or sometimes even "OK, just tell me the solution and we'll move on to the next part"). What happens to the people who don't have the same background? Are they really less competent software engineers because their algs class didn't cover making a queue from two stacks?

We use a 3 step process, sans whiteboard: 1. First interview, the candidate interviews us. What market we serve, what our development processes are, what our technology stack is. If they express interest by being prepared and asking good questions, we send them home with

2. a programming task. Choose 1 of 5 tasks. The tasks are not abstract problems or puzzles, but come out of the designs we've implemented. We ask for 100 lines of code and not more than 2 hours. They take as much calendar time in days as they need, most have full time jobs, and let us know when you're done. The candidate then comes back, typically in 2 to 7 days and hosts a code review in front of our team. I give strict instructions before hand: The purpose of the review is to learn how they thought through the problem and how they solved it, not to criticize their style and approach.

3. If we decide we like them to this point, the third interview is with managers from other functions. How well does the candidate communicate, come across to non-developers, express interest in the company and role, etc. It's a check point to look for concerning weaknesses, as well as get buy in from the broader organization.

We like this approach because it allows the candidate to code in a much more natural environment. They can take the time they need and comfortably solve. No one spends their professional career coding on a white board. This approach so far has yielded excellent results. We ask developers how much time they took in the programming task and why they chose the one they solved. The programming task is telling, not in the quality of their code and how long they took, but how much did they get into it? We have had the range from candidates who did not complete it at all and opted out, to candidates who stumped 40 year veterans with elegant code. In every case, we learn how well they can express their thoughts, and importantly, their level of love for the discipline. This is as important to me as any other attribute.