OK. Time to take a break from the “best” or “worst” interview questions and take a walk through problematic landscape of tech interviews. Rather th...
For further actions, you may consider blocking this person and/or reporting abuse
"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?