Hacker News Reader

Comment by RodgerTheGreat | Hacker News Reader

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.

View on HN

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.

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.

"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.

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?

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.

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".

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.

"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.

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.

My point isn't that bugs happen - of course they do and of course they get missed by tests. It is that if you pull someone out of bed to fix a problem I would suspect there is a high likelihood that you will be introducing more problems when you deploy this fix unless you run a full QA cycle after the change.

don't know about 1. and 2. The 3rd - Facebook - from what i read about it (bug in cache invalidation/update, herding the db) as well as recent problem at Foursquare (uneven sharding on MongoDb overloading a shard), as well as the production problems i have faced and resolved personally, have nothing in common with interview questions i've been asked so far in my life. Not even close, not even in the same Universe.

The problem is that real world bugs are often too complex to use in interview questions. From my experience solving production bugs often involves having to piece together bits of information from logs, databases, etc. and making educated guess to track down the source of the bug. It's pretty hard to replicate in an interview environment.

Spotting bugs in code, operational questions, and writing code samples are probably the closest you'll be able to come within the time restrictions of an interview.

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.

Occasionally I have to troubleshoot our production code while we lose several thousand dollars per hour in revenue and jeopardize business partnerships. Sometimes it's just pointing out which servers need a kick in the head, but sometimes it's a recent code change that didn't handle all cases and we need to fix forward on the spot (because rolling back all interdependencies would take longer).

Reply on news.ycombinator.com