The Interview

Okay, I know. It’s not science, but let’s talk about something that is very important to the process of being any sort of technical worker or scientist. The Interview. This is important for just about… anyone, in fact, who is seeking a job. Not everyone is cut out to run their own business. I know I’m not and I am not afraid to admit it. Software engineering and computer science is frequently a collective effort to get stuff done. There are no more superheroes. There never were, in fact. That’s a myth. Bill Gates didn’t do it alone. Neither did Steve, Jobs and Wozniak, nor did Mark Zuckerberg. Sergei Brin and Larry Page didn’t either.

The reality for the vast majority of us is: we have to trade our labor and time for compensation.

So, we do that dread practice — the Interview. In this musing, I will be discussing primarily the Whiteboard Interview, something that is a lot of fun and harrowing all at the same time.

And I will admit up front — just like standardized exams and finals, I am quite awful at them. It is not that I don’t know my material, but if I don’t spend considerable time preparing myself mentally for them, I fall flat. I know of people who can walk into an interview and wow everyone. Other people can’t. And that is okay. Whether or not I am predisposed to being ‘bad’ at them due to ADHD… questionable diagnosis, I’m like most boys my age [90s kids] … where my rambunctiousness and need to exercise was mistaken for a cerebrophysical disorder that needed to be medicated… or I just prefer a more leisurely pace, I admit, for all my sternness and passion, I’m actually a more Type B personality. If I have to get up and do something, there needs to be a good reason for it. Or maybe I’m just plain lazy. But laziness is the Mother of Efficiency, so hah.

Whiteboard Interviews (Often Onsite)

So, let’s talk one of my pet peeves and the one interview format I actually do like. That’s right. I listed a pet peeve as something I like… The Whiteboard Interview. This is a very common practice. Many companies are also moving away from them now in favor of technical screens through LeetCode or HackerRank and take-home-coding interviews. I have some issues with that as well, which I will discuss later.

The Whiteboard Interview, alternatively, the Onsite, is the standard bearer, where you and an interviewer, or possibly a panel or interviewers, sit down or stand up and work through a problem to ensure you know your computer science fundamentals and can come up with a viable solution relatively quickly to a presented problem. The biggest benefit to this is that it actually measures your ability to problem solve under pressure, ask intelligent questions, and have a discussion with the interviewer so they can see how you think. The Whiteboard Interview can be anything from a single one on one chat to an all-day event where you work with multiple people across multiple teams or even the same team.

Now, the reason I have a pet peeve with them is the inherent unfairness/bias that can occur with them.

If you get an interviewer that is negatively predisposed to you, as I have in the past, for whatever reason, the odds of your success, even if you rock star, is pretty much nil. Some interviewers also, come from cultures, where rote memorization and perfection are expected, not how you think or how you arrive to your conclusion and this can definitely throw you. This is where I have often stumbled in the past. I will do quite well, get an interviewer that has a specific answer in mind, and will poo-poo anything that isn’t what they were thinking.

If they are this sort of interviewer and you like mergesort and they prefer quicksort? Well, you are probably dead in the water at that point. For those who do not know what merge and quicksorts are, these are two very popular and efficient sorting algorithms. I will go into some depth with them in a later post, but they’re used to sort fairly large, and I say fairly, because even they break down at certain orders of magnitude, arrays of data. Mergesort tends to break things down piece by individual piece, and merge it all back together, where as quicksort relies on pivots and re-arranging around that pivot. For most tasks, they’re fungible and equivalent. There are a few cases in very small and very large data sets where one trumps the other. For most use cases, they are pretty interchangeable in my experience.

This can make Whiteboarding a frustrating and ultimately negative experience for many aspirant developers and I’ve missed out on more than a few opportunities this way. I do not begrudge the companies I interviewed and did not do ‘well’, but it can be a disheartening experience. However, I do highly approve of Whiteboard Interviews for the simple fact that they are the simplest sanity test you can muster. And here’s why…

We currently have a glut of developers that have only a rudimentary understanding of computer science fundamentals, data structures, and algorithms. They’re often trained for the questions, but they do not understand the logic behind them. And I think the Whiteboard Interview often does a FANTASTIC job of weeding those people out. It’s not that they’re undeserving of jobs or development careers, but when interviewing for a major technical corporation, especially those that have mission critical directives where lives or billions of dollars may be at stake, ensuring your engineer has the fundamentals down cold, or at least understands them on more than a superficial level is very important. Many of these aforementioned developers are fantastic full-stack developers and software engineers in their own right, but at certain points in their careers, they are very much more suited for positions in smaller or less mission critical firms until they can bolster their knowledge.

Whiteboard Interviews often help find these people. A good engineer, while they should always practice and expand their knowledge, should be able to come to a reasonable conclusion about the problem in front of them without too much prompting. It is important to ask questions, figure out the system, and the expectations, but regurgitating a solution from a coding website or textbook does not show your ability to problem solve.

This is why I think Whiteboards are the gold standard for interviews, even with all their flaws and the potential false negatives (and positives!) they produce.

The Phone Screen

One can’t talk about Whiteboard or any other interview for that matter without the phone screen. These are often done as a sanity check to make sure your actual skills and personality match what you are presenting before a company takes a risk on flying you out to their site and putting you up in a hotel room. Most of the time, the questions are just as difficult as the ones you will encounter at Whiteboard Interview, but many times, they can be quite misleading, especially if a team or company is planning mass-hirings. Phone screens (and I include video conferences in these) can be just as nerve wracking as the on-site. However, they are absolutely critical for sanity testing. Lots of people can talk a good game, get past initial screens and HR interviews, and then they fall apart on the phone screen. I fumbled my first few due to lack of experience and nerves. Then I got better.

You are also put at the distinct disadvantage of coding in a shared document much of the time. This is all the convenience of programming on your computer, without an IDE and you have to worry about checking yourself, without the automatic muscle memory allowed in a Whiteboard. Aside from these complaints, I actually enjoy phone screens and think they’re one of the most fair ways to screen candidates.

The LeetCode/HackerRank/Online Assessment

I grudgingly do these, only because they’ve become so popular as a screening tool for smaller corporations and many startups. What I dislike about them, is the same reason I dislike certain Whiteboard Interviewers. The metric is based on whether or not you pass all or most of the test cases on the website in question.

Another reason I don’t care for them: these are remarkably easy to cheat on. and it is almost encouraged due to the metric of ‘perfection’, often based on the test cases provided to the website or assessment in question, required to pass them. Most of the test questions given are usually popular ones with easily accessible solutions either in Cracking the Coding Interview, GeeksForGeeks.com, or on various discussion boards. Companies like TripleByte have tried to stop this by disabling the copy and paste function in their IDEs, but most do not, and any savvy aspirant can get around these.

Until they’re given, observed, and the IDE is locked and outside interaction is disabled, I cannot give a positive impression of this style of interview. It generates entirely too many false positives with unscrupulous developers who end up wasting the company’s time on the onsite and too many false negatives for more scrupulous developer who don’t understand the tricks of the system.

The Take-Home Coding Assignment (THCA)

This is a style of interview that many start ups and newer companies use prior to bringing potential employees on site or even hiring them. It also runs the risk of you doing their work, for free. If the assignment takes more than 3-4 hours to accomplish and has a large number of very specific requirements without much leeway in terms of how you come to the solution, be very suspect. Odds are, you are doing work they should have their in-house people doing, for free.

On the other hand, if you enjoy doing things at a more leisurely pace or simulating the kind of problems you would encounter at that particular job, these are great. I have very mixed feelings about the THCA. On the one hand, if you have a dynamic, rapidly growing, company where you do not have a lot of time to do interviews and need to see if someone has the chops to quickly produce the code needed to get the job done, it can be a viable alternative — but you also run the risk of being out some of your time and hard-earned money, especially if you are made to host on a HEROKU or AWS instance. The amount is usually trivial, but if you are at a point where every nickel and dime counts, these can be a bit onerous. Most of these services do have -free- tiers, but they often have limitations that require you to babysit the project constantly which can be better spent looking for different positions.

Another issue I have with THCAs is that it is also quite easy to cheat on these, same with the LeetCode/HackerRank/Online Assessments. If someone has posted their code on Github or another like service, you can skip past a lot of the song and dance on these and potentially get into a position you have no right having. It is one thing to investigate someone else’s approach, it is is another thing to rip it off wholesale and it is on the company interviewing you to do their due diligence to make sure you are not doing this. Unfortunately, many of them do not have the time, and people fly through and waste their and the company’s time.

Conclusions…

Ultimately, interviews are just part and parcel of the experience of getting and keeping a job. They’re often not that much fun, and can be very stressful, but especially in technical careers, they’re an important sanity test. The flaws of the THCA and Online Assessments are the reason I greatly prefer the phone screen followed by an Whiteboard Interview/Onsite, whether in person or virtual.

Leave a Reply