OK. Time to take a break from the “best” or “worst” interview questions and take a walk through problematic landscape of tech interviews. Rather than engage in false narrative that only serves to reaffirm the battle between good vs. evil, I’m going to tackle the problems from a different perspective.
Who is this guy trying to tell me the way I conduct a tech interview is problematic? I'm not just a principal or senior level engineer at most corporations, but I am also certified in university teaching from Syracuse University. Part of that certification involved clearly understanding techniques for evaluating a student's progress. In my opinion, the tech industry is just repeating a lot of the problems in education. I've been on both sides of the interview. I've interviewed at virtually every large tech company at one time or another. Household names like Amazon, Google, Microsoft, Facebook, SpaceX and Apple. I've also sat in the interviewer's chair plenty of times. Sometimes I mentor others going through this ridiculous process on Codementor.
Some of the problems outlined below are not problems everywhere. If you happen to work at a company where there is a fair and balanced interview then congratulations. Please take on what you have learned about interviewing to your next job and make the process better there.
For the rest of us it can be really hard to identify problems in the interview process.
We don't feel empowered to change it, particularly when everyone at work is running around from meeting to meeting like a chicken with their head cut off. Who has the time to change the interview process? Hopefully this post will start a conversation geared toward changing the interview process where you work and give you tools to make a better interview.
Why do we need to change? Let's get through the first uncomfortable bit. Racism and sexism are rampant in the technology industry. Things are changing slowly, but it's a thing. More people need to act in order to make the entire process more fair and balanced at most corporations to ensure there isn't racial or sexist bias in the interview process. There are too many of one racial or gender profile or not enough of others. Looking at you white men.
The second reason we need to change is worth mentioning because it prohibits getting really good talent, but it relies on a simple proposition. Someone may be a poor test taker, but could be the most brilliant programmer you've ever met. People don't often fit in the molds we craft for them. Anyone going through public education could probably understand this, unless you got a perfect scores on all the tests. Standardized tests are actually poor evaluators of a person's ability in my opinion. A lot of the problems in education are reflected in the tech industry. We start teaching to the test, learning how to do well on the test rather than sharpening our skills as programmers. Questions that involve a simple answer are just that. Too simple. Trivia can be memorized. Problem solving requires experience.
Just remember less of this.
More of this.
The third reason for change is a less obvious one, but worth mentioning. Interviews are too stressful for a lot of people. I bet the sheer mention you are taking a test would make your blood pressure jump a little bit. Interviews are a first impression. When the candidate is stressed they won't perform as well or could act differently than they would under normal working conditions. The interviewers don't help the matter sometimes looking over the candidates shoulder or watching them code. This makes some people nervous. Do you code all the time with someone looking over your shoulder? Sometimes observation is unavoidable to ensure the candidate is genuine and that's fine but maybe try not to be so obvious or creepy about it.
How can you know something is broken in your company's tech interview?
That's alright, because here are some indicators of how the interview process at your company may be broken.
Questions amount to nothing more than trivia.
Candidate isn’t allowed to perform the tasks as they would in the course of a normal day’s work.
Process isn't standardized across the company or organization.
Content has no direct correlation to the function of the position.
Candidate isn't given a sufficient amount of time to complete the problem without someone looking over their shoulder the entire time.
How do we solve these problems? Below are some quick ideas for making the interview process more fair.
Clearly define a rubric in order to gauge the candidate's success.
Give the candidate a series of problems to solve in increasingly complexity.
Keep the trivia questions to the first round and use them to screen the candidate.
Allow the candidate to solve the problem in the environment they are used to. In the case of programmers their IDE or similar interface.
Give the candidate a project they can complete in 4 hours or less that reflects the position they are interviewing for.
Include a roundtable discussion as part of the interview. Avoid every step of the process being 1 on 1.
Add questions that aren't technical in nature to evaluate how well the candidate will work in a team.
As an interviewee if the process makes you want to convert to paganism and start making human sacrifices to the gods in order to get a new job just remember it’s not you who is broken. It’s most likely the process. No offense to the pagans. Keep up the good work.
If there’s one thing I’ve learned about human beings in my short time on this planet is that we are great imitators but not so great at innovation. It takes a lot of effort to change something, especially when that change requires combating sexism, racism, bias, and just sheer lack of will. So while y’all are talking about what is a good question or what is a nightmare question in an interview how about looking at how we can change the process altogether? Instead of trying to make the current process better let's offer a new vision for how it can be done. What are you doing to fix technical interview process at your company? Do you have any ideas on how to make it better for everyone involved?
Top comments (14)
"Trivia can be memorized. Problem solving requires experience."
Nailed it right there my friend. I've grown so flabbergasted and frustrated at the state of the interview process, particularly in the JavaScript world, that I have decided to take the bull by the horn and attack it heads on. You can look up what I have written about it here on devto if you like.
At a meetup recently, I have conducted this experiment. I divided the room in three teams and asked how many of the people in attendance were Basketball fans and geeks. Not so much were lol, but that was perfect for the exercise.
I then proceeded to have them compete around a Basketball trivia, and everyone was of course into it. No need for hoops knowledge to kick the competitive spirit into gears ;) At the end of the 5 question exercise, the team from "Middle Earth" won lol :) They had about 65% of the answers right.
the highlight, besides the high fives, was the simple fact that in a room full of non-expert on anything Basketball, one team was able to score 65%.
This has become unfortunately the sad state of the Coding interview process.
I really like the "giving or proposing a solutions approach" here and I will surely implement it in my proposition to the hiring companies. I have started a series of questions that have for ambition to be relevant and help in the fix of this problem.
Here are the first eight, it will be nice to have your take on it when you have a second. Relevant JS Questions
Thanks again for writing this. Cheers :)
I was just mentioning in another post how Google's whiteboard interview terrifies me. And it doesn't matter if you want to work frontend, everyone goes through the same whiteboard test. The packet I have to study involves BigO Notation which I promptly forgot after my final exams 6 years ago, but it's just a lot of stuff to study so I can pass the "exam"... probably not gonna use any of that stuff for what I want to do.
There are so many people who can’t deal with whiteboard interviews. Do we normally code on a whiteboard? No. The context switching is enough to cripple some folks so practice at home. Get a big pad of paper or whatever you have to simulate the experience.
You are totally right! There is at times content on the interview that is not applicable. I go back and forth about BigO. It’s an abstract concept first off and tends to restrict candidates to those who have a 4 year degree. But it is an essential concept I wish more junior level or self taught developers understood when using so many Array mutations. BigO is certainly something that can be recited or memorized and if I’m already using methods that are geared toward performance in the code I just wrote why is the interviewer pressing me to explain BigO? Honestly no one will probably know, but there maybe bias at play.
At my company, we only use the whiteboard in both interviews and on the job for diagramming ideas. Proposed system architecture, very loose pseudocode, proposed json schemas, etc. We would never have an interviewee write code on the board, that's ridiculous.
I hate that so many companies do this. As someone who is dislexic and has a hard time spelling and reading, writing code without spell check and autocomplete is very difficult. I'm self taught, no degree, was team lead on my first job, filed for my first patent (and was granted) at my second job on a proprietary OCR technology along side my mentor who has a PhD in neuroscience from Stanford, now I am a Machine learning engineer working with health care data. I don't say this to brag, but to highlight that I think I'm a pretty smart guy but I've failed a LOT of interviews. There is so much focus on crap that isn't used on the job. I will almost certainly never have to implement my own sort algorithm because every standard language library has a highly efficient sort function picked out. I failed a Facebook interview because I don't know how to solve Grid search problems when interviewing for an ANDROID position! Where in the Facebook Android app do they use Grid search? They don't.
I think big O isn't as important as the process by which you evaluate the complexity. Knowing that you have to loop over your entire dataset 3 times to solve your problem when a solution exists that can do it with one iteration. Being able to compare efficiency like this is more important than being able to specifically score a function. Ultimately, you're never going to actually score functions on the job. You'll profile code and compare processing time, sure. You may even look for inefficiencies in a code block that has been identified as a bottleneck, but you'll never actually score the code.
Inspirational. Awesome.
The only exception I can think of where having a good understanding of Big O is crucial is when you will be tasked with implementing a product from scratch, for example the storage engine under Amazon S3 using R-B tree or something.
Having said that, it still doesn't explain the rationale behind whiteboard interviews, apart from the common argument of testing how someone deals with pressure... except it's induced pressure so highly unrealistic to those we'll face day to day.
Lots of good points here and there’s definitely a lot of repeated problems across the tech industry when it comes to tech tests (personally, I’m not a fan.). One of the biggest issues I find with them is the amount of time that candidates are expected to commit to and where they turn from knowledge-testing exercises and into larger projects that are unpaid.
These can be very trying and overly time-consuming when applying for multiple roles at a time. Especially when uncompensated.
If a candidate is lucky enough to be entertaining multiple offers it can be quite the burden at the same time. Then if the same person is supporting a family and has all the stress of that on them it’s a compound problem. Candidates definitely need to negotiate time management but at the same time don’t be afraid to turn down the next round if things don’t feel right. I never accept unpaid work. No one should, no matter the circumstances. It sets harmful precedents that allow people to take advantage of others.
While I whole heartedly agree with everything you said, I think you failed to elaborate on how the things you want to change will help with sexism and racism. Perhaps you could do another article just on that topic and what we can do to help.
I touched on it lightly in this post. Make sure there is at least 1 roundtable discussion in the interview, avoid only having 1 on 1 when possible.
Here are a few ideas but these are just scratching the surface:
You're right, this topic deserves way more attention. I asked for the community to chime in with solutions. I don't have all the answers.
I would agree that a small project related to the job is ideal. However, I have only ever seen it misused. If a Senior Engineer reads this article, I hope that a 4-hour project is given at the end of all rounds. If every company is trying to give out 4-hour assignments to every candidate it would be a terrible experience. 1.5-hour Hackerrank tests in the first round are awful enough.
Oh for sure! 4 hours maximum. Sometimes it can take that long. Once I had to take a test that was timed remotely. It involved spinning up a Node.js server, transcoding some video with ffmpeg, and then deploying that to a server so anyone could upload and transcode. TBH it was probably a fair test for a startup who needs someone who can be a self-starter. It was an interesting problem to solve too, I hadn’t used ffmpeg in a couple years.
Keep the long form tests near the end of the process, allow the engineer ample time to do them, and keep it a reasonable ask.
Thats really long to read... lol I interviewed some developpers in vuejs expertise. I made for them a test that they pass for 1 hour 15 min.
After that i know it will have a lot of failures and that's normal the test can't normally be finish even if you are senior.
The important part is, I want to know how they are thinking and if they can easily say "i dont know". And this is the most important part. Because we all have different thinking about the solution so i want to check of they react with failure
While you make a solid point that can be important to see how someone deals with failure, giving a candidate no room for success is problematic. Honestly I really dislike this format as it doesn't allow the candidate to establish trust with the interviewer when their first impression is the interviewer just set them up for failure. The interviewee point of view is equally as important as the interviewer's as the candidate is about to dedicate a portion of their life to the company. If the candidate also has multiple prospects, why would they choose the company that set them up for failure when they can go with the company that treated them well throughout the process?