Yes, people are really doing this. It's stupid, but to not do so puts you at a competitive disadvantage against other candidates. Competition for programming jobs is fierce.
It is not enough to be able to implement quicksort. One must have the algorithm thoroughly memorized so that it can be scrawled onto the whiteboard in one smooth motion of the dry-erase pen. If you pause to say "hmm..." while re-deriving quicksort on the spot, you will be branded as "slow" and obviously inferior to the candidate who spent three days bashing his/her head against an algorithms textbook.
>Yes, people are really doing this. It's stupid, but to not do so puts you at a competitive disadvantage against other candidates. Competition for programming jobs is fierce.
I'm suspecting that this is a "Valley" thing, would that be wrong?
>It is not enough to be able to implement quicksort. One must have the algorithm thoroughly memorized so that it can be scrawled onto the whiteboard in one smooth motion of the dry-erase pen. If you pause to say "hmm..." while re-deriving quicksort on the spot, you will be branded as "slow" and obviously inferior to the candidate who spent three days bashing his/her head against an algorithms textbook.
If someone has years of experience in this field, and a strong portfolio, why would they need to remember how to do quicksort? They probably haven't done it since their university days. That shouldn't even remotely be the focus of an interview for someone who has done real work in this industry.
It's not a "Valley" thing. It's a tech. company thing. I've never interviewed in the Bay Area, but pretty much every interview I've had has asked me to write algorithms on a whiteboard.
>If someone has years of experience in their field and a strong portfolio
Well, the problem is that quite a lot of programmers don't have portfolios outside of work. I certainly don't. I mean, I have a Github, true, but there's not really anything on there except for a bunch of half-finished experiments. Honestly, I don't have the energy to spend 8 hours a day immersed in programming, and then come home and spend one to two hours more building up my portfolio. Maybe that makes me a "bad" programmer, by some definitions.
>It's not a "Valley" thing. It's a tech. company thing. I've never interviewed in the Bay Area, but pretty much every interview I've had has asked me to write algorithms on a whiteboard.
The last time I had to write anything on a whiteboard in an interview, it was a data model relating to the work I'd be doing. I felt it was relevant to the process, at the time. If it weren't I'd feel like my valuable time (as well as theirs) was being wasted. But I suppose this comes down to what a company wants. If they just want people who are generally smart, and can be ramped up on the company's tech stack, fair enough. But some companies need to hire people who can hit the ground running. Much of my contracting has been done on such a basis.
>Well, the problem is that quite a lot of programmers don't have portfolios outside of work. I certainly don't. I mean, I have a Github, true, but there's not really anything on there except for a bunch of half-finished experiments. Honestly, I don't have the energy to spend 8 hours a day immersed in programming, and then come home and spend one to two hours more building up my portfolio. Maybe that makes me a "bad" programmer, by some definitions.
Your portfolio need not be only Github work. Barring an NDA, you can certainly discuss your professional work. In fact, I want to be asked about it during my interviews, as it forms the basis of my experience (which in theory is a big part of why I'm there in the interview room!).
It's not a "Tech company thing" it's a "junior engineer who doesn't know how to interview" thing. It is an indicator of a low quality company. Seriously. This is my opinion after 25 years of interviews.
Ask the candidate "Tell me about a project you're passionate about". Find out why. Get them to explain a hard problem they solved. Get them to teach it to you so you understand it.
Find the candidate that can do that and that gives you a good answer and you find a candidate who is passionate about something and can communicate it and understood it well enough to relate it in detail to you on the spot. That's the one to hire.
not the one who memorized quick sort... the former can implement a new quicsort.... the other one will spend all his time on stack overflow asking others to do his work.
I've worked for two of those, beat one in the market, and have a low regard of the quality of engineering at the other two... so yeah, low quality companies. Or at least low quality hiring processes.
One problem that seems pervasive on hacker news is Cargo Cultism. Just because one of those companies does something does not mean that it's a good thing. Some of those companies have really capricious and arbitrary hiring policies.
Don't get starry eyed. Don't confuse a household name for quality. And don't mindlessly copy the broken system of a fortune 500 company for your startup.
I'm an engineer, I'm not just pulling this out of my ass. I've been conducting thousands of interviews over the past decades and had to manage the people I hired with my process.
There's a bit of hyperbole here, though I am largely in agreement based on my interviews. In my interviews experience, it is unlikely that you'd be asked to implement quick sort, but that's because you'll be asked a question that requires realizing that a the question reduces to quick sort (this is how companies can avoid hiring people who just memorize solutions). For instance, instead of being asked to create all permutations of a string and all its substrings, you'll be asked a question that involves analyzing a set that needs to be permuted a similar way (this is my example, not from an actual interview, but I'd say it would count as about a medium level difficult question). If you don't know quick sort cold (or, in the case of my example, how to print all permutations of a string), there's no way you'd be able to program something that requires modifying and adapting these algorithms in 45 minutes at a whiteboard.
And yeah, again YMMV, but you definitely do need to largely solve the problem, so speed absolutely does matter here.
The really frustrating thing about all this is that if the experience causes you to go back, study algorithms, buy cracking the coding interview, and getting incredibly good at these questions, your next interview will involve… detailed questions about ruby syntax, followed by another interview with questions about how the JVM works, followed by another interview with questions about how MapReduce works[1].
Not saying this is good or bad, just that this is how it is, at least at the harder interviews.
Based on the final paragraph, it looks like triple byte does see the market opportunity here. The frustrating moving target of interview questions could correlate very well with what type of programmers a company is looking for. Considering that every interview requires a day (or more) off and a stressful and mentally taxing series of in-person exams, there's only so much one candidate can take before giving up and just staying in his or her job (assuming the candidate is currently employed). So if a company becomes aware of how to align candidate type with interview path, if you can line up with the algorithms style interviews, the person can slowly learn until getting a job offer, rather than experiencing a reset button. I wish them luck with this, because they'd be adding real value to a developer's job search, which isn't something devs typically expect from a recruiter.
>"It is not enough to be able to implement quicksort. One must have the algorithm thoroughly memorized so that it can be scrawled onto the whiteboard in one smooth motion of the dry-erase pen. If you pause to say "hmm..." while re-deriving quicksort on the spot, you will be branded as "slow" and obviously inferior to the candidate who spent three days bashing his/her head against an algorithms textbook."
If at an interview they asked/expected that of me, it would promptly disinterest me in working for them. And I'd probably tell them that right there.
Optimizing for memorization of specific algorithms (of sorting even?) instead of problem-solving and domain-knowledge is quite a weird/perverse incentive. I'm surprised it's gotten this far, if it is true. The places I've interviewed generally ask prior experience, talk about solutions and approaches, and theoretical OO-questions of the fizz-buzz level just to be sure.
It's quite difficult to come up with really good, unique interview questions. It's quite a bit easier to walk into the room, say "write a function that returns all the permutations of a string" and watch the candidate squirm. That's why most companies do that, it has nothing to do with trying to find candidates who can do the work at hand.
It is not enough to be able to implement quicksort. One must have the algorithm thoroughly memorized so that it can be scrawled onto the whiteboard in one smooth motion of the dry-erase pen. If you pause to say "hmm..." while re-deriving quicksort on the spot, you will be branded as "slow" and obviously inferior to the candidate who spent three days bashing his/her head against an algorithms textbook.