F*** You, I Quit – Hiring Is Broken
medium.com
medium.com
That doesn't mean that we don't share the feeling. I've felt the same way about tech job interviews for years, and one of my life goals is never to endure one again, at either end.
Do software sales reps get told to "sell me this shampoo" during an interview? Do they have to whiteboard the structure of an e-mail campaign? No. Because it's no indication of whether or not they can identify and build a relationship with a person at an enterprise that has purchasing power.
If you are putting someone through a coding exercise, it should be simply to query the basics - does this person write readable code. Does this person make comments or use logging?
Anything beyond that and you are looking for good candidates to fail, especially if you are trying to make them do it on the spot in front of an audience.
"Read this file, reverse the strings, and output the results to another file" - people can go months without reading/writing files in a given language and how many times in your professional life did you ever have to reverse a string?
"Explain the difference between a quick sort and a merge sort?" Who cares except when you are reviewing existing code and you look it up to see if there's an optimization to be made for your particular use case?
Being a good software developer takes a lot more than can be determined from a white boarding or code writing exercise. It takes good critical thinking. It takes the ability to work on a detail item while maintaining a view of the big picture pragmatically. It takes the ability to teach and communicate across technical boundaries. It takes the ability to identify, estimate LOE of, and prioritize tasks. It takes so much more than you can glean from an exercise flawed at the outset.
Look at the code bases for just about any existing software project public or private and you'll see code that was written by someone who would have done things differently if given a chance. Even when given autonomy over a project and an endless timeline we don't do things perfectly. Why should anybody be expected to write something perfect during an interview?
Developer interviews should be friendly and curious. You have to get along with the new hire, and that developer will have to succeed in your environment. Find the best person who meets those two basic requirements and who knows about the specific area where your existing shortcomings are, and you have a winner.
Funnily enough, anywhere that asked me to do that turned out to be a pretty rubbish place to work...
The world is full of not-entirely-relevant systems that you need to master to succeed. Tech interviewing is just another one of them. The good news is that once you know what they're looking for (and yes, there are books) it can be studied in a straightforward way.
Think of it as a standardized test, with all the associated virtues (consistency) and faults (dehumanization).
Except that it's not standardized at all.
BFS is absolutely on that list. Yes, I had to relearn it in preparation for my Google interview, but it was something I was ready for when it came up. And I would claim I'm a better software engineer for it -- graph search and data structures are topics that come up in lots of different contexts and for which understanding the basics can indeed make a big impact on your code.
The list of these fundamentals is not that long, and the fact that it exists is a big part of the reason why coding bootcamps have been so successful.
Maybe the best time to do one of these interviews is right after taking your algorithms final. I think I got 120 on that thing, but I would have a hard time recalling what BFS and DFS did without reviewing it.
You can argue the process is flawed, but what's the point of applying to these jobs without preparing and just hoping you would get a different outcome? The flip side is that these hard interviews makes programmers that can pass them scarce, which drives up salaries.
I have had some interviews that certainly haven't been positive, but they have been instructive or rewarding in some way. Not necessarily even relating to code. It teaches you something about them, the industry, and more importantly, about yourself.
Quiz != Interview