I think coding questions are really important. You see their logic flow. Now stupid coding questions (in a list, find all the number pairs that add up to another number in the list) are terrible. They're complex and even good programmers need time to think about them. Fibonacci is one that people expect, so they look up all the variations and you get people who are good test takers (would ace a GRE/MCAT) but not good designers.

You want a simple question that isn't common, but that shows how they break down a problem under stress. Example: you have an input with paragraphs at 80 characters. Write a function to return the same paragraphs wrapped to 40 characters. You cannot break a word and must maintain paragraphs.

Great design questions: a word problem (You have an autoshop with, staff and customers. Customers can own multiple cars. A staff member gets assigned to a car with a work order...) .. draw an ER diagram. This is actually a pretty low stress question. It should be straight forward. If someone draws a terrible ER diagram with lists in tables and no normalization, or unnecessary relationships (or you have to keep asking them to label 1-to-n/n-to-1 relationships and they struggle), you know they're not going to be good at designing database schemas.

Another great general knowledge question: "A user types in a web address into a web browser and hits enter. Describe what happens. Go into as much detail as you can." This gives people a change to elaborate as much as they can. People can talk about DNS, HTTP, load balances, HTTP request/response, cookies, load balancers, web apps vs static content...

Questions need to be geared to the job. You don't ask someone to draw an ER diagram if they're being hired to rack servers and setup VMWare. Likewise you don't ask a web developer to write a function to do matrix multiplication.

I often ask the web browser one and find it quite illuminating. Best answer so far started with something like "Well, there's a microswitch in the keyboard if it's a decent one, and a circuit that debounces the input - err, is it a USB keyboard or a PS/2 one? Hmmm... How long do I have to answer this question?" THAT is the guy you want to hire...

Last time I got that question, I started with nerve impulses.

Still not enough: If you wish to explain a web-request, you must first invent the universe.

"Describe an HTTP request? Tricky.... What's the mass of the electron in this hypothetical?"

I did actually start my answer to that one with 'Look, I'm just going to skip over the microcontroller in the keyboard and the USB protocol --- is that OK?' and was met with a calm, 'That's fine.'

I feel like there is a happy medium there.

> In a list, find all the number pairs that add up to another number in the list.

You're saying this is a bad question because it's too complicated? Am I missing something? It really doesn't seem more complicated than the paragraph question to me, but maybe I'm having a brain lapse.

The entirety of HN seems to have something against Competitive coding.

My company has been giving the fizzbuzz for students applying for internship, with any language they wish and extra for style points.

The results speak for themself. All the good applicants do it in no time, without hesitation and give a perfect answer and usually some style points on top. The ones who have second grade coding skills have always something wrong with it.

It's a good 5 minute test whether someone can code or not. It shouldn't be the only test, of course.

How do you know the people failing your interview process have "second grade coding skills"? The fundamental challenge with evaluating interviews is that companies don't hire people who flunk interviews - so there is no easy way to reliably measure the false negative rate. Does fizzbuzz ability correlate with coding ability? Maybe, but you'd have to hire people who fail fizzbuzz to definitely answer the question. I know that I use google extensively at work - interviews don't allow you to use search.

I'm not sure about OP, but there is a tech company that has said it hires people who fail their interviews occasionally to see if their interview process is working. That company is the one that is the subject of this thread.

Can you cite your source? I haven't seen this anywhere.

I haven't read it myself, but I heard that's what Laszlo Bock said in Work Rules.

We actually do let people use Google during our code interviews. They'll use it at work, so why not.

We do watch them work though so if they just copy and paste from stack overflow and they don't understand the problem, it's pretty obvious.

It depends on the questions.

If you require using real, compiler correct language in a coding exercise, and the problem is not trivial, than allowing search is more than fair.

But the point of Fizzbuzz is being such trivial problem that it really should not require nothing more than an understanding of basic programming logic and constructs.

In my (limited) experience, there were instances where the candidate could not even decide on a programming language to use, I told them to use pseudo-code and they still flunked horribly.

Aside from that, Fizbuzz is rarely a dealbreaking task in itself, it tends to correlate pretty well with the overall performance, I would be surprised seeing someone failing fizzbuzz and excelling in the rest of the interview (once again, in my limited experience).

These were done in recruitment events at universities and the applicants were free to access Google if they wished. Some guys even went to the computer lab to do the assignments on a computer and then return a printout of their code. And we were completely fine with that.

But really, if an applicant needs to google to solve FizzBuzz, they don't have a firm grasp of the fundamentals. You're required to write one loop, a few if/then/elses and understand how the modulo operator works. Our jobs are much more demanding than that.

> Why the hell would you ask someone at that level basic questions like fizz buzz?

Because there are people applying for software engineering jobs that still can't answer those questions.

If you have a CS degree and cannot answer this type of question in your language of choice, you simply aren't ready for even a junior position in my opinion.

This type of coding exercise can potentially answer more questions about the candidate in two minutes than 30 minutes of softball questions about the candidate's past experiences.

I think that people who disagree simply haven't done much interviewing or haven't worked on a team with someone who couldn't do much more than copy/paste code from SO.

> I think that people who disagree simply haven't done much interviewing

Absolutely. Last time I went through trying to hire people was about a year ago. Easily 90% of the applicants we saw were completely unqualified. You have to have a way to weed them out.

I don't ask multiple questions like FizzBuzz, but I do ask for FizzBuzz. (I will explain the modulo operator if necessary because it doesn't come up that often in web development and people many forget about it until prompted.) Everything else about FizzBuzz (loop over a range, use a conditional, define a function, compare, etc.) is so basic you would think you wouldn't need to test it - but then you run into a person with 10 years experience who can't do it.

It's a (sadly) useful screen. Even more sad when you realize how popular and widespread that particular question is.

The question is, "why wouldn't you?" If the person is competent they will dismiss it in seconds and you can move onto something more interesting.

But this is Director level. You are wasting your time and their time. Far more important things to be factoring in for a director level.