>On top of the interview itself, there's the hours of studying you have to put in.
Yikes, are people really doing this, or feel like they must?
If I'm interviewing, I expect to be asked about previous projects, maybe my Github portfolio, and so on. I also expect to be asked how I might approach a given problem within my area of work. I can't imagine studying that - I'm paid to do this stuff every day.
So are we talking about stuff that isn't related to my area of work, like brain-teasers and random algorithm questions?
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.
I interviewed for jobs recently, and I studied my ass off for 6+ weeks, every night doing different coding questions, and spending weekends learning new things and coding algorithms for 6-8 hrs a a day.
It paid off, I got multiple job offers, and am pretty happy with the end result.
Indeed, I don't. I even asked, in one of my replies, if this was a "Valley" thing.
I'm ok with being asked to code or write things out during interviews - that is, if it is pertinent to the job I'll be performing. If I'm expected to do complex DB queries, for example, it is reasonable to see if I can write one. If I've been doing it for years, I should be able to handle such a task.
>I interviewed for jobs recently, and I studied my ass off for 6+ weeks, every night doing different coding questions, and spending weekends learning new things and coding algorithms for 6-8 hrs a a day.
But this... this seems more appropriate in the context of a university exam than a job in real-world software development. As I said in elsewhere in this thread, I can understand asking such questions of a prospective junior developer, as they won't have much experience, and the CS 101 material may be fresher in their mind.
It doesn't matter what you think is appropriate. This is the reality in Silicon Valley and probably other places now too. If you tried to interview here without preparing you would be eaten alive.
Maybe where you are (and how unfortunate). But in a decade-plus of doing this, I haven't been asked things like that since I was trying to find my first job in software development. At that point, asking CS 101 questions made sense, since I didn't have much in the way of products shipped, and so forth.
How unfortunate why? Is it unreasonable to ask a candidate to know CS101? I would never work for a company that didn't ask engineer candidates those questions.
>How unfortunate why? Is it unreasonable to ask a candidate to know CS101?
Not at all. For a junior position. But that's a difference of opinion with which we may have to live. For more experienced candidates, I'd be far more interested in what they've done to apply their knowledge in real-world scenarios. I need them to be able to do more than hypotheticals.
>I would never work for a company that didn't ask engineer candidates those questions.
And that's fine. Small point to add: I see at least one regional difference, with regards to the terms being used - I never see software developers called "engineers" unless they have an engineering degree. Maybe that's just my part of Canada, I don't know. Perhaps it is more of a protected term here.
It is a protected term here (in Canada), and it is not in the US.
For example, in 2001, Microsoft apparently agreed that in Canada, they would only use the acronym "MCSE", and not spell it out, because holding an MCSE does not make you an engineer.
I think it's amusing and cute that American developers call themselves engineers. It's not like they take on the ethical responsibilities that engineers do. But when in Rome, speak Romansh. Or however that goes.
Yes, I hadn't really interviewed seriously for a while and it was essential to go back and re-review all the basics of trees, lists, sorting, searching etc.
Problem is there is such a wide variety of questions its hard to be prepared across the board ...
Yikes, are people really doing this, or feel like they must?
If I'm interviewing, I expect to be asked about previous projects, maybe my Github portfolio, and so on. I also expect to be asked how I might approach a given problem within my area of work. I can't imagine studying that - I'm paid to do this stuff every day.
So are we talking about stuff that isn't related to my area of work, like brain-teasers and random algorithm questions?