[bluejekyll]

This is not true. You have to do them if you don’t have much experience, i.e. straight out of college. With no experience, these stand in for an understanding of your CS understanding. Organizations that put very experienced candidates through algorithms questions show that they don’t value experience, and I wouldn’t want to work there.

With a large amount of experience, we as interviews, should be asking much more about past projects and issues people have run into. I find it much more valuable to understand what real world problems people have faced, and how they solved them. Sometimes you even get to a point where someone actually has a good story about using the wrong algorithm, and so you still get to talk about algorithms.

This tends to also tell you a lot about the candidate’s abilities to work in the environment you are thinking of placing them into. Algorithms questions should be a fallback only when you can’t discover this while running through questions about their experiences.

[koblas]

Fresh out or not, a good interview process will involve technical problems. Some organizations will bias to "take home" style, others will do a whiteboard session either on a whiteboard or with a computer.

Good questions are going to be more than, build a linked list in JavaScript or a bubble sort. Those are pure algorithmic questions, but you still need to walk the walk not just talk the talk.

[dominotw]

This has been my experience interviewing past couple of months . I have over a decade of fulltime experience. I still had to do tons of these whiteboard/algorithm interviews. And not its not just clueless companies doing them, everyone from google to local software consulting show down the street doing this.

[booleandilemma]

If you have a high paying position that doesn’t require a license or certification to work in then you’re going to attract a lot of frauds, so these kinds of interviews are necessary.

Doctors need a license, and even so, you still hear about people who are found out to be frauds years later.

If software development didn’t have technical interviews the field would be full of people who wouldn’t know anything about programming, but who would call themselves developers anyway.

[watwut]

The trouble with "nice discussion about past projects" interview style is that it is super easy to pretend way more experience and skill then you really have. You are literally measuring how smooth talking that person is and whether has good idea about what opinions are cool now.

That is what fizz buzz or basic algorithms are for. Because really,smooth talking incapable collegus do more harm then normal incapable ones.

[bluejekyll]

I disagree. I suggest you read about the behavioral interview. By using pretty well known techniques you can quickly get people into a situation where they feel comfortable in telling you about what they did or did not do.

For example, I recently had someone run through a distributed system's set of questions related to kafka and some AWS services. It became obvious through this questioning that what he had built was not capable of guaranteed message delivery, i.e. the system was lossy.

The rest of the interview was about this system and how he would rebuild it to make sure there were no messages lost between all the handoffs of the system. We got into many very detailed areas about persistence, atomicity, idempotentcy, etc.

It should not be a shoot the breeze conversation about buzz words, it should be a very detailed process of getting down to the most complicated piece of software someone has worked with. It becomes very clear, very quickly, if they are bullshitting you, and then you don't hire them.

[jakub_g]

Sadly this is very true. I had been working with a colleague who was a perfect talker about best practices and what not, and first to criticize the offshore team for bad coding, yet himself he was as well doing a lot of crazy things and sloppy coding, and breaking the build and shipping regressions on a regular basis.

Unfortunately I don't have a good solution to this problem.

I'm wondering how interviews in other professions look like. For example when you're a director of a hospital and want to hire a surgeon. I guess you don't ask him to come one day to make a little surgery for free.

[watwut]

Surgeons are heavily credentialed. You have to have school and residency and subsewuent tests what not. I don't think same would be appropriate for coders.

[vonmoltke]

Sounds more like poor work ethic and other issues of professionalism, not lack of knowledge.

[LVB]

Fizz buzz etc. might detect complete frauds, and at the other end some heavy algorithm questions might falsely reject good candidates who simply haven't applied that stuff in a long time. I think small at-home coding challenges are a sweet spot. They too reveal total rejects, but allow the rest to demonstrate their broader level of understanding and organization. And they make great follow-up discussion items.