Hacker News Reader

Comment by danesparza | Hacker News Reader

[sarcasm]Please continue to use this question. It’s a wonderful marker for candidates (like me) who don’t want to work with folks who think questions like that are useful.[/sarcasm]

To be honest, I think it’s far more interesting to set aside a real world problem that you have encountered at your company and see how a candidate would think through it (out loud, of course). Many issues you’ll need to solve on a day-to-day basis have nothing to do with programming — and instead have to do with knowing related technologies (like a TCP/IP network, or a database) and how they interact.

You might be shocked to discover how many developers have a deep understanding of algorithms but can’t troubleshoot/design/architect/solve their way out of a paper bag.

Also: the thought of you ACTUALLY chewing your arm off is morbidly humorous. Thanks for that. :-)

View on HN

"You might be shocked to discover how many developers have a deep understanding of algorithms but can’t troubleshoot/design/architect/solve their way out of a paper bag."

I might, but I have been shocked by the number of developers in the opposite situation: can create wonderful, beautiful designs but can't actually write code better than your average bonobo. And I won't even mention troubleshooting or actually solving problems. If you can't actually write decent code, I don't actually care if you can design or architect and I doubt your other skills would actually help me if I'm looking for a programmer.

This problem in no way requires a "deep understanding of algorithms". Hell, writing a balanced tree is hardly deep understanding, and I admit I'd have a bit of an uphill struggle with that myself. But this is just basic programming logic. If you have any problems with that, I don't care if you're Bob Braden or Edgar Frank "Ted" Codd.

Couldn't have said it better.

As the article says, this is fizz buzz. The purpose of it is to decide if you can program, not if you're a good programmer and not if you're a good engineer. Also, it's not an algorithm question. Actually, I'm not sure why I'm writing this up, he's specifically addressing your point in the article.

> I think it’s far more interesting to set aside a real world problem that you have encountered at your company

I would too. But the domain space of (things that aren't dreadfully trivial) intersect (things I can explain to an outsider in <10 minutes, including the relevant domain and context) intersect (things that an outsider can make reasonable progress on in the remaining 35 minutes) intersect (things I didn't just bloody fix when I came across them) is very, very small. I'm not even sure all those circles even overlaps, ever.

If this is just Fizz Buzz (ie, a very low-level filter to see if you can program at all), why is he testing for elegance? For cleanliness? For speed of writing on a whiteboard, for god sake? He may claim it's Fizz Buzz, but he gives it and treats it like a normal programming test, with all the problems associated with it.

I agree. This is the most important point in this discussion.

The whole concept of fizz buzz for an in-person whiteboard interview is absurd. The type of candidate who would fail that test should have been filtered out way earlier in the process and the type of candidate who hasn't been filtered out by that point (i.e., a 'top candidate') would be extremely insulted.

I think the people who ask asinine questions like this haven't done their due diligence going in. They haven't looked at the candidate's online presence (including GitHub) nor even read her resume.

Why are you requiring 'things you didn't fix when you came across them' ? It'd seem to me those'd be ideal - and they should be sitting around in source control.

[sarcasm]Please continue to use this question. It’s a wonderful marker for candidates (like me) who don’t want to work with folks who think questions like that are useful.[/sarcasm]

That's a two way street. Asking this question to ward off people who are offended to be asked it sounds like a net win to me.

Completely agree.

Also, some of the replies to the original article got me thinking about my own experiences as an interviewee. I realized that those engineers who have interviewed me in the past and did not ask much technically have been amongst the weakest engineers I have worked with. Really nice people, not really good engineers.

> I think it’s far more interesting to set aside a real world problem that you have encountered at your company and see how a candidate would think through it (out loud, of course).

So how do you do that consistently? Do you just go with whatever you were working on last week? Do you keep your favourite bugs to show to candidates?

> Many issues you’ll need to solve on a day-to-day basis have nothing to do with programming — and instead have to do with knowing related technologies (like a TCP/IP network, or a database) and how they interact.

Both are important, but programming is easier to test. Most candidates haven't used exactly the same technologies, so unless you happen to be an expert on every database under the sun it's very hard to ask a fair question about how to use one. And my impression is that it's easier to cargo-cult how to connect to a database than how to write a binary tree (though I've certainly seen people do both).

I am getting asked to write a job description for new person. "What is required?" Basically I would be happy with someone who didn't have any of the required skills, as long as they had a decent attitude and were willing to learn, (and had some sort of background that was relevant). But apparently we need required skills on the ad.

I was thinking about this the last time we were hiring at work, and decided to try to take notes the next time I find a bug or issue that could be repackaged as a hiring challenge.

(I haven't succeeded yet, have been too distracted trying to solve the actual issue to remember to take notes...)

So is your argument actually that it's not necessary for people to be able to do this? Or is it that it's not nearly in-depth enough. If you're arguing the latter, I'm pretty sure everyone agrees; this was described as his version of fizzbuzz, to weed out people who literally just can't program. If you're arguing the former, that seems insane. Knowing how a TCP/IP network works is great, but if you're incapable of writing code to implement your knowledge, you're not very useful

C'mon, this is not about knowing some algorithm by heart. He clearly describes the specifications and gives a test case. With that information you should be able to "troubleshoot/design/architect/solve" a solution to his problem even if you've never seen it before.

This is a fizzbuzz, someone posted a quite sparse C++ solution in 75 LOC above. C++ ! That would be half in python, less than one laptop screens height.

> You might be shocked to discover how many developers have a deep understanding of algorithms but can’t troubleshoot/design/architect/solve their way out of a paper bag.

In interviews I'm curious to hear about developers' favorite debugging tools or techniques for precisely that reason.

Reply on news.ycombinator.com