Hacker News Reader

Comment by Aqua_Geek | Hacker News Reader

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 linked lists work (for example) instead of the practical application of where they'd be used?

Edit: Big O notation is great and all, but shouldn't the emphasis be more on shipping than optimizing? You can optimize your MVP to death, but if you never finish it what good does that do?

View on HN

Yes, interview questions like this are common.

The problem with "practical application" questions is that the answer almost always comes down to "it depends". The correct optimization or fix is specific to the actual thing you are doing; that's what makes it practical.

In order for an interview question to be useful, both the interviewer and the interviewee must be able to answer it. The applicant doesn't know the interviewer's product well enough to make accurate technical diagnoses. The person doing the interviewing doesn't know about the applicants' products either. Bogging the interview down in specifics to fill in the background is usually not helpful - plus, it gives lots of opportunities for the applicant to bullshit the interview by listing a bunch of technical details that might not actually have been accurate or important.

Theory questions are favored precisely because they are not dependent on nuts-and-bolts practical details. "Reverse a linked list, writing your code on this whiteboard" is general enough that most applicants can answer.

I understand that people who lack CS degrees might not know the answer. Interviewing means accepting that you don't get a 100% accurate result. I would only switch away from the "basic CS question" problems if I was convinced that some other question has a higher accuracy rating, and I'm not sure of that.

> The problem with "practical application" questions is that the answer almost always comes down to "it depends."

Agreed. Talking about application of theory is way too vague and leaves way too much room for bs. But I think my original point was unclear. I'm not suggesting that interview questions be "When would you use a linked list?" but rather "Let's hack on something using a linked list (something beyond just simply reversing it)." Like the article mentions, once you've built a linked list before and have optimized (and reversed) it to death, there's little to be gained from doing it again for somebody else.

Yes, most interviews are like this. "Here, solve problem X on a binary tree on the whiteboard, you have 15 minutes, go!"

I'm not good at it, I have to study for a while before going on interviews. The whole "study ahead of time to look like you are a genius coming up with the best answer thinking out loud" routine seems to work, although it feels dirty to me.

When I am the interviewer, I ask people simple questions about what mistakes they have made and how they worked through them, because in my own experience the things I do to solve problems I have created for myself are usually the most enlightening. My take is if you have some obscure bug you spent a few days/weeks solving and you can relate it to me, I tend to believe you, but if you don't have stories about this then you probably weren't really doing much programming.

Big O is a little odd, because it can be very important or not very important, depending on what you are doing. The ability to say "I know this has bad runtime" and then deciding if it's either worth fixing now or noting for later is important.

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 linked lists work (for example) instead of the practical application of where they'd be used?

Edit: Big O notation is great and all, but shouldn't the emphasis be more on shipping than optimizing? You can optimize your MVP to death, but if you never finish it what good does that do?

I feel the third paragraph here conflicts with the second one. In effect, understanding Big O would help you identify where linked lists are applicable. You seem to want to be given an exhaustive list of where they should be used. Sorry, but that's not how programming works.

Secondly, I take issue with the "limiting your applicant pool to only those who got a CS degree". If you're going to work in the CS field, I think its only normal you are asked question to see if you've got a grasp of the foundations of your job. You don't need a CS degree for that, there exists such a thing as self-study, and I think its a very reasonable thing to require if you're trying to transition between fields.

And I take issue with "If you're going to work in the CS field." You're assuming that all programming/coding/software engineering/whatever jobs are in the CS field. There's a lot more out there.

I think this is more typical of positions being filled in Silicon Valley, where it appears that more programmers tend to have CS degrees. Or there are enough people with CS degrees that the rest of the community feels compelled to know and understand at least second year level CS theory (Big O and Data Structures).

I work in Texas, where this is not the case, and I've never been asked to implement a Linked List in any language. I have a CS degree from 10 years ago, and I can count on one hand the number of CS graduates that I've worked with in the past 6 years.

Because these things are immensely useful, but only if you know about them and can recognize when they will help in solving a problem. For example, I ended up implementing a linked list recently to efficiently allow editing of an ordered, traversable set of lines on a google map (a drawn route). There are other ways to solve the problem, but a linked list was the simplest as well as most performant.

Anyway, moral of the story is fundamental CS concepts come in handy if you know them enough to recognize how they will make a problem easier. Bonus points if you can whip it out in a few hours, which may be difficult if you have never done it before.

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.

The key insight that relates to the analysis of merge sort is that solving problems with computers always goes better if you divide them in half a few times. This comes up again and again; binary trees, binary search, and all the n log n sorts. Branch prediction is a little different; it's an optimization engineered into modern processors. Splitting problems into two is a fundamental property of the Universe. Therefore, it's less excusable to not realize that you do that a lot.

I concede that your example is more applicable. Perhaps something relating to L1/L2/L3 caches and memory might have been more suitable as mine.

I'm still not fully onboard with your general claim though. Someone building the most brilliantly simple, computationally simple Android calendar/planning/todo application might not care about dividing in half when all they have to do is Collections.sort(). Someone building a CRUD web app might see their most significant performance issue in HTTP throughput or latency. You'll be wondering how often they program a computer.

It's hard for me to imagine knowledge of Big O notation being a major limiting factor. I gleaned at least a superficial knowledge of it cruising Gamedev.net in high school, well enough that they didn't throw me out when I had to use it for an internship interview. It seems reasonable to expect people to have at least seen it. But perhaps I was an aberration.

We use these types of questions to allow an applicant to show us that they can, in fact, write a simple program (see http://www.codinghorror.com/blog/2007/02/why-cant-programmer...) and we use programming puzzles to make it more interesting for the bright candidates.

Are there any good sites out there that have a lot of these types of problems that are asked in interviews? Sites like http://spoj.pl seem to have problems that are more longer form. But it would be fun to start practicing solving the shorter ones that are asked without the hassle of interviewing to get them.

Other programming contest sites are good sources of problems similar to the ones that come up in interviews.

http://train.usaco.org/usacogate

http://community.topcoder.com/tc

http://uva.onlinejudge.org/

http://www.facebook.com/hackercup

http://code.google.com/codejam/

http://codeforces.com/

http://www.interviewstreet.com/recruit/challenges/

http://projecteuler.net/problems is a nice source

I guess that one of the advantages of such an approach is standardization, in particular if your company is big. Once you get a significant number of candidates, it may become more important to have some "objective" and quantitative way to rank your candidates by performance than to get a true understanding about how likely they are to get things done (how would you "measure" that?). At that point, it becomes more important to ensure uniformity of judgement across the pool of interviewers. Isn't that why they often ask programming puzzles: so that they can compare performance. If the price to pay for that is that some valuable candidate won't get an offer, they can live with that. At least, that's how I see it.

Of course the argument for startups will be different :)

I'm not sure standardization of interviews is desirable in a large company. My experience is that large companies hire by team, so interview candidates get widely varying experiences depending on what team interviews them. This way candidates can be considered not solely based on technical knowledge but also on how well they fit with a particular team.

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.

Isn't the MVP stage a little early to hire developers?

Reply on news.ycombinator.com