I can't really remember the last time I was turned down for an interview.
You're totally right about the other part though. I've lost a lot of jobs I think I could have been great at because I'm really bad at whiteboard coding interviews.
That's what I'm starting to suspect, and that suspicion is shared by several of my friends in the industry.
These deep technical skills don’t matter as much because a lot these highly paying companies don’t have work that is deeply technical. Their challenges are primarily around management and scaling the number of engineers.
This requires reducing people down to something very simple and being able to treat engineers as fungible resources. Hiring and evaluating each person as a special snow flake is not the most profitable thing to do at large scales.
This is exactly the thesis behind Paul Graham’s ideas on startups and innovation. The scaling of a large corporation inevitably jams up the gears of the system and a small team can completely outflank a large company with employees keeping more of the returns and the work being more fulfilling.
Unfortunately the incumbents have sucked in most of the revenue so even though you regularly have small teams of people knocking out work that puts the biggies to shame making money is hard to impossible. So everyone on “Hacker news” is now left reverse engineering every detail of how big co works to get ahead .
There maybe god level engineers who are stuck at junior levels because they simply don’t know how to fit into the gears of the hierarchy. If you want to get promoted your relationships and trust with the management chain is as important as the quality of your work.
Don’t buy into the official stories about systems and processes work. Learn how they actually do.
FAANMG also has a deluge of resume thrown at it every semester. Ever since mainstream media filmed at the Google Campus/Facebook HQ, every parent wants their kid to work there since "he's really good at this computer stuff" and "he's gaming all the time, he might as well make money at the computer!".
And then you get to interviewing and realize this candidate cannot write 2 lines of code...
Yes, people can randomly fail in interview due to stress or whatever. But that can happen on any question. This particular question really should weed out all that many otherwise good people.
Imo conversational questions are much better indicators in an interview of whether someone will be a good hire, the candidate knowing why you would use a binary tree over another data structure offers much more insight than asking them to write one. The more conversational approach also allows the interviewee to demonstrate their knowledge and gives you a better idea of how they approach a problem or whether they'd be a good fit on your team.
With that said, having a conversation with someone solving a problem right in front of you, gives you a very good insight into how the person thinks. To that end I've censored a lot of pupils where they have to "defend" (i.e. talk about or explain) a piece of code that they made, sometimes beforehand as a bigger project, or sometimes on the fly.
I'd often give them extra problems and talk with them about it as they solved it if I was unsure about the grade. I find that this gives me far more insight in where the pupil is coming from, and hence his level of competence, rather than seeing the code on its own, or having him answer a multiple choice or SAT type test. I can see how an interviewer might make use of a similar technique if he's unsure about the candidate.
Anecdotally, a coworker we hired a couple years ago (and has been doing an awesome job) dusted off her old coding challenge from when she applied, and ran it through a new test suite we've been working on. The suite failed, and it turns out her binary search was buggy...
Also for sorted datasets where the most frequently referenced data is at the top.
There's a lot of room in between "couldn't implement it" and "can do it in 5 seconds" and "wrote a buggy version of it".
A common counter argument is that a bad interviewer wouldn't accept an answer that has minor bugs in it like that. But I don't buy that counter argument, because a bad interviewer could misjudge candidates regardless of the interview format.
[1] https://reprog.wordpress.com/2010/04/19/are-you-one-of-the-1...
When I joined my current company, it was still tiny and sketchy and I got shanghaied into a surprise full day interview by the promise of an informal two hour tour. A two hour tour... At one point I was given 1.5 hours to write an implementation of a very core library that most software engineers take for granted every day. Trying to have fun with it, I spent about 20 minutes writing a design document, about 30 minutes coding the implementation, and then the last 40 minutes writing a dozen or so unit test cases (as well as a simple standalone unit test framework). When I ran out of time, only maybe 2/3rds of my test cases passed, and I had just narrowed the problem down to a flaw in one of the assumptions I had enumerated in my design document. All the interviewers seemed pretty impressed by the documentation and test coverage, and didn't really care about the implementation, mostly because it was relatively boring by design.
I quote from the thread: "binary search was first published in 1946 but the first published binary search without bugs was in 1962"
On the other hand, just understanding how the algorithm works is what matters. And binary search may have been "published" as an implementation on programmable electronic computers in the recent past, but it's a timeless and intuitive algorithm that I understood perfectly well when I was 4 years old and first learned to read and started looking up entries in the dictionary, encyclopedia, and phone book.
I've been writing code for 25+ years, 15 years professionally, and the only time I had to write any search algos from scratch was in school. I'm sure I could do a binary search given enough time but I'd probably just refuse and end the interview.
Walking out of an interview like that is certainly a great way to not get hired. That's fine if you didn't want to work there anyway I guess, and nice for the interviewers because they learned enough to end the candidacy confidently knowing they dodged a bullet. Strong engineering teams solving worthwhile problems want to hire people that charge head first into difficult problems and get their hands dirty.
If I were in a similar situation where I was asked to write an algorithm I was unfamiliar with, I would probably just say up front that I have no idea how to do that, and then start asking the interviewer questions about how it might work. I would also quickly try to identify a real world example of a problem they're hoping to solve with that algorithm, and then brainstorm alternative ways to solve that problem in ways I'm more familiar with.
"This person seems really sharp, and their questions were very insightful!"
"They really focused on testing more than the typical applicant."
"I tried giving them a hint four different ways, but they just wouldn't take it. When I explicitly explained what I was looking for, they agreed with me, but I couldn't tell if they actually understood."
"Their solution seemed a lot more complicated than necessary, and had a bunch of unhandled edge cases as a result. Every time I pointed out an edge case, they added another branch rather than fixing the underlying structural problems."
"Several times when I asked a question, they deflected or answered something else, or assumed I was implying something and continued writing more nonsensical code."
Also, many people people tend to attribute a lot of value to their personal/hobby projects. They're certainly very cool and fun to chat about, but it's very rare for projects to be novel in a way that sets you apart when being considered for serious engineering projects. At work we develop UAVs. Your hobby grade FPV quadcopter is totally sweet, but it isn't going to get you an interview. If you built a hardware-in-the-loop testbed for your quadcopter, then let's talk!
"Output" in particular is a funny thing to gauge in software engineering. I'll sometimes go a month without writing a single line of production code. My favorite PRs delete more lines of code than they add. A more junior coworker will have bloody fingertips from coding around a problem for days, and then I'll ask a relatively dumb question about what they're trying to do, they'll think for a minute, and then delete 1000 lines of code and replace it with 50 because they were making incorrect assumptions. It's not just individual productivity that matters, but also team productivity.
"Creativity" is also a funny thing. Within embedded software, the most elegant solution is the most boring one. Any time someone does something creative, there better be an extensive unit test for it, because otherwise it's definitely going to be buggy. With wisdom, discipline and creativity all together one can build more sophisticated and complex systems than otherwise, and that's highly valuable. Lacking wisdom or discipline, though, creativity does indeed become a liability.
They are optimizing for something. It's just not what you think it is.
A lot of it seems to be about the identities of the employees and the hazing ritual that initiates new members into the group.
Got it in one.
Whenever I ask people about these tests, we have some back-and-forth, and it inevitably ends with them declaring (in so many words): “Well, I got hazed, so you will, too.”
I don’t suck at the tests, but I’m not particularly good at them. I never practice them, and didn’t come up through the traditional CS curriculum (I started as an EE), so I’m often seeing the problems for the first time, when I look at them.
They just don’t have any relevance to the type of work I have experience doing, or the value I could bring to a team. Since it seems that most interviewers are looking for particularly formulaic responses, they are a pretty good way of filtering out people like me.
I’m always puzzled as to why interviewers waste valuable time on these seemingly pointless exams. If they don't want me to work for them, there's much easier ways to discourage me.
They probably only interview people that have showed continuous progress with several finished projects over the years and hire only those that are good and can code instead of pulling leftpad from npm (a snarky response but so is yours, as if it's either good at whiteboard interviews but uncreative imp or bad at interviews but great and accomplished)
In the absence of that, why might I ask you to implement a binary search or maybe a linked list: I want to give you a problem that you (should, for senior folks) understand and will show me that you understand pointers and dealing with memory with something basic. I don't expect perfect on a whiteboard interview, I'm just looking for red flags.
To be fair, I always get tripped up by the classic interview question of reverse-a-single-linked-list. It's not something I ever do outside an interview!
At one place I worked, one of the exercises we used simulated working in a team environment. HR was really worried that we were giving a "test" (this really sets of their alarm bells if they haven't vetted it!) and we had to prove up and down that it was an exercise to see how they performed in a group setting, and the actual code wasn't very important.
The whiteboard coding interviews are beyond stupid IMO, but at least they can prove that they're consistently applied.
As someone who thrives on talking about side-projects, I did not do well in that interview.