7 ms·

[Interviewers] ask simple coding questions like the fizzbuzz, but [their] applicants still fail – even ones that shouldn't. [...] [Y]ou're using the wrong mediu

• Tuna-Fish 16y ago
  The problem with the Newcomb solution is that it is aimed at the high-end of tech companies, which are ultimately willing to pay very high portion of the company worth for the top talent. Most companies employing programmers today are not such companies -- they cannot possibly hope to hire A+ employees, but they are trying to build a solid team of B- or C-level programmers, just hoping to keep the F-level out. As far as I know, this is a total crapshoot and the ones succeeding in it do so mostly by luck.
  • gvb 16y ago
    Understood and agreed. I thought about editing my comment to add a disclaimer about "if you can implement it" because many companies cannot. On the other hand, the same companies that are decrying "99 out of 100 cannot program" also claim to be in the same high-end tech company space as Newcomb.
• RodgerTheGreat 16y ago
  The general principle, as I understand it, is that if you can't write a very simple program like FizzBuzz under pressure, you will also do poorly when you're doing harder tasks with less pressure. This aligns pretty well with my experiences, both in school and industry. Really, if you can't write a few lines "on the spot", what use are you going to be to an employer? In the real world there is always some deadline. I don't always expect perfection in a whiteboard scenario, but there's a world of difference between a blank stare and a 90% correct solution with an off-by-one.
  • St-Clock 16y ago
    I disagree. Give me a hard problem and a short deadline, leave me in front of my computer with my environment set up (so I can do some quick trial-error), don't look over my shoulder to evaluate me (but you can help me if we're doing pp), and I'll succeed. Give me an easy problem over the phone (I'm a visual) or on a whiteboard (my handwriting is not good) while timing me, and I will fail. But in the end, I like this kind of interview, because I don't want to work for anyone who would evaluate me like that.
    • Lewisham 16y ago
      The other thing is that these interviews almost always enforce no Internet access. If I was in a position to hire, I'm looking for people who can solve problems, not those who can remember the Java API in their head. If their first instinct is to open Javadoc, then my reaction should be "good, they know where to look for to make sure it's correct" not "God, why can't they just do this [arbitrary task]?" I'm hoping to finish my PhD and become a professor in Computer Science. My plan, given university constraints, is to never once offer a written final. I've not once taken an exam where I was confident just writing code down. It doesn't make sense. Offer them a final on a computer with Internet access, but with a sufficiently difficult problem that it can't just be Googled for a complete answer. Their web access logs are turned in with their exam, so I can see if they copied something if it looks suspect, or if they're borderline I can give extra credit for going through a mental process that shows promise.
• rdtsc 16y ago
  The person who is interviewed should be interviewed at least for a full day. They should be presented with a large set of problems, both "fizzbuzz" type, design problems, debugging problems. They should talk to the top technical people in the company, with those they will be working with, and with as many other people as possible. This is even more important in a small company. A small company cannot afford to hire a dead weight. A couple of those will kill the company -- they waste resources, don't get work done, and, what is perhaps very dangerous, drive away top technical talent who does not tolerate mediocrity.
  • deleted 16y ago
    [deleted]
  • deleted 16y ago
    [deleted]
  • acgourley 16y ago
    This sounds great in theory, but can also be a big time waster for your top dev talent. Especially so considering you usually start hiring when you're especially crunched for developer resources. The interview process should be extensive, yes, but it should also be spread out in a way that allows you to fail candidates early. Blocking out a day of interview time at once can be inefficient - rarely will that person be sent home early (for various reasons) and they are now just wasting a bunch of peoples time, and their own.
    • JanezStupar 16y ago
      Think of all the time they will be wasting with this person if she turns out not to be a good fit. You presumably want people who will enhance and help your top talent.
      • rdtsc 16y ago
        That's exactly the point and this inversely related to the size of the company. Imagine if IBM hires a dead weight, the company is so big and there are so many other positions that the company as a whole will not be terribly hurt (unless it's the CEO perhaps). But with a small company, when you have 5 people and you hire the 6 and it turn out to be a bad choice, it could kill the company.
• jerf 16y ago
  This doesn't solve the problem for everyone else, but when interviewing, solve the problem for yourself: Bring your own laptop. (Or borrow one if you need to!) I can't believe in 2010 this isn't "conventional wisdom", but heck, take advantage of the competitive advantage while you can. No matter how impressive your linked list reversal is on the whiteboard, running code is even more impressive.
  • gvb 16y ago
    (blush) That didn't occur to me. Good thing I haven't had any "program on a whiteboard" interviews. Thanks for giving up your competitive advantage to all the HNers. :-) Personally, I hate to program on someone else's computer. I run pretty bog-standard linux with minimal plugins and aliases (in part, so that I'm comfortable in a bog-standard environment typical of servers). The problem is, lots of people have customized the crap out of their system. The result is added discomfort when I try to do something on their computer.
  • dlo 16y ago
    Someone once brought in his laptop. He showed me a running program and gave me a tour of his code. It was very impressive.
    • Luyt 16y ago
      That's very much like what I would ask from a candidate developer: "Bring your laptop and show me some stuff you made in the past year(s), and expect to implement a small programming problem I give you. You may use your favourite development environment for that."
      • Leynos 16y ago
        What happens if they don't have a laptop?
        • ojbyrne 16y ago
          Wouldn't that be some kind of a contra-indication? Not a definite "don't hire" signal, but pretty close.
• mattm 16y ago
  >> The same people ... don't understand why someone is uncomfortable writing a program on a whiteboard or, even worse, over the phone Exactly. I loathe whiteboard interview questions. In five years of programming, how many times have I ever written or looked at code on a whiteboard to solve a real, work problem? Zero. Yet some people think the best way to learn about a candidate is to put them in a situation far removed from a real, daily work situation and see how they perform.
  • btilly 16y ago
    Full working code on a whiteboard, is very uncommon. However a lot of the time useful code snippets go on a whiteboard. Particularly in informal meetings. More than that, design diagrams go up there as well. There are some interview questions that I like which force people to put up the sort of pictures we actually draw in meetings - for instance come up with the tables backing a particular application. At the place where we asked that, you'd find yourself doing that after you got hired as well. If you don't use whiteboards in these ways, then I'm going to suggest putting whiteboards near developers and consciously try it. You'll be amazed how well it works.
• dgant 16y ago
  One of the most eye-opening lessons of my professional life: I had a set of coding questions to give final round candidates to complete in person. By paper, whiteboard, or laptop -- their pick. The success rate for candidates was about 25%. I then started giving the same questions as a time-limited take-home test, for first-round candidates. The success rate jumped to almost 100%. Same questions. Less-filtered candidates. The difference? The primary determinant of success was interview environment, not candidate ability.
  • znt 16y ago
    That's exactly what happened to me in my recent interviews. Some company wanted me to write a simple string reversion and prime number finder programs on paper, I failed because I'm not used to code on paper. Some other company wanted me to write a server client program which takes a file from client and saves it to server. I completed it on my laptop on the same day when I got home. If the interviewer is going to make the interviewee take a written test; it must be about concepts, designs and stuff, not implementation.
    • ig1 16y ago
      Out of curiosity was the failure at an algorithm level or at a semantic level ? (i.e. could you not put the algorithm down on paper, or was it just a case of not remembering the correct syntax or libraries)
      • znt 16y ago
        Algorithm was fine in both cases, I had the problem solved in my head but couldn't pass it onto paper effectively. I had trouble remembering semantics. Because I use autocomplete functions of IDEs a lot.
      • puredemo 16y ago
        Personally, (visual and diagnosed ADD) it's very difficult for me to think through algorithms under pressure, or in environments with distractions. Stuff that takes me five minutes in a quiet, private, relaxed setting can take me an hour to think through in an environment with more people. Lab courses in college were particularly frustrating for me for this reason.
• bitwize 16y ago
  My company does whiteboard interviews. The important thing is not getting the right answer. We don't bother to attempt to compile the applicants' code, so we don't even know if it works. The idea is to get a glimpse of how they reason through a problem. After they've roughed up a solution we ask them follow-on questions like, "How would you test this? What corner cases would you check?" If it suddenly dawns on them that they forgot about certain corner cases, that's considered positively; if they blunder confidently on through without checking to see if what they'd written would really work, that's considered negatively. We also ask them a design question, typically something like "design an automatic retrieval system for one of our robots". Again, not being mechanical engineers we have no way of telling whether their ideas would actually work. It's the thought process we're interested in looking at: how detailed they can get, how they anticipate and solve or work around problems with their design, etc. Given that we have a pretty top-notch software team, I'd say our system has worked out rather well. :)
• ori_b 16y ago
  You should be able to reason regardless of how big or interactive the surface you're messing around with is. The reason that big monitors are useful isn't because it makes you smarter or more able to reason about trivial problems. It's because it provides more space to cross reference code, more space to look up documentation, and so on. For the sorts of questions that are being asked in an interview, you should be able to sketch out a solution on a whiteboard no problem.