[pp13]

My point was, his questions, doesn't really indicate if the candidate is a good programmer or not.

It could be the person studied up on all sorts of puzzles and famous algorithms online but hasn't really written or programmed anything.

Not all jobs require that much expertise. You could be doing some really simple programming work.

I think most interviewers ask these type of questions 1.) make themselves feel smart 2.) they get a kick out it

[eropple]

That wasn't much of a point, on your part. The second question in particular requires some not-entirely-simple breaking down into subproblems. The first one can be handled in such a way if you're unfamiliar with the mathematics behind it; it's easier, as are many things, if you remember combinations and permutations from math class but not at all unsolvable if you don't. His questions aren't bad at demonstrating important aspects of a programmer's problem-solving approach.

And your complaining that "not all jobs require that much expertise" is unfounded. I consider those to be novice questions, personally--and even if they weren't, you don't know what he's hiring for.

He's not being unreasonable. You, on the other hand, seem to be, and seem to be doing so in a rather defensive manner.

[pp13]

@eropple

So do you have data to back up your claims that; answering those questions determine if your a good programmer.

Yes, there are tons of programming jobs out there, that don't require much of those skills. Not all jobs are that innovative.

Most of the development jobs I have seen require you to come up to speed with the code base fast. So it's that code reading comprehension that I think is most prevalent.

[eropple]

I did not in any way, shape, or form claim that such questions determine whether or not a candidate is a good programmer. If you are going to respond to my posts, please respond to my posts and not what you think or wish I said in those posts.

No interview or interview question can determine conclusively that you are a good programmer. But they reduce the likelihood that you're not, and comments like your strident and hysterical analogy drawn between these really very simple problems and "write a SSL library!" are doing little to change my mind.

[pp13]

Ok, I didn't mean to offend you, I am sorry if I have.

That being said these are my thoughts on the subject of interviewing programmers.

When I just graduated college, I was all about puzzles and programming puzzles. My thoughts were that only people who could do these puzzles deserved programming jobs.

I was so wrong. Puzzles are something that you get or don't get. If your in an interview, and you haven't faced those combinatorial problems for a while, you could bomb, if someone asked you those questions.

Understood "fizzbuzz" problems are suppose to be the the lowest level of programming problems that any competent programmer can solve. If you want to fast screen candidates, go ahead and ask them.

When you get into problems, that require "tricks", either you get it or don't. It could be easy for some people and hard for others. There is no correlation of them getting it, to being good on the job, unless the problems are such that, the programmer will face them every day on the job.

Another good permutation problem, is subset sum problem. Come up with a program that determines if a array or list, can be partitioned into 2 non overlapping subsets, such that the the sum of both subsets equals each other. Print out both subsets if they are equal or state that it cannot be done. Is it possible to get better than O(n^2) for the optimal solution. That is fun one, but I don't think asking that would give you much insight into determining whether the programmer is fit or not.

I think interviewing is a really important task. It a really hard job to get right. If your a bad interviewer, the company you work for will eventually get a bad reputation.

Many software companies do not train people how to interview. That in our industry, is a huge problem.

There are many other things besides raw technical skills that will determine, how well the candidate will do at their job and at at the company.

Going over the candidate's experience in detail. Getting a feel for what they really want and expect from the job. Do you like the candidate's personality? What does your gut instinct say. What technical things do you need to ask that are relevant for that job, that you couldn't determine from the their experience? How would you design questions, relevant to the job at hand.

Just my random thoughts.

[Someone]

"Another good permutation problem, is subset sum problem. [...] Is it possible to get better than O(n^2) for the optimal solution."

AFAIK subset sum is NP complete, so I guess you meant O(2^n). Even so, I would not expect a programmer to tell me much about it.

[aplusbi]

Part of our interview process is having the candidate code-review some really bad code. The only problem with it is that it is biased against students/recent graduates. I'd say close to 90% of student/recent grad candidates do pretty poorly on the code review question.

[pp13]

What type of candidate are you looking for? Obviously recent graduates will not have that much coding experience and reading comprehension.

Are you looking for someone to write new libraries from scratch? Who can implement new algorithms and data structures from nothing. Someone who can write new protocols and publish it to the team?

Are you looking for someone who can read your code base? Just fix bugs?

This one problem I keep seeing, many software companies don't know what to look for. Everyone wants that "smart and gets things done", but do you what things need to be done?

[aplusbi]

I work for a financial software company and we have a lot of projects so it depends, really. Recently we've been looking for some frontend Javascript developers the project I work on. The interviews we've been conducting have reflected that - mostly questions on things like JQuery/Moo Tools, having the candidate code stuff using AJAX, etc. "Real world" stuff in other words.

We often hire C++/C#/Python/Perl/Ruby/Objective-C/Java/etc (seriously, we use all those languages) to work on existing code bases. We work on Linux, VMS, Windows, iOS, and BlackBerry. We have plenty of "glue" code, frontend code and code that needs to deal with large amounts of data.

We don't expect recent graduates to have much coding experience. You seem to think that we have some strict checklist which is not the case at all. I really don't know where you got this idea. My initial comment was simply meant to answer the OPs question. I don't always ask those questions, I weight many things in my decision (including whether I think I conducted the interview well - sometimes it's clear that I've failed to properly describe the problem) and discuss the candidate with other people who have also interviewed them.