Also breaks the web search a bit since the title of the other conversation is not the actual title of the post (so for example reddit links don't show up)
It does do that, but long experience has taught us that HN is better when titles don't vent feelings of frustration.
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.
I understand the author's frustration but this sounds like sour grapes. Sure, the interview questions that Google, Facebook, Amazon, Microsoft and pretty much every big tech company asks are hard and abstract. But it shouldn't be a surprise. As the author mentions, there's numerous books on programming interview questions. Every software engineer I know will spend a lot of time studying common interview questions like maze solving before interviewing for jobs.
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.
BFS may not feel very relevant for front end development, but second time the author encountered it in an interview should have been a clue that it's worth learning.
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).
The second time he encountered it should have been a clue that interviewers are likely bored of interviewing and just googling "tech interview questions" and downloading the first set that catches their eye. It is this alone that makes BFS "worth learning" by heart.
Obviously, your mileage may vary. But at least at large companies (e.g., Google) the CS fundamentals you need to know to pass a coding interview are indeed pretty standard, and well described in books such as "Cracking the Coding Interview".
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.
So we have all these posts saying how it is so hard to find developers, and half the posts saying hiring is broken.
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're given a starting node in a linked data structure and you want to visit, collect, or search all of the nodes that it can reach, and do so without duplication. If you can solve that problem correctly, you've just used or re-invented one of DFS or BFS, and could come up with the other one after a moment of thought about the order in which you visit the nodes. These are not magic spells that you have to go to Hogwarts to memorize; they're the two obvious approaches to solving a really straight-forward problem statement.
For the people who are surprised that anybody could have a problem coming up with these solutions on the spot. What do you guys do all day that has you implementing these CS algorithms so often that you've effectively memorized them
Software developers are not dancing monkeys and should not be treated as such.
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.
I do agree with you on all the rest of the points, but just to say I started out in software and IT sales (but now much happier in a very different field) and I have absolutely been asked to both sell interviewers pens and random products and to have lots of imaginary phone conversations.
Funnily enough, anywhere that asked me to do that turned out to be a pretty rubbish place to work...
I've interviewed at Google, and their phone screening questions are exactly that, some basic coding exercise. E.g. how would you serialize a binary tree, or find the largest substring in lexicographical order.
I dunno... it's frustrating, but really, you can learn some valuable stuff during those few hours.
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.
27 comments
[ 2.9 ms ] story [ 67.4 ms ] threadThat 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.
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.
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.
Quiz != Interview
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...
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.