Live data from Hacker News

How to get hired (or, 'The silly story of interviewing in the valley')

trapm.com

111–120 of 178 posts

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#111
post #97
post #3

"Then, acting as though this was the first time I'd seen this problem, I would ask if it was ok if I thought aloud as I worked my way through the problem on the board. I'd mumble to myself about moving-this-piece-over-here and-now-we're-going-to-get-this, and lo-and-behold, I accidentally solved it in constant memory space, in C - a language I didn't even claim to be particularly good at! Only someone with amazing pr…

Tell me about it. I have nearly 20 years of experience in CS, and hold an advanced degree. I have 5 years of experience in a very niche field which is relatively hot. I was approached by Facebook for this specific purpose. They invited me in for just a "chat", asked me if I'd be interested in working with them. Obviously I said yeah, I'd be willing to talk. They set up an in-person interview. Just 45 minutes they sai…

I've interviewed a few people who thought the elementary questions I was asking were beneath them. I insisted, politely, that they humor me, because it's something we make everybody do, nothing personal. They failed. Hard.

Some people are probably bullshitters, but my theory is that some are just people who used to code (a little) but have since moved on to making architectural diagrams for so long they've forgotten what it's like in the trenches. Unfortunately, if you're interviewing for a job in the trenches, you need to demonstrate the ability to do the job.

It's entirely possible they screwed up, depending on why they asked you in, but once a company starts letting in people they "know" can code without verifying it first hand, things go bad fast.

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#112
post #75
post #69

Earlier quoted context omitted.

Thomas is saying that the hiring process for programmers is so comprehensively fubared that asking the FizzBuzz question to someone who has worked as a senior developer for 8 years at a well-regarded firm provides valuable signal and that if you fail to ask it you might hire people who are completely incapable of programming even with your fancy-dancy recruiting process, which shows that the pipeline and standard int…

Essentially: It is not common for doctors to be asked to locate the interviewer's mouth, ears and thumbs. If an interviewer asked that kind of thing, you'd really have to suspect that he couldn't tell a good doctor from a bad one. But programming interviewers do need to ask this kind of thing. So you really have to suspect…

The problem isn't that we're asking doctors to locate their mouth, ears, and thumbs.

The problem is that the resume and candidate pipeline is so crappy, that the interviewer cannot be sure if the person sitting across the table is a doctor, or a plumber, or a carpenter, or an accountant, or maybe a bum off the street.

My interviewing life would be a lot easier if there was a firm guarantee that every candidate knows at least basic programming - and by basic I mean basic - i.e., can put together a for loop that compiles, in a language of their choice.

The second part of this problem is that the industry has so many jobs where the absolutely clueless can survive that "X years experience" in-industry is not a trustworthy metric for competence. "5 years at County General" for a MD, with a clean record, is a pretty decent guarantee that your candidate is in the ballpark. "5 years at Accenture" for a programmer guarantees nothing, not even the ability to write FizzBuzz.

Elsewhere in the thread someone mentioned being incensed that, even with his years of experience, he was being asked elementary questions. That's why - years of working experience is not a valid signal for competence.

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#113
post #97

Earlier quoted context omitted.

Tell me about it. I have nearly 20 years of experience in CS, and hold an advanced degree. I have 5 years of experience in a very niche field which is relatively hot. I was approached by Facebook for this specific purpose. They invited me in for just a "chat", asked me if I'd be interested in working with them. Obviously I said yeah, I'd be willing to talk. They set up an in-person interview. Just 45 minutes they sai…

I've interviewed a few people who thought the elementary questions I was asking were beneath them. I insisted, politely, that they humor me, because it's something we make everybody do, nothing personal. They failed. Hard. Some people are probably bullshitters, but my theory is that some are just people who used to code (a little) but have since moved on to making architectural diagrams for so long they've forgotten…

[deleted]

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#114
post #97

Earlier quoted context omitted.

Tell me about it. I have nearly 20 years of experience in CS, and hold an advanced degree. I have 5 years of experience in a very niche field which is relatively hot. I was approached by Facebook for this specific purpose. They invited me in for just a "chat", asked me if I'd be interested in working with them. Obviously I said yeah, I'd be willing to talk. They set up an in-person interview. Just 45 minutes they sai…

I've interviewed a few people who thought the elementary questions I was asking were beneath them. I insisted, politely, that they humor me, because it's something we make everybody do, nothing personal. They failed. Hard. Some people are probably bullshitters, but my theory is that some are just people who used to code (a little) but have since moved on to making architectural diagrams for so long they've forgotten…

"I insisted, politely, that they humor me, because it's something we make everybody do, nothing personal. They failed. Hard."

I'm sensitive to that argument, but I also think the parent has a point. Coding the solution to a toy problem on a whiteboard has only limited correlation with the ability of a candidate to solve real-world problems. We use the tool because it's one of the best we have, not because it's a great tool. And if your interviewers can't summon the energy to make eye contact with a candidate...well, they're one-tool cavemen. Most software engineering demands communication skills and culture fit, yet we're still screening as if individual mental horsepower were the most important factor.

The danger in dismissing someone because they can't stand at a whiteboard and barf out the code to print the levels of a binary tree is that it has next to nothing to do with real work. That's just a fact. I probably couldn't do it correctly on a whiteboard, on my first try right now, and I write a lot of code. And I'm sure some hiring manager would eagerly dismiss me as "another frickin' PhD that doesn't know how to write code."

The point is twofold:

1) As in all things, good judgment is key. Sometimes the candidate can bork the technical question, and still deserve a hire.

2) If you find yourself depending exclusively upon the outcome of coding puzzles to screen candidates, you've already failed.

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#115

Are these kinds of interview questions really that prevalent? From the hiring side of the table, I can understand wanting to quickly know whether somebody knows some of the "basics" like data structures and whatnot. But I can't help feeling that you're needlessly limiting your applicant pool to only those who got a CS degree (and paid attention during the process). Why is so much emphasis placed on the theory of how…

Few of these types of questions ask anything beyond the first year of a decent CS curriculum. If interviewers wanted to limit themselves to CS students, they would ask about virtual memory and require candidates to write proofs of algorithms concepts on the whiteboard.

I certainly agree that writing proofs and algorithm concepts is a heavy bias towards CS grads. The issue there isn't so much with the concepts involved with the particular problem as with the structure of a proof and the approach to those problems in general. Once you've learned about induction formally, it's much easier to use it in a proof, even if you can understand what it is anyhow.

On the other hand, I'm not sure virtual memory is such a concept. I'm under the impression that virtual memory is a topic tons of people are talking about and that it's hard to get away from it even if you're a programmer without a CS degree. Of course, this could just be the result of my being a Linux enthusiast.

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#116
post #89

This article really indicates to me the fatuousness of this sorts of problem/solution interview approach. I agree with timr in that a more more intelligent approach is to throw a problem at the candidate, then drill down into their thinking about the problem. It's a bit silly if you're hiring based on regurgitation of algorithms in my opinion.

I certainly agree. However, I haven't actually seen any pure problem/solution interviews--and this is just for internships where you wouldn't expect the companies to be as thorough. I had questions ranging from "find and fix the problems in this code" to "how would you design a library to do..." to "propose a solution to this problem and prove it works". This might be because I mostly talked to smaller companies.

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#117
post #3

"Then, acting as though this was the first time I'd seen this problem, I would ask if it was ok if I thought aloud as I worked my way through the problem on the board. I'd mumble to myself about moving-this-piece-over-here and-now-we're-going-to-get-this, and lo-and-behold, I accidentally solved it in constant memory space, in C - a language I didn't even claim to be particularly good at! Only someone with amazing pr…

as someone who successfully built a great dev team at a startup, i can say that this is a sign of sheer laziness on the interviewers' parts. which is sad, because in a small company, hiring is one of the most important things you can do. there is no real excuse for having an interview so generic that someone can game it in this manner unless you're so large that you can afford the odd charlatan.

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#118

Earlier quoted context omitted.

Can you give me an example of a question that isn't located in glassdoor.com and is "diverse but not hard". As far as I'm concerned, the bar is already ridiculously high to the point where I feel like the only people that get jobs are the ones who randomly get lucky enough to get 3 or 4 interviewees that ask easy questions. There are people I know personally that have gone through every single one of the 1000+ Google…

But the clever thing is the work required to answer these questions is a filter in itself. Firstly it filters for the seriousness of the interviewee - have they done their (days of) preparation? And even then only a few people will have he ability to actually understand the quiz questions, and even if the answers are there in front of them.

The only problem is the filter for being good at cramming interview questions is not quite congruent with the filter for being a good programmer/developer/engineer/$role_youre_hiring_for.

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#119

Earlier quoted context omitted.

It's legal ageism. Asking questions whose answers will be fresh in the minds of recent CS graduates is a way to legally screen out everyone else, no matter how irrelevant the Big-O runtime of merge sort is to the job.

Personally, I always have to wonder how often someone programs a computer if they don't know the asymptotic complexity of a merge sort. It seems like something someone would either pick up at some point in their career, or be able to figure out on their own at the interview. (Come to think of it, I never took an algorithms class in school, and I know the answer to this question.)

What's your definition of "programming a computer"? Personally, I always have to wonder how often someone programs a computer if they don't know how a four-state branch predictor helps their CPU.

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#120
post #68
post #66

Earlier quoted context omitted.

I'm not sure I understood you correctly about FizzBuzz, but if you're saying that it isn't necessary then I'd have to disagree. I wish the world was such that FizzBuzz wasn't an effective filter, but it is. I really like the rest of your questions.

I'm saying that the fact that FizzBuzz actually works should be an indication of how crappy programming interviews tend to be.

I think this conclusion is wrong. The fact that FizzBuzz exists actually means that programming interviews are awesome: with most other professions, you would end up hiring a candidate equally as incompetent as the programmer that failed FizzBuzz.
Post reply on HN