4 ms·

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 do

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.
  - Someone 16y ago
    "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" That is what makes the whiteboard such a good tool: when working on a whiteboard, you can focus on the problem, not on pesky details. A whiteboard will never complain about API issues, function naming, etc. Not even by using squiggly underlines.
    - matwood 16y ago
      I agree and think people are getting caught up with writing complete running code on a whiteboard which should not be what the whiteboard is for. A whiteboard is for writing pseudocode to quickly build algorithms, work on design or solve other 'thinking' type problems. It's not for testing if someone knows obscure syntax issues (there are actual tests for that!). In school we were taught to work through algorithms and other design using pseudocode and pencil and paper. Doing this also helped reenforce that languages are very interchangeable using the same algorithms and designs. I wonder if that is simply not done anymore in school?
- dlo 16y ago
  I think another way to impress an interviewer is to come to your interview prepared to discuss (with technical detail) past exploits in which you were able to do just what you described. Most people just flow with the interview rather than try to (subtly) direct it in a way that is more favorable to them. This is a workaround for sure, but aren't programmers used to finding workarounds to impossible situations? Another option is to tackle the interview itself as a challenge and practice interview skills, such as whiteboard coding. I think Steve Yegge suggested this in one of this blog posts about how to interview at Google. Personally, I find this to be very impressive: You knew there was going to be whiteboard coding, so instead of complaining about it, you practiced it. If you (casually) mentioned this during one of my interviews, I would probably give you some extra points.
tocomment 16y ago
Deadline pressure != interview pressure. Also stressful deadlines are an indicator that sosmthing else is wrong in a company. The company should fix that issue instead of hiring people that can "program under pressure".
- bitwize 16y ago
  At my company (we make AUVs), stressful deadlines mean you're out on a boat and you've got ops personnel looking over your shoulder and if you can't push out that code fix or configuration change NOW then they may not be able to run missions for the rest of the day because the vehicle would be dead in the water and the sun is going down. Needless to say, actual software development in the office is pretty relaxed. But when you go out on ops, you will be in the pressure cooker and you will need to handle it.
- ig1 16y ago
  Plenty of code changes need to be made under pressure. Some recent examples from stories posted on HN: 1) Bug in Google authentication which allows websites running on App Engine to grab users email addresses without permission 2) Crunchbase making all historical searches public 3) Facebook downtime bringing down "like" buttons All three of these issues were for the companies in questions bugs that had to be fixed in realtime. Does it indicate that something is wrong with these companies ? - no. Any changing production system is going to suffer from bugs that on occasion will require programmers to be woken up in the middle of the night to urgently fix a bug.
  - arethuza 16y ago
    "Does it indicate that something is wrong with these companies" It means that their testing wasn't very good. If programmers are being woken up to fix something then something is very wrong with an environment.
    - ig1 16y ago
      You're never going to have 100% test coverage. Any complex system is going to have bugs. It's pretty much impossible to write even a small library without bugs, let alone huge websites with the complexity of Facebook or Google. Look at cryptographic libraries. Often they've been gone over line-by-line by hundreds of experts in the field, have extensive testing both unit and field. Yet bugs still get found in them.

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.
- Someone 16y ago
  "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" That is what makes the whiteboard such a good tool: when working on a whiteboard, you can focus on the problem, not on pesky details. A whiteboard will never complain about API issues, function naming, etc. Not even by using squiggly underlines.
  - matwood 16y ago
    I agree and think people are getting caught up with writing complete running code on a whiteboard which should not be what the whiteboard is for. A whiteboard is for writing pseudocode to quickly build algorithms, work on design or solve other 'thinking' type problems. It's not for testing if someone knows obscure syntax issues (there are actual tests for that!). In school we were taught to work through algorithms and other design using pseudocode and pencil and paper. Doing this also helped reenforce that languages are very interchangeable using the same algorithms and designs. I wonder if that is simply not done anymore in school?
dlo 16y ago
I think another way to impress an interviewer is to come to your interview prepared to discuss (with technical detail) past exploits in which you were able to do just what you described. Most people just flow with the interview rather than try to (subtly) direct it in a way that is more favorable to them. This is a workaround for sure, but aren't programmers used to finding workarounds to impossible situations? Another option is to tackle the interview itself as a challenge and practice interview skills, such as whiteboard coding. I think Steve Yegge suggested this in one of this blog posts about how to interview at Google. Personally, I find this to be very impressive: You knew there was going to be whiteboard coding, so instead of complaining about it, you practiced it. If you (casually) mentioned this during one of my interviews, I would probably give you some extra points.

tocomment 16y ago

Deadline pressure != interview pressure. Also stressful deadlines are an indicator that sosmthing else is wrong in a company. The company should fix that issue instead of hiring people that can "program under pressure".

bitwize 16y ago
At my company (we make AUVs), stressful deadlines mean you're out on a boat and you've got ops personnel looking over your shoulder and if you can't push out that code fix or configuration change NOW then they may not be able to run missions for the rest of the day because the vehicle would be dead in the water and the sun is going down. Needless to say, actual software development in the office is pretty relaxed. But when you go out on ops, you will be in the pressure cooker and you will need to handle it.
ig1 16y ago
Plenty of code changes need to be made under pressure. Some recent examples from stories posted on HN: 1) Bug in Google authentication which allows websites running on App Engine to grab users email addresses without permission 2) Crunchbase making all historical searches public 3) Facebook downtime bringing down "like" buttons All three of these issues were for the companies in questions bugs that had to be fixed in realtime. Does it indicate that something is wrong with these companies ? - no. Any changing production system is going to suffer from bugs that on occasion will require programmers to be woken up in the middle of the night to urgently fix a bug.
- arethuza 16y ago
  "Does it indicate that something is wrong with these companies" It means that their testing wasn't very good. If programmers are being woken up to fix something then something is very wrong with an environment.
  - ig1 16y ago
    You're never going to have 100% test coverage. Any complex system is going to have bugs. It's pretty much impossible to write even a small library without bugs, let alone huge websites with the complexity of Facebook or Google. Look at cryptographic libraries. Often they've been gone over line-by-line by hundreds of experts in the field, have extensive testing both unit and field. Yet bugs still get found in them.