Earlier quoted context omitted.
They all got through the interview process so I'm pretty confident about 80% of them would be able to do it and 100% of them would be able to implement BFS. Also yes it's a basic graph algorithm everyone learns, but its inherently much more complicated than BFS which is a simple traversal. It's like bubble sort vs radix sort ... which makes this kind of a loaded question.
Now, I didn't say BFS, did I? :) I expect they can all do BFS, because your interview process apparently requires that.
Hiring Is Broken – My interview experience in the tech industry
471–480 of 693 posts
Re: Hiring Is Broken – My interview experience in the tech industry
#472The purposes of these interviews is not (usually) to see if you know the answer. It's to see how you problem solve. If you knew the correct answer to e.g. the BFS algorithm, you'll get thrown another question that they hope you don't know. When interviewing, the thing I want to see most is how someone works through a problem: can they solve from first principles? do they go via trial and error? do they ask for a comp…
Almost all are simply playing "programming trivia." They name an algorithm or a data structure, and then evaluate whether you can recite it from memory. That's it. There is no problem-solving element involved. It is purely a test of whether you can memorize and recite.
This requires a lot less effort on the part of the interviewer than the style you describe, and also bolsters their ego and makes them feel clever when they find a candidate who can't recite properly.
Re: Hiring Is Broken – My interview experience in the tech industry
#473There's selectivity, and there's courtesy and respect. Companies are entitled to be as selective as they like, and if those are the kinds of tests that yield the people they want to hire then good for them. On the other hand courtesy and respect would demand that you're clear with the candidate about your expectations and requirements, that you don't waste their time, that you respect the investment of time by commun…
Reciting the implementation of some obscure algorithm from memory is entirely irrelevant to the daily job of a software engineer. Being able to do that does not make you a good software engineer, and most good software engineers cannot do that.
They do these "programming trivia" style interviews because it makes them feel clever and superior to the interviewees, and because it's a lot less work for them than conducting an interview that actually probes what level of software engineering talent the candidate has.
Re: Hiring Is Broken – My interview experience in the tech industry
#474Technical interviews became 10x easier when I realized that most companies aren't necessarily looking for the right answer as much as they are trying to look into your mind. As a self taught programmer things like binary search trees and linked lists are a foreign concepts (especially as a self taught frontend developer). When I am asked to solve a problem in a way I've never encountered before, people are pretty ope…
I think you've hit on a great strategy to coast through these interviews: "Gee whiz, that's an amazing question. I've never thought of that before. It's probably beyond my reach but let me try to stumble through it. Will you help me out if I get lost? You're so amazing, how could this company get by without your brilliance?"
When I interview candidates, I state up-front that I care less about the solutions than the steps taken to reach one. It's okay to ask for help or hints when confronted with a previously unfamiliar problem. But if I need to provide too much help, teach the use of basic tools (whether they are logical patterns or universal utilities), and even then getting to A solution requires excessive hand-holding, I will hold that against you.
Also, I will happily invert a question if needed. Showing one way to solve a given problem, I would expect a qualified candidate to be able to point out where it could be done differently.
Re: Hiring Is Broken – My interview experience in the tech industry
#475Earlier quoted context omitted.
Maybe your idea of a front end developer differs from mine. I don't agree that front end developers need to code BFS. They just need to know that graphs can be searched, that should be it. Frontend devs can do many tasks that systems engineers (who can supposedly whip out algorithms in their sleep) cannot do: - Make pages render properly in all popular browsers - Make responsive UIs - Align text of variable length in…
I'm having a hard time responding to this. More and more, whole applications are being delivered in clientside Javascript using Angular or React or whatever. Are you suggesting that there are two "kinds" of front-end developers, the kind that knows how the DOM APIs work and the kind that can implement the rest of the application and domain logic in Javascript?
What algorithms have you seen in practice in web frontends? I have seen nothing even minor, not even binary search or bublle sort.
Re: Hiring Is Broken – My interview experience in the tech industry
#476Earlier quoted context omitted.
Sure. I know what a list, a hash table, a tree are because I looked it up whenever I saw someone mention it, and eventually internalized it. But before that, I'd used them for 10-15 years without knowing the name because it doesn't matter. Take a hash table. Python calls it a dict. C++ calls it an (unordered) map. Java calls it.. whatever it calls it. It's nice to have that 'hash table' google term to find the thing…
>> Java calls it.. whatever it calls it. It's nice to have that 'hash table' google term to find the thing you want in a new language, but otherwise they're just words. Actually, they are more than just words. Try not to conflate the abstract data structure itself with the language-specific implementations which can vary quite significantly. Also your flippant, dismissive attitude on quite important CS concepts would…
Please try to avoid this. We can discuss without resorting to attacks.
>> "There's no point in testing for X or Y because ... e.g. we won't need X or Y to perform the job we are being tested for"
That's what most people are arguing for I think, so I agree with you there.
>> not being able to recognize what BFS even stands for in the first place is enough to raise a red flag anywhere.
By doing this you are throwing away developers that have made their respective companies millions in revenue. It's not hypothetical. One day, a non-CS trained developer will come across a tree and use it. And then they'll learn.
Re: Hiring Is Broken – My interview experience in the tech industry
#477Corporate feedback is mostly BS. And the rare line from bozo recruiters offer little of substantive value. It's safer for him to say nothing at all.
Re: Hiring Is Broken – My interview experience in the tech industry
#478Why bother applying at those super fancy companies. There are loads of medium-sized shops with a friendly work atmosphere and reasonable hiring practices. Vimeo, Facebook, Google, ... they hire elitists and those design the interviews. And honestly I doubt their work is at the end of the day more efficient then that of most other "regular" companies.
Re: Hiring Is Broken – My interview experience in the tech industry
#479Earlier quoted context omitted.
I'v;e been programming for 8 years and have never ran into a BFS problem. Why do I need to know this to be an effective programmer again?
I've been programming for ~8 years as well and have implemented BFS multiple times, especially in occasions where I have to travel nested data structures and want to print them in a specific order. BFS and DFS are the bread and butter of tree/graph problems and every software engineer is expected to encounter them at least once in their life. What if you want to debug a complex data structure or just a tree and want…
It is intuitive, which even further pushes the question "Why do I need to know this to be an effective programmer"?
Re: Hiring Is Broken – My interview experience in the tech industry
#480Google studied their own interview process, according to Lazlo Bock, examining tens of thousands of hiring decisions. The study concluded that their process was no better than random chance at finding good candidates. They continue with that process nevertheless.
I have a rich network of Silicon Valley connections, built over 29 years of working for Valley companies. What I hear time and again is that many highly-qualified and productive people have a terrible time finding work.
Simultaneously, Silicon Valley companies testify before congress and complain to the press that there is a serious shortage of technical hires.
If companies can't find enough good candidates, and good candidates can't find enough offers, and one of the most prosperous companies in technology, with the most famously rigorous hiring process in the industry says that their own process is bullshit, then yeah, I'd say that hiring is broken.
Of course, if you happen to be prospering, then it doesn't look broken to you. You're prospering, after all.
And of course, if some joker comes along and says that the process that hired you is broken and gives results no better than random chance, of course you aren't likely to agree. After all, if it was luck that gave you your prosperity, then luck could just as easily take it away again.
The story we like to tell is that the technical interview screens out bad candidates. It's just a story, though. Google's research says it doesn't.
Is that such a big surprise, though? How many times in my three decades in software has a product launch depended on someone being able to solve a brain teaser in front of a critical stranger? Zero. How many times has a company's success depended on someone writing the right code on a whiteboard? Zero. How many times has the bottom line depended on someone coming up with the right algorithm or data structure off the top of their head in a conversation? Zero.
Technical interviews, if they measure anything at all, measure things that don't have much to do with technical jobs. So it shouldn't be a big surprise that they don't do better than chance at predicting someone's performance.
If technical interviews don't work, why do we still use them? Why does Google still use a hiring process that its own research says is bullshit?
Maybe it's because we don't have anything better.
I think it's because on some level we realize that we don't actually know how to distinguish good candidates from bad ones, but we don't want to admit it to ourselves. We want to think that we can pick the right candidate, because it can be so costly if we don't.
So we ritualize the process. We rely on a bullshit hazing ritual. We wave a dead chicken over it and tell ourselves that we are screening out bad candidates and hiring only the best.
Only we're not. If we were, then maybe companies would still have a hard time finding enough candidates, or maybe good candidates would still have a hard time finding jobs, but not both at the same time. And the company with the most 'rigorous' hiring process in the industry wouldn't be concluding that their own process is nonsense.
Yeah. It's broken.