75 ms·

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

245 points by sgrove 15y ago

Aqua_Geek 15y ago
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?
- overgryphon 15y ago
  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.
  - tikhonj 15y ago
    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.
- robobenjie 15y ago
  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... http://www.codinghorror.com/blog/2007/02/why-cant-programmer...) and we use programming puzzles to make it more interesting for the bright candidates.
  - Stwerner 15y ago
    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 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.
    - robobenjie 15y ago
      http://projecteuler.net/problems http://projecteuler.net/problems is a nice source
    - anonymoushn 15y ago
      Other programming contest sites are good sources of problems similar to the ones that come up in interviews. http://train.usaco.org/usacogate http://train.usaco.org/usacogate http://community.topcoder.com/tc http://community.topcoder.com/tc http://uva.onlinejudge.org/ http://uva.onlinejudge.org/ http://www.facebook.com/hackercup http://www.facebook.com/hackercup http://code.google.com/codejam/ http://code.google.com/codejam/ http://codeforces.com/ http://codeforces.com/ http://www.interviewstreet.com/recruit/challenges/ http://www.interviewstreet.com/recruit/challenges/
- ejames 15y ago
  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.
  - Aqua_Geek 15y ago
    > 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.
- qdog 15y ago
  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.
- cullenking 15y ago
  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.
- gcp 15y ago
  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.
  - jaylevitt 15y ago
    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.
- philwelch 15y ago
  Isn't the MVP stage a little early to hire developers?
- abahgat 15y ago
  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 :)
  - overgryphon 15y ago
    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.
- hkarthik 15y ago
  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.
- dangrossman 15y ago
  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.
  - jrockway 15y ago
    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.)
    - jarek 15y ago
      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.
      - jrockway 15y ago
        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.
        jarek 15y ago
        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.
- andrewflnr 15y ago
  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.
timr 15y ago
"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 problem solving skills would be able to do that their first time thinking through this problem so earnestly!" All this tells me is that tech interviewing is horribly broken. What we have here is a story of a guy with a little bit of experience who has (if his story is true) successfully learned how to game the interview systems at dozens of startups. If you interview people, this article should terrify you. You can argue that it isn't "gaming" if the guy turns out to be a good employee, but that's wrong. If he can trivially game the system, so can anyone else with the ability to go to dozens of interviews and remember questions. There's a fix for this problem: make the interview about more than the answer to the stupid question. If the candidate answers your question a little too quickly, ask something harder. Chase down a detail. Pick an experience on the resume (and not an obvious one), and dig as deeply as you can. Good candidates know the details. Bad candidates don't have details you can chase. If you're interviewing correctly, no candidate should be able to come in and snow you with some regurgitated C code from previous interview experience, because you'll be able to out-flank them at every attempt to cough up a line. Unfortunately, there's a corollary: you need to know the subject better than the person that you're interviewing. If you don't, you have no hope of screening for good people.
- kakuri 15y ago
  It sounds like in this case, this guy might be a good candidate - look at all the effort he put in and his ability to remember things, think critically, and learn. On the other hand, there are plenty of competent programmers not willing to put up with this nonsense, and the companies are going to miss out on them.
- sgrove 15y ago
  Yeah, that was more or less the point of the post. For applicants, don't feel nervous, it's a silly game just to see if you know some of the puzzles. For people hiring, go ahead and use this as a first-pass filter, but realize that it's easy to game (by someone who's trying hard and learning, so there is a positive signal in that). It's going to be important to go through and work with them for a period of time in a let's-date-before-we-marry relationship. As an employee, I always insisted on a contracting relationship before an employment relationship. Like I said in the footer, Heroku really seems to do this the right way, and it shows. Kudos to them. And everyone else needs to step up their game.
breadbox 15y ago
So ... what exactly is the turing-machine dog question? A google search left me unenlightened.
- andrewflnr 15y ago
  I figured it was just humorous nonsense.
deleted 15y ago
[deleted]
observer1 15y ago
"....this process, starting from ~50+ raw leads whittled down into ~40 initial phone interviews/coding challenges, which went to ~25 next stage interviews, eventually down to ~6 really good offers, all in about ~1.5 weeks." Does this timeframe seem a little dubious to anyone else? I count 65 technical interviews plus interviews with hiring managers, etc., followed by receiving offers. And all of this happening in about 8 days. This story would be a lot more believable if it had a realistic timeframe.
- sgrove 15y ago
  Nope, it's true. I woke up early in the morning (easy to do sleeping on the kitchen floor in mountain view without a heater), went through craigslist every morning, had an email template I'd individualize for each posting, and send it out. I'd work through the code challenges as they came in, set phone interviews into the late night, in-person interviews in the city during lunch, etc. It happened, I took it pretty seriously because of the impending cliff of being homeless.
- angelbob 15y ago
  The 25 next-stage interviews are the only part that sounds even slightly unrealistic to me. The phone interviews are 30-60 minutes each, so 40 of them is no problem (20-40 hours of work). The next-stage interviews are going to vary from 1-2 hours to a full day, so I assume he didn't do many full-day interviews in that 10-11 days, or probably 7-8 workdays. But startups are often far more willing to do remote interviews, interviews at weird times, interviews on weekends... It would be a packed 1.5 weeks, though.
- Timothee 15y ago
  Besides the apparent mismatch between hours in a day and hours necessary for all that to happen in 1.5 weeks (well, it's technically possible), what surprised me was just even that 40 companies out of 50 were responsive enough to schedule phone interviews in that time. And next stage interviews after that. And make a decision to hire him. Especially for a self-proclaimed bad coder. So, I agree with you, but this is not really the point of the post. The point is that interviewing is a game that you can master with practice.
- 15y ago
rauljara 15y ago
I was flabbergasted that someone was asked implement a linked list in Ruby. My initial reaction was 'That is an incredibly stupid thing to do.' My slightly more in depth reaction was "Isn't that what mutable arrays are for?" And my final reaction was, "Maybe I'm missing something." At which point I tried to figure out the benefits of a linked list over a ruby array. I wasn't able to come up with a good reason to use a linked list in Ruby, but maybe someone could enlighten me.
- kenjackson 15y ago
  Linked lists and arrays typically have different perf characteristics (although I don't know how Ruby arrays work). For example if I give you an element of an array/linked list and tell you to insert a new element adjacent to it -- a linked list is a constant time insertion, whereas arrays are typically O(n).
  - tptacek 15y ago
    That's a sensible point, but interpreter and runtime overhead crushes any cost savings you might get from adjusting links instead of the whole array backing store. (Ruby arrays, at least in MRI, are basically STL vectors). 1000 inserts to the middle of a 1,000,000 element Ruby array happens so quickly you can barely perceive the delay. The same insert pattern to a basic Ruby linked list sets my machine on fire.
    - kenjackson 15y ago
      Wow, that sounds painful. So do people not use things like graphs or trees in Ruby due to perf? I actually used to do Python development -- about 13 or so years ago, but had to quit due to perf just being abysmal for applications intended for customers (and started focusing on C++). Is Ruby today similarly bad for apps that make heavy use of data structures like trees/graphs as Python more than a decade ago? EDIT: Updated to remove the term 'toy-apps'
      - tptacek 15y ago
langsamer 15y ago
I think a much better indicator of how valuable a person will be in your company is not if he can solve puzzles on the fly but how munch time he puts into coding. If a person is coding in his free time and keeping up with technology and experimenting even though his current job doesn't require it, that person is more likely to have a breadth of knowledge that will pay dividends over time. Something like that cannot be gauged by him/her solving a "reverse-linked-list" problem. Furthermore, a person involved in the community is more likely have in-roads with other strong developers, which again might pay dividends in the future in terms of hiring.
- gcp 15y ago
  In my experience interviewing candidates, the two are very strongly correlated. A person coding in a lot, including in his free time is more likely to have implemented a wide variety of things, and will be much more hands-on to solve these kind of riddles/exercises, than a person with only book knowledge who coded the same kind of stuff for years on an end.
codenerdz 15y ago
I had a similar experience interviewing after being off the job market for a quiet a few years: You will be rusty initially, but then you will pick up steam. Just like in your "real life", solving interview problems is not about reinventing the wheel with 100% custom solution, its about pattern recognition where the pattern is a problem you know a solution for. The more problems you solve(and possibly fail) the more data your internal pattern recognition algorithm(your brain) has to help you with the solution. I dont see it as gaming the system, I see it as being able to prove that you are capable of problem solving.
- sgrove 15y ago
  Yeah, it's a positive signal that someone was able to pick up from past failed interviews. It's a weak filter, but it's fine to have. From there, it's best to work with the person on short projects, and then hire them as a contractor to find out if they're a culture match and can solve the problems you're facing at an acceptable rate and in a maintainable way before hiring them on as an employee.
russell 15y ago
I use a similar approach. I spent 20 years as a consultant, so I did a lot of interviews. I would send out lots of emails. I didnt do many tailored emails, but I did a carefully tailored cover letter designed to be amusing to the HR ladies. You have to get by them first. I figured the first few interviews were throw-aways, just to get my interviewing skills back up to speed and to find what this years interview questions were. Yes, they go in fads. One year the programming task of choice was to reverse the words in a string. See it a couple of times and you get too be pretty proficient. I keep a stock of questions to push back. I havent issued programming challenges, but I have asked, "What is your pain point? What technical issue is causing you problems?" Usually we get into a long discussion of the challenges theyare facing.
- shard 15y ago
  What did you do in your cover letter to amuse the HR ladies? Please share.
  - russell 15y ago
    Do you remember the Johnny Cash song "I've Been Everywhere... Chicago, Reno, Fargo"? Sometimes I think my resume reads like that. After I added those lines, I got a 25-30% increase in responses.
brown9-2 15y ago
I started asking if I could assume TCO - usually knowing they would say no, but it would set them back a bit because that's an unusual question. What does TCO here mean? Tail-call optimization?
- anonymoushn 15y ago
  Yes. For a moment I wondered why he wanted to use TopCoder Open in the middle of an interview.
  - r00fus 15y ago
    or Total Cost of Ownership... I guess I'm hopelessly "enterprisey".
    - AdamTReineke 15y ago
      That's two of us.
- sgrove 15y ago
  yup.
seank 15y ago
It's worth mentioning this as a counterpoint to 'startups don't reply': http://news.ycombinator.com/item?id=3351699 http://news.ycombinator.com/item?id=3351699
tptacek 15y ago
Programmer interviews are famously terrible. Take a second to think about FizzBuzz, why anyone ever thought we'd need something like it, and how it actually continues to serve a purpose. Everyone thinks they're better at interviewing than they are. They often have a survivorship bias. In clueful companies, it's not that dead weight doesn't get hired. It just gets washed out. Interviewers tend to remember the people they end up working alongside. There are dev questions that are harder to study for. They tend to be open ended. A few of my favorites: * Describe some code that tends to follow you from project to project (I mostly interview C devs, so I tend to ask this as, "what's in libyou.a?"). What's in your bag of utility functions? * What's the worst library you've ever worked with and why did you hate it? * Estimate the amount of time it will take you to complete system X. Drill down, both by forcing the candidate to specify components (do an informal design exercise) and then cost each of those components. Estimation is an extremely important skill regardless. * What's a piece of functionality that tends to crop up on lots of projects that you'd never implement yourself if you had the option of using a library? (Usually, I'm trying to get C programmers to tell me that they would not in fact hand-hack doubly linked lists out of structs with nested struct pointers). * Describe the last system you contributed significantly to; how did those contributions break down structurally (did you write libraries for X, Y, Z; did you write plugins for X, Y, Z; did you extend the engine in X, Y, Z ways). Now describe the trickiest bug you ran into on that project. For C devs, I always used to ask, "You're testing a component you just wrote and finding that it crashes in malloc. Diagnose the problem." This is less relevant now, but there are probably surgical questions you can ask e.g. a Python dev that verify that they actually have the experience of working professionally in the language.
- steve8918 15y ago
  These are great questions. The one question I use with experienced hires is "Talk to me about the hardest bug you've ever worked on." I will keep drilling down to deeper and deeper levels to figure out how much they actually know, as opposed to memorize.
- zmj 15y ago
  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.
steve8918 15y ago
I call complete and utter bullshit. Each "technical interview" I've been to is about 3-6 hrs. I've yet to see a Silicon Valley technical interview where it's not at least 3 hrs, meeting with 3 people. So right there, fitting 25 "next stage" interviews in 1.5 weeks is bullshit. Where is he going to find the time for 40 initial phone interviews? That requires talking with the recruiter, and then the recruiter scheduling time with a developer. Anyone who has realistically interviewed in Silicon Valley knows that recruiters are very slow, and things tend to get muddled up very easily. In 1.5 weeks, assuming they don't interview on weekends, that's 6 1-hr phone screens, plus 3 on-site interviews per day. The logistics simply don't work. It's a complete lie. If he had said 1 month, then it still would have been impossible with 1.5 phone screens and 1 on-sites per day, but it would have been slightly more believable than 1.5 weeks.
- sgrove 15y ago
  Rough. But you're free not believe, I don't have a problem with that.
  - steve8918 15y ago
    Sorry buddy, but please explain the complete discrepancy in what you reported. How do you fit 3 on-sites and 6 interviews per day? Even if your onsites were 1 hr long and they offered you a job after a single interview, you still have to drive back and forth to each location. How did you have time for the 6 phone screens per day?
    - sgrove 15y ago
      I didn't have a car actually. I just scheduled all the interviews as close to possible every day, and walked around SOMA/FiDi from morning until evening going through different stages of different interviews - initial chat (morning coffee/lunch/dinner/drinks), whiteboarding session, meet with the team, build a mini-project, discuss final offer. Each successive stage is more time intensive, but there were also fewer of them. There's a lot of noise, especially in the beginning, so a lot drop off very quickly. From there, it was just a matter of tightly packing the schedule and doing it from day to night. Like I said, the "you'll be homeless again very soon" factor was a big one for me.
eru 15y ago
I can't post to the site, could somebody who can (or can contact the author in some other way), leave a note to the author, notifying him of a typo in "For people hiring, remember that anyway can pass yours tests with enough experience interviewing, even someone as bad at coding as myself." (It should be `anyone' not `anyway'.) Thanks!
- sgrove 15y ago
  Got it, thank you eru!
troygoode 15y ago
People talking about how he "hacked the interview process" are missing the point: as a hiring manager I'd gladly hire this guy even knowing that so much of what he did was not entire genuine. He took a problem (I need a job), implemented a solution (applied and interviewed at a TON of places in that short of a timeframe), and successfully iterated on that solution until he had completely mastered it! In a very short time period he went from being unable to solve a variety of programming problems (or doing so poorly) to internalizing the how & why of the optimal solutions - this is what good software development is about! I care a lot more about initiative and problem-solving skills than I do reversing linked-lists - this guy has the former two in spades.
- overgryphon 15y ago
  Sure, if you're looking for someone who is hard working and willing to learn, then this type of candidate is perfect for you. But if you're screening for candidates with development experience who you can rely on for technical knowledge, the idea that someone can game your interview process in less than two weeks without previous knowledge is horrifying. But I'm guessing that people looking to hire experienced candidates aren't basing hiring decisions on questions about reversing linked-lists.
  - kamaal 15y ago
    I think the point he was trying to make was. If you are productive enough and serious with a little skills you are can be hired. The reason being you work hard your way towards success. This is far better than the person who knows merely facts. Knowing doesn't always doing. But in most cases if you are doing something you are likely to know what it is.
krupan 15y ago
A lot of discussion here about memorizing the programming questions, but I think the most interesting part of this is when he turned the tables at the Do You Have Any Questions For Me stage and really interviewed them. I haven't asked anyone a programming questions like he did, but I did ask some tough questions about the team, work environment, management style, company goals (looking for a quick exit? in for the long haul? etc.) at my last job interview (after some good friends gave me the advice) and it both gave me a lot of insight into the company and team that I was considering working for, and I think it impressed them that I was thinking about those things. In short, know what you want from a team, manager, and company, and take time to interview the people interviewing you to make sure they have what you are looking for.
systemizer 15y ago
I had a similar experience. This past Fall, I was interviewing with multiple companies, and I received questions that were very similar.... some being the same exact thing. I was nice, however, and told them out front that I had seen the problem before and asked for another. I don't regret doing that; some may have passed the interview by keeping quiet even though they had seen the problem, but those people won't go far in the world because they cheat. They will eventually get called out for it and lose their reputation.
nadam 15y ago
I don't understand why is there such a strong emphasis on these kind of interview questions. I think showing a piece of nontrivial code which the candidate have created in the past tells a lot more about the candidate. For example this tells more about me than the interview questions I usually got: http://codeclamp.com/ccui.js http://codeclamp.com/ccui.js , because it tells about how I think long-term, how I solve relatively hard and relatively complex problems, not how I survive a quick interview (solving relatively easy algorithmical problems but under very high time pressure.). (By the way, if you have an interesting well paying job for me, I might be interested...)
pnathan 15y ago
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.
- tikhonj 15y ago
  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.
tldrtldr 15y ago
Isn't there a book dedicated to coding interviews? http://www.amazon.com/Cracking-Coding-Interview-Programming-Questions/dp/098478280X http://www.amazon.com/Cracking-Coding-Interview-Programming-...

245 points by sgrove 15y ago

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?

overgryphon 15y ago
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.
- tikhonj 15y ago
  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.
robobenjie 15y ago
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... http://www.codinghorror.com/blog/2007/02/why-cant-programmer...) and we use programming puzzles to make it more interesting for the bright candidates.
- Stwerner 15y ago
  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 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.
  - robobenjie 15y ago
    http://projecteuler.net/problems http://projecteuler.net/problems is a nice source
  - anonymoushn 15y ago
    Other programming contest sites are good sources of problems similar to the ones that come up in interviews. http://train.usaco.org/usacogate http://train.usaco.org/usacogate http://community.topcoder.com/tc http://community.topcoder.com/tc http://uva.onlinejudge.org/ http://uva.onlinejudge.org/ http://www.facebook.com/hackercup http://www.facebook.com/hackercup http://code.google.com/codejam/ http://code.google.com/codejam/ http://codeforces.com/ http://codeforces.com/ http://www.interviewstreet.com/recruit/challenges/ http://www.interviewstreet.com/recruit/challenges/
ejames 15y ago
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.
- Aqua_Geek 15y ago
  > 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.
qdog 15y ago
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.
cullenking 15y ago
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.
gcp 15y ago
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.
- jaylevitt 15y ago
  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.
philwelch 15y ago
Isn't the MVP stage a little early to hire developers?
abahgat 15y ago
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 :)
- overgryphon 15y ago
  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.
hkarthik 15y ago
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.
dangrossman 15y ago
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.
- jrockway 15y ago
  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.)
  - jarek 15y ago
    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.
    - jrockway 15y ago
      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.
      - jarek 15y ago
        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.
andrewflnr 15y ago
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.

timr 15y ago

"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 problem solving skills would be able to do that their first time thinking through this problem so earnestly!" All this tells me is that tech interviewing is horribly broken. What we have here is a story of a guy with a little bit of experience who has (if his story is true) successfully learned how to game the interview systems at dozens of startups. If you interview people, this article should terrify you. You can argue that it isn't "gaming" if the guy turns out to be a good employee, but that's wrong. If he can trivially game the system, so can anyone else with the ability to go to dozens of interviews and remember questions. There's a fix for this problem: make the interview about more than the answer to the stupid question. If the candidate answers your question a little too quickly, ask something harder. Chase down a detail. Pick an experience on the resume (and not an obvious one), and dig as deeply as you can. Good candidates know the details. Bad candidates don't have details you can chase. If you're interviewing correctly, no candidate should be able to come in and snow you with some regurgitated C code from previous interview experience, because you'll be able to out-flank them at every attempt to cough up a line. Unfortunately, there's a corollary: you need to know the subject better than the person that you're interviewing. If you don't, you have no hope of screening for good people.

kakuri 15y ago
It sounds like in this case, this guy might be a good candidate - look at all the effort he put in and his ability to remember things, think critically, and learn. On the other hand, there are plenty of competent programmers not willing to put up with this nonsense, and the companies are going to miss out on them.
sgrove 15y ago
Yeah, that was more or less the point of the post. For applicants, don't feel nervous, it's a silly game just to see if you know some of the puzzles. For people hiring, go ahead and use this as a first-pass filter, but realize that it's easy to game (by someone who's trying hard and learning, so there is a positive signal in that). It's going to be important to go through and work with them for a period of time in a let's-date-before-we-marry relationship. As an employee, I always insisted on a contracting relationship before an employment relationship. Like I said in the footer, Heroku really seems to do this the right way, and it shows. Kudos to them. And everyone else needs to step up their game.

breadbox 15y ago

So ... what exactly is the turing-machine dog question? A google search left me unenlightened.

andrewflnr 15y ago
I figured it was just humorous nonsense.

deleted 15y ago

[deleted]

observer1 15y ago

"....this process, starting from ~50+ raw leads whittled down into ~40 initial phone interviews/coding challenges, which went to ~25 next stage interviews, eventually down to ~6 really good offers, all in about ~1.5 weeks." Does this timeframe seem a little dubious to anyone else? I count 65 technical interviews plus interviews with hiring managers, etc., followed by receiving offers. And all of this happening in about 8 days. This story would be a lot more believable if it had a realistic timeframe.

sgrove 15y ago
Nope, it's true. I woke up early in the morning (easy to do sleeping on the kitchen floor in mountain view without a heater), went through craigslist every morning, had an email template I'd individualize for each posting, and send it out. I'd work through the code challenges as they came in, set phone interviews into the late night, in-person interviews in the city during lunch, etc. It happened, I took it pretty seriously because of the impending cliff of being homeless.
angelbob 15y ago
The 25 next-stage interviews are the only part that sounds even slightly unrealistic to me. The phone interviews are 30-60 minutes each, so 40 of them is no problem (20-40 hours of work). The next-stage interviews are going to vary from 1-2 hours to a full day, so I assume he didn't do many full-day interviews in that 10-11 days, or probably 7-8 workdays. But startups are often far more willing to do remote interviews, interviews at weird times, interviews on weekends... It would be a packed 1.5 weeks, though.
Timothee 15y ago
Besides the apparent mismatch between hours in a day and hours necessary for all that to happen in 1.5 weeks (well, it's technically possible), what surprised me was just even that 40 companies out of 50 were responsive enough to schedule phone interviews in that time. And next stage interviews after that. And make a decision to hire him. Especially for a self-proclaimed bad coder. So, I agree with you, but this is not really the point of the post. The point is that interviewing is a game that you can master with practice.
15y ago

rauljara 15y ago

I was flabbergasted that someone was asked implement a linked list in Ruby. My initial reaction was 'That is an incredibly stupid thing to do.' My slightly more in depth reaction was "Isn't that what mutable arrays are for?" And my final reaction was, "Maybe I'm missing something." At which point I tried to figure out the benefits of a linked list over a ruby array. I wasn't able to come up with a good reason to use a linked list in Ruby, but maybe someone could enlighten me.

kenjackson 15y ago
Linked lists and arrays typically have different perf characteristics (although I don't know how Ruby arrays work). For example if I give you an element of an array/linked list and tell you to insert a new element adjacent to it -- a linked list is a constant time insertion, whereas arrays are typically O(n).
- tptacek 15y ago
  That's a sensible point, but interpreter and runtime overhead crushes any cost savings you might get from adjusting links instead of the whole array backing store. (Ruby arrays, at least in MRI, are basically STL vectors). 1000 inserts to the middle of a 1,000,000 element Ruby array happens so quickly you can barely perceive the delay. The same insert pattern to a basic Ruby linked list sets my machine on fire.
  - kenjackson 15y ago
    Wow, that sounds painful. So do people not use things like graphs or trees in Ruby due to perf? I actually used to do Python development -- about 13 or so years ago, but had to quit due to perf just being abysmal for applications intended for customers (and started focusing on C++). Is Ruby today similarly bad for apps that make heavy use of data structures like trees/graphs as Python more than a decade ago? EDIT: Updated to remove the term 'toy-apps'
    - tptacek 15y ago

langsamer 15y ago

I think a much better indicator of how valuable a person will be in your company is not if he can solve puzzles on the fly but how munch time he puts into coding. If a person is coding in his free time and keeping up with technology and experimenting even though his current job doesn't require it, that person is more likely to have a breadth of knowledge that will pay dividends over time. Something like that cannot be gauged by him/her solving a "reverse-linked-list" problem. Furthermore, a person involved in the community is more likely have in-roads with other strong developers, which again might pay dividends in the future in terms of hiring.

gcp 15y ago
In my experience interviewing candidates, the two are very strongly correlated. A person coding in a lot, including in his free time is more likely to have implemented a wide variety of things, and will be much more hands-on to solve these kind of riddles/exercises, than a person with only book knowledge who coded the same kind of stuff for years on an end.

codenerdz 15y ago

I had a similar experience interviewing after being off the job market for a quiet a few years: You will be rusty initially, but then you will pick up steam. Just like in your "real life", solving interview problems is not about reinventing the wheel with 100% custom solution, its about pattern recognition where the pattern is a problem you know a solution for. The more problems you solve(and possibly fail) the more data your internal pattern recognition algorithm(your brain) has to help you with the solution. I dont see it as gaming the system, I see it as being able to prove that you are capable of problem solving.

sgrove 15y ago
Yeah, it's a positive signal that someone was able to pick up from past failed interviews. It's a weak filter, but it's fine to have. From there, it's best to work with the person on short projects, and then hire them as a contractor to find out if they're a culture match and can solve the problems you're facing at an acceptable rate and in a maintainable way before hiring them on as an employee.

russell 15y ago

I use a similar approach. I spent 20 years as a consultant, so I did a lot of interviews. I would send out lots of emails. I didnt do many tailored emails, but I did a carefully tailored cover letter designed to be amusing to the HR ladies. You have to get by them first. I figured the first few interviews were throw-aways, just to get my interviewing skills back up to speed and to find what this years interview questions were. Yes, they go in fads. One year the programming task of choice was to reverse the words in a string. See it a couple of times and you get too be pretty proficient. I keep a stock of questions to push back. I havent issued programming challenges, but I have asked, "What is your pain point? What technical issue is causing you problems?" Usually we get into a long discussion of the challenges theyare facing.

shard 15y ago
What did you do in your cover letter to amuse the HR ladies? Please share.
- russell 15y ago
  Do you remember the Johnny Cash song "I've Been Everywhere... Chicago, Reno, Fargo"? Sometimes I think my resume reads like that. After I added those lines, I got a 25-30% increase in responses.

brown9-2 15y ago

I started asking if I could assume TCO - usually knowing they would say no, but it would set them back a bit because that's an unusual question. What does TCO here mean? Tail-call optimization?

anonymoushn 15y ago
Yes. For a moment I wondered why he wanted to use TopCoder Open in the middle of an interview.
- r00fus 15y ago
  or Total Cost of Ownership... I guess I'm hopelessly "enterprisey".
  - AdamTReineke 15y ago
    That's two of us.
sgrove 15y ago
yup.

seank 15y ago

It's worth mentioning this as a counterpoint to 'startups don't reply': http://news.ycombinator.com/item?id=3351699 http://news.ycombinator.com/item?id=3351699

tptacek 15y ago

Programmer interviews are famously terrible. Take a second to think about FizzBuzz, why anyone ever thought we'd need something like it, and how it actually continues to serve a purpose. Everyone thinks they're better at interviewing than they are. They often have a survivorship bias. In clueful companies, it's not that dead weight doesn't get hired. It just gets washed out. Interviewers tend to remember the people they end up working alongside. There are dev questions that are harder to study for. They tend to be open ended. A few of my favorites: * Describe some code that tends to follow you from project to project (I mostly interview C devs, so I tend to ask this as, "what's in libyou.a?"). What's in your bag of utility functions? * What's the worst library you've ever worked with and why did you hate it? * Estimate the amount of time it will take you to complete system X. Drill down, both by forcing the candidate to specify components (do an informal design exercise) and then cost each of those components. Estimation is an extremely important skill regardless. * What's a piece of functionality that tends to crop up on lots of projects that you'd never implement yourself if you had the option of using a library? (Usually, I'm trying to get C programmers to tell me that they would not in fact hand-hack doubly linked lists out of structs with nested struct pointers). * Describe the last system you contributed significantly to; how did those contributions break down structurally (did you write libraries for X, Y, Z; did you write plugins for X, Y, Z; did you extend the engine in X, Y, Z ways). Now describe the trickiest bug you ran into on that project. For C devs, I always used to ask, "You're testing a component you just wrote and finding that it crashes in malloc. Diagnose the problem." This is less relevant now, but there are probably surgical questions you can ask e.g. a Python dev that verify that they actually have the experience of working professionally in the language.

steve8918 15y ago
These are great questions. The one question I use with experienced hires is "Talk to me about the hardest bug you've ever worked on." I will keep drilling down to deeper and deeper levels to figure out how much they actually know, as opposed to memorize.
zmj 15y ago
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.

steve8918 15y ago

I call complete and utter bullshit. Each "technical interview" I've been to is about 3-6 hrs. I've yet to see a Silicon Valley technical interview where it's not at least 3 hrs, meeting with 3 people. So right there, fitting 25 "next stage" interviews in 1.5 weeks is bullshit. Where is he going to find the time for 40 initial phone interviews? That requires talking with the recruiter, and then the recruiter scheduling time with a developer. Anyone who has realistically interviewed in Silicon Valley knows that recruiters are very slow, and things tend to get muddled up very easily. In 1.5 weeks, assuming they don't interview on weekends, that's 6 1-hr phone screens, plus 3 on-site interviews per day. The logistics simply don't work. It's a complete lie. If he had said 1 month, then it still would have been impossible with 1.5 phone screens and 1 on-sites per day, but it would have been slightly more believable than 1.5 weeks.

sgrove 15y ago
Rough. But you're free not believe, I don't have a problem with that.
- steve8918 15y ago
  Sorry buddy, but please explain the complete discrepancy in what you reported. How do you fit 3 on-sites and 6 interviews per day? Even if your onsites were 1 hr long and they offered you a job after a single interview, you still have to drive back and forth to each location. How did you have time for the 6 phone screens per day?
  - sgrove 15y ago
    I didn't have a car actually. I just scheduled all the interviews as close to possible every day, and walked around SOMA/FiDi from morning until evening going through different stages of different interviews - initial chat (morning coffee/lunch/dinner/drinks), whiteboarding session, meet with the team, build a mini-project, discuss final offer. Each successive stage is more time intensive, but there were also fewer of them. There's a lot of noise, especially in the beginning, so a lot drop off very quickly. From there, it was just a matter of tightly packing the schedule and doing it from day to night. Like I said, the "you'll be homeless again very soon" factor was a big one for me.

eru 15y ago

I can't post to the site, could somebody who can (or can contact the author in some other way), leave a note to the author, notifying him of a typo in "For people hiring, remember that anyway can pass yours tests with enough experience interviewing, even someone as bad at coding as myself." (It should be `anyone' not `anyway'.) Thanks!

sgrove 15y ago
Got it, thank you eru!

troygoode 15y ago

People talking about how he "hacked the interview process" are missing the point: as a hiring manager I'd gladly hire this guy even knowing that so much of what he did was not entire genuine. He took a problem (I need a job), implemented a solution (applied and interviewed at a TON of places in that short of a timeframe), and successfully iterated on that solution until he had completely mastered it! In a very short time period he went from being unable to solve a variety of programming problems (or doing so poorly) to internalizing the how & why of the optimal solutions - this is what good software development is about! I care a lot more about initiative and problem-solving skills than I do reversing linked-lists - this guy has the former two in spades.

overgryphon 15y ago
Sure, if you're looking for someone who is hard working and willing to learn, then this type of candidate is perfect for you. But if you're screening for candidates with development experience who you can rely on for technical knowledge, the idea that someone can game your interview process in less than two weeks without previous knowledge is horrifying. But I'm guessing that people looking to hire experienced candidates aren't basing hiring decisions on questions about reversing linked-lists.
- kamaal 15y ago
  I think the point he was trying to make was. If you are productive enough and serious with a little skills you are can be hired. The reason being you work hard your way towards success. This is far better than the person who knows merely facts. Knowing doesn't always doing. But in most cases if you are doing something you are likely to know what it is.

krupan 15y ago

A lot of discussion here about memorizing the programming questions, but I think the most interesting part of this is when he turned the tables at the Do You Have Any Questions For Me stage and really interviewed them. I haven't asked anyone a programming questions like he did, but I did ask some tough questions about the team, work environment, management style, company goals (looking for a quick exit? in for the long haul? etc.) at my last job interview (after some good friends gave me the advice) and it both gave me a lot of insight into the company and team that I was considering working for, and I think it impressed them that I was thinking about those things. In short, know what you want from a team, manager, and company, and take time to interview the people interviewing you to make sure they have what you are looking for.

systemizer 15y ago

I had a similar experience. This past Fall, I was interviewing with multiple companies, and I received questions that were very similar.... some being the same exact thing. I was nice, however, and told them out front that I had seen the problem before and asked for another. I don't regret doing that; some may have passed the interview by keeping quiet even though they had seen the problem, but those people won't go far in the world because they cheat. They will eventually get called out for it and lose their reputation.

nadam 15y ago

I don't understand why is there such a strong emphasis on these kind of interview questions. I think showing a piece of nontrivial code which the candidate have created in the past tells a lot more about the candidate. For example this tells more about me than the interview questions I usually got: http://codeclamp.com/ccui.js http://codeclamp.com/ccui.js , because it tells about how I think long-term, how I solve relatively hard and relatively complex problems, not how I survive a quick interview (solving relatively easy algorithmical problems but under very high time pressure.). (By the way, if you have an interesting well paying job for me, I might be interested...)

pnathan 15y ago

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.

tikhonj 15y ago
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.

tldrtldr 15y ago

Isn't there a book dedicated to coding interviews? http://www.amazon.com/Cracking-Coding-Interview-Programming-Questions/dp/098478280X http://www.amazon.com/Cracking-Coding-Interview-Programming-...