The heart of tech is coming to the heart of the Mediterranean. Join TNW in València this March 🇪🇸

This article was published on December 18, 2022

3 nightmare interviews for software developers

Just no.


3 nightmare interviews for software developers
.cult
Story by

.cult

.cult by Honeypot is a Berlin-based community platform for developers. We write about all things career-related, make original documentaries .cult by Honeypot is a Berlin-based community platform for developers. We write about all things career-related, make original documentaries and share heaps of other untold developer stories from around the world.

This article was originally published on .cult by Nadya Primak. .cult is a Berlin-based community platform for developers. We write about all things career-related, make original documentaries, and share heaps of other untold developer stories from around the world.

The tech industry is not known for having great interviewing processes. From the notorious whiteboard interviews to algorithm challenges requiring a computer science degree to even wrap your head around, there are all kinds of outdated standards and approaches to interviewing developers that should have died out years ago. Unfortunately, like most legacy systems we love to hate, these interview processes are likely to crop up in your career from time to time. Or if you’re unlucky like me, they might pop up a bit more often.

To be clear, I’m not writing this post to call out any companies in particular or for the purpose of naming and shaming. For every company at which I’ve experienced these issues, there are hundreds of thousands if not millions more. One of the most common ways tech corporations practice gatekeeping is by making the interviewing process so difficult that it leaves everyone except (generally) white men with a computer science degree feeling like they aren’t good enough or don’t belong there.

In this post, you’re going to read some of the most common ways that companies can make your interviewing process a nightmare and hopefully be able to recognize them early on so that you don’t waste your time. I’ll share personal anecdotes of how they impacted me and how I moved on past them and you can too.

1. White board interviews

Like I said in the introduction, whiteboard interviews are one of those outdated approaches that tech companies still love to torture us with. The general idea is that you go up in front of a whiteboard and write pseudo-code mapping out how to solve an algorithm.

In case it’s not immediately apparent why this approach sucks, let me explain. Forcing a developer to write code by hand is inherently unnatural because it takes us out of the zone where we do our best work: in front of a computer. It also robs us of our most useful tool: search engines. Not to mention that it has no bearing on the everyday reality of the job.

It’s especially problematic for self-taught developers because the less expensive online classes and resources tend not to focus on algorithms but on more practical on-the-job skills, like building applications. Even students who’ve gone to a traditional 4-year institution and majored in computer science often need to practice these algorithms whenever they go in for interviews because they’re easy to forget.

I’ve lost track of how many whiteboard interviews I’ve had but there are a few that are particularly sharp in my memory. One was for a small startup where I was interviewing 1:1 and the guy interviewing me was very awkward. I knew the algorithm he was asking me to write was relatively simple but for whatever reason, my brain just couldn’t remember. Instead of cutting the interview off early or just giving me a hint, the interviewer insisted on dragging out the whiteboard portion for a ridiculously long time. I spent well over an hour in his office struggling with it before I finally got to the solution. Naturally, I did not get the job but I was so frustrated after the fact that my humiliation had to be drawn out for so long.

The good news is that whiteboard interviews are falling more and more out of fashion. There’s a lot of criticism of them in the developer community and I can probably count on 1 hand the number of developers I know who actually like these types of interviews.

2. Timed technical assessments

If you went to high school in the United States, you probably have a special place of hatred in your heart for timed tests. The first time I took the ACT I got a bad score simply because I could not stop looking at the clock and worrying about how much time I had left. It didn’t help that halfway through I had to go to the bathroom, but I was too nervous to leave the room because of how much time I might lose.

Like the whiteboard interviews, timed technical assessments tend to have algorithm components to them. A couple of years ago I decided to try one of those platforms where you take a coding test to create a developer profile for companies who want to outsource the technical stuff to a third party (Hired is one example).

There were three different challenges I had to complete successfully to be admitted into the platform. All of them were algorithm heavy, and I had done relatively minimal practice. I ended up getting stuck on the second challenge and not having enough time to complete the third. It can be very demoralizing to take a test and feel like you have virtually no idea what you’re doing. Chances are if you’re self-taught you’ll feel pretty demoralized since you didn’t study algorithms in college.

The added pressure of timing also doesn’t reflect the reality of most developer jobs. There’s pretty much never a situation where you only have 20 minutes to complete a task, in fact usually coding new features  takes days or even weeks.

The good news is there are platforms that have popped up to help developers prepare for these timed technical assessments. Hackerrank is probably the most popular one and is a great tool for self-taught and computer science degree-holding developers to brush up on these skills.

Unlike whiteboard interviews, timed technical assessments aren’t going anywhere. They’re convenient for hiring managers because all they have to do is send a link to the developer and the platform administers the test and returns the results. Hiring managers who choose to use these platforms aren’t necessarily lazy, they may just be running a small company or have too many other tasks to juggle. But it’s still worth being wary of this type of interview and know what you’re getting yourself into.

3. Phone screens

Not all phone screens are technical. Some of them are casual conversations with the recruiter or someone from HR. In fact, this is usually what we think of with a phone screen. However, sometimes companies get creative or want to shorten the interview process by skipping a technical assessment and just conducting a Q&A over the phone.

In theory, this could be great. No technical assessments or take-home projects to worry about. Just a quick phone call and you’re done! This was my exact mindset when I first encountered this type of interview. But my attitude changed quickly after I got the job. I realized that some of my coworkers didn’t have the required skills at all and were able to pretty easily dupe the hiring manager into thinking they were competent.

The other danger of phone screenings is technical jargon. This is again more of an issue for self-taught developers, but there’s so much jargon in the world of coding that nobody’s safe. If I’m asked over the phone to define a technical term, there’s a decent chance I know the concept, just not by name—but have either forgotten the term it’s associated with or I haven’t encountered it enough to try to memorize what it means. This has caused me to fail phone screenings in the past, or be asked to do additional take-home assignments.

It’s pretty rare that a company will only do a phone screen and not give some sort of in-person or online coding test but you might encounter it if you’re doing contract work or applying for a company that does not have a lot of technical positions. Just go forward with caution.

Takeaways

Self-taught developers have to be more aware and often prepare more for interviews than their computer science degree bearing peers. It often boils down to the difference of being less familiar with the technical jargon and algorithms, which are overemphasized in the interview process compared to the actual day-to-day work of software developers.

Luckily some of the particularly unpleasant interviewing approaches like whiteboard interviews are becoming quite unpopular, but it’s still worth going in prepared and knowing there is a possibility you’ll have some sorting puzzles or word salad thrown your way.

You should also know that there are companies who actually give practical coding challenges that reflect a better environment for programmers because it means they care about the experience of their candidates (and likely care about their employees more too). There is room for improvement but also a lot of discourse around how to improve the interview process in the industry, and thankfully some companies are actually listening and making big improvements.

Get the TNW newsletter

Get the most important tech news in your inbox each week.

Also tagged with


Published
Back to top