There's a difference between not being able to write bubble sort and realizing that looking it up is a better use of your time. But when it actually comes time to do something you can't copy/paste off the internet, what do you expect a programmer who can't reinvent a half-decent bubble sort to do? The interview is to convince the other person that you can think logically about programs. Bubble sort is a low, low bar, and basic data structures are not much higher.
Maybe he's being hyperbolic, maybe not. But that's entirely besides the point.
I'm absolutely certain that there are many, many engineers who failed interviews because they couldn't write a zig-zag string and could yet come up with good solutions to problems at a real company.
> what do you expect a programmer who can't reinvent a half-decent bubble sort to do
But interviews aren't testing for that. The guy who invented Homebrew was judged by a Google engineer to be not good enough. Heck, I bet the engineer interviewing him probably had his/her entire dev machine setup via Homebrew.
DHH invented Ruby on Rails, which was used at Twitter for what, 4+ years? And yet if he anonymously gave an interview at Twitter they would probably reject him because he can't find a cycle in a linked list in 30 minutes.
> The interview is to convince the other person that you can think logically about programs.
It's supposed to be about that. The modern CS interview is, however, absolutely not about that. It's whether or not you've grinded through CtCI enough to be able to answer something taken from a vast pool of useless questions.
Tell me, is the Homebrew guy just really not good enough? Do you really think he does not know how to think about programs logically?
Good CS fundamentals are important because they are transferable skill to a wide array of problems a startup may face. Just because someone wrote an impressive framework or library doesn't mean given a complex problem outside of their known domain (web framework design or package management tool), they would be have the necessary background to solve it. With strong math and CS knowledge, you can reason through almost any problem.
Yes they are. Except, these interviews aren't testing for that. Finding the maximum sum subarray isn't testing for any fundamental.
> Just because someone wrote an impressive framework or library doesn't mean given a complex problem outside of their known domain
Why are you even hiring them for something that's not their expertise? Seriously, that's literally the whole point of the interview. I don't think Max Howell was trying to get in to the DeepMind team.
Calling these just some other web framework or package management tools is doing them an incredible disservice. Twitter used Rails. Airbnb uses Rails. If Airbnb hired DHH, it would be Airbnb's fault if they made him tune hyperparameters of some ML model rather than see how their web performance could be improved.
Honestly, at this point I'm convinced I could get HN to talk poorly about John Carmack's programming skills.
> Finding the maximum sum subarray isn't testing for any fundamental.
There is quite literally nothing more fundamental to computer science than data organization and access.
And for what it's worth, Google and others are very open about their hiring process: they want generalists. I assume they have the data to justify that's a better investment. So maybe DHH or whoever gave the impression they weren't interested in doing anything they haven't already mastered. We have at least a little bit of evidence that attitude could be the problem: many of these anecdotes are disgruntled people who (often profanely) publicly vent when a company rejects them. Maybe that attitude comes out during the interview when they're asked to do something they deem to be beneath them.
> Good CS fundamentals are important because they are transferable skill to a wide array of problems a startup may face
I'm really skeptical of this claim. Nothing about CS fundamentals prepares you for debugging mobile browser performance, or machine learning, or setting up a sharded database. Maybe the big companies have a reason for asking these questions, but few startups benefit from these types of questions.
From the POV of the large tech companies, it's mostly a matter of keeping the interviews short since the questions can be complicated yet fit in under an hour. The top companies are constantly growing, have ~3 year turnover and are flooded with applicants due to their name recognition. Why all the smaller ones copy this approach, I have no idea. The alternatives usually are just as unpalatable: pair programming, a long project, language triva questions, etc. So nothing changes.
>>I'm really skeptical of this claim. Nothing about CS fundamentals prepares you for debugging mobile browser performance, or machine learning, or setting up a sharded database. Maybe the big companies have a reason for asking these questions, but few startups benefit from these types of questions.
To summarize this statement, there's a reason why algos and datastructs is taught only for 1 semester out of 8 in college.
I'd much rather say a company like Google might have problems that require deep knowledge both inside and outside of someone's domain, but startups - no. They need to ship and optimize on the go, rinse and repeat.
> With strong math and CS knowledge, you can reason through almost any problem.
Until you can't. Math and CS, while certainly giving new perspectives, don't add much to the actual solution. What makes developers great is experience and not some text book knowledge of a topic. Hands on experience is a game changer.
Majority of the developers don't work and will most likely never work on something life-changing that they need to know every algorithm and data structure out there. Their time is better spent elsewhere.
That's a good one. My friends in engineering (physical sciences based, e.g. aerospace) and I have decided that the analog in that industry to programming interviews would for the candidate to be bombarded with questions asking him to evaluate complicated integrals from the CRC or something like it.
Yes, I can see the confusion. You see, we are looking for the very best Translators, and it has been proven by major companies that the people that are able to do the job best have a very solid foundation in the science translation is based in, such as Linguistics and Classics.
I would not be surprised if there were other, non-technical issues during such an interview. I know many people who are supposed to be smart, but they consider the basics beneath them and refuse to do anything by hand in the presence of people that might be subordinate in another context.
I'm sure I could do it in something pseudocodish, but it'd probably take an embarrassing amount of time. Honestly I could probably do almost as good a job of implementing quicksort, at least in a naive version based on the stack.
Seems to me that what interviewers should be looking for is not savants who can whack out particular odd bits of code but developers who can look up some things to use as reference as they go and most important who know how to determine what it is that they need. Proper evaluation and decision making is at least as important as actually writing the code, because those are the skills that can keep you from writing the wrong code.
With all due respect, I hear what you mean, but further supporting an interview system so divorced from actual problem solving (because most everyone who really really wants a job just endures the empty tediusness and memorizes these algorithmic puzzles from CTCI and Interview Cake and other sources) just enforces a kind of innane candy-empty arms race just like the SAT did, before it was clear that there were proven ways to master it. (the SAT has become just another pay wall at this point) The ultimate effect of this race is to render every programmer with the money and time to practice this equal. It is, forgive me, an infinite loop (sorry) -- and the bar will just get higher and new innane hoops will be added to the performing monkey obstacle course. Then, employers will be (or already are) selecting for a kind of navy seal squad of pedantry-- coders who like to submit and follow directions and behave themselves. Creative problem solving requires a bit of the rebel/subversive spirit. These kinds of interviews may test for an intrepid spirit. But honestly, There is no more intrepid spirit than that of an actual well-programmed machine. This popular interview method reveals that we are merely looking for programmers to be as similar to intrepid, well-programmed machines as possible. It results in machine-like workers working on machines. In effect, perhaps, the blind leading the blind. Is that what we want? I could be wrong, but I think we need to more highly value what humans bring to the task/process/team that computers can't. It seems less nihilistic, anyway. Or do we not know what that is? Maybe that is the real problem. Ironically, so many job ads say they are looking for "passion" in their programmers. Passion is at odds with what they select for. I wonder if the employers even realize this. My puzzle for them is: Given n programmers (all have memorized CTCI etc) ... so how do you decide what to select for and how would you implement an efficient, blind process that is more likely to include a diverse array of programmers who could work together hapily?
