I have now solved algorithms for interviews or mock interviews in several different ways. There's the classic in person, where you've got a whiteboard and a marker and that's it. Then, there's a remote interview where you are working with someone in a shared IDE. Finally, I have had more than one job send me an assessment to complete that involved solving an algorithm in under a time limit on my own, where I simply turn in the code at the end. Each of these is a very different experience from the others, and y'all, I have preferences and opinions.
Firstly I'll describe each experience - and along the way I'm sure you'll gather where I stand on each. First, there's the traditional whiteboard interview. Here, you are given a challenge and a whiteboard and a marker. I've done this several times, mostly in practice interviews. The interviewers are there, and while it varies greatly by the person how much they'll stay silent and how much they'll treat it like pair programming, you can very much interact with them if needed - in fact that is encouraged. You should ask questions and talk out loud about your process. That's why you're there - not so much to solve the problem, but to demonstrate how you work.
Next, there's working with the interviewer remotely - say over a zoom call on a shared IDE. I had to do this this week, because thanks to the Covid-19 panic, the company had moved all on-site interviews remote. This version is a bit awkward, but it's doable. White-boarding out your ideas isn't really an option, and as much as white-boarding can seem awkward, it's actually a great way to be able to easily throw up your pseudocode and ideas. There's not a great way to do that over a shared IDE - things feel more formal, and there's not the loose creative space that handwriting and arrow drawing etc allows. In my experience this leads to committing to actual code too early, and can stifle some of your more creative thinking. There are also pros of course, mainly that the code really is right there, so you can test much more easily.
Lastly, there's the version that could hardly even be called an interview - just completing an algorithm challenge and submitting your results online. I will be honest - I am not a fan of this method. I had to do it this way for interview rounds/application processes with a couple different companies in the last couple of weeks, and I would not recommend it. When you are interacting with a person, you can bounce ideas out loud, you can gauge their reactions, they can give you hints or even just gentle nudges down the right path. As is, you're stuck with only your own brain, and the time limit associated can lead to some real panic and shut down. Notably, it is much harder to convey your process and work style this way. You can leave notes for the reviewer to read online, but that both takes away from your time limit to actually solve the problem, and is not as clear or communicative as an in person conversation. The result is that it's both harder to complete and harder to show a true reflection of your ability.
Whether or not algorithms are an appropriate way to interview someone in the first place is an entirely different argument, one I also have opinions about... But now is not the time. This has been a run down of my impressions of these different options... if I'm honest, perhaps it has been a rant.
Top comments (0)