Hacker News Reader

Comment by rickmb | Hacker News Reader

Maybe it's just me, but when I look for great programmers, their ability to solve coding challenges is really the least of my problems.

In my experience, the ability to leverage those skills into delivering mature, stable, maintainable and generally high quality software is considerably rarer than the skill to solve puzzles. And don't even get me started on non-technical skills, like being able to organize and plan the work, communicate with non-technical people etcetera.

Basically, I don't see this kind of testing covering more than 5% of the screening effort.

View on HN

You're not the only one. The more experience I get developing software with other people, the more I value stuff that isn't really captured by coding interviews:

  * do you thoroughly document your code without nagging?
  * do you value simplicity over cleverness?
  * do you think communication is a chore?
  * do you enjoy human interaction?
  * do you have empathy?
  * are you creative?
  * do you have good taste?

Googrosoft-style interviews are great for selecting people with raw intelligence, a competitive streak and some level of arrogance. They're not quite as hot at selecting reasonably smart people who are personable, creative and tasteful. And that's a huge portion of the job when you're writing software in a group. Very little day-to-day software work requires raw brilliance, but nearly all of it requires communication, empathy, creativity and taste.

Well stated man totally well stated.

And how do you test for all of these things that you listed during an interview? I've been in charge of technical interviews for a large corporation for a year and a half, and there have been many truly shitty developers who couldn't solve even simple programming problems, but they knew how to bullshit, and they would totally ace your questions.

"I've been in charge of technical interviews for a large corporation for a year and a half, and there have been many truly shitty developers who couldn't solve even simple programming problems, but they knew how to bullshit, and they would totally ace your questions."

Well, first, it's not like I just ask someone if they enjoy documenting code, and expect them not to lie. That would be stupid. It's much easier to just ask coding questions than to figure out if someone is creative. That's why the problem is hard.

Second, how do you focus on the other important factors, and still manage to test for coding ability? You ask coding questions -- you just don't devote the entire interview process to them.

I totally agree.

Last year I interviewed at two YC companies, AirBnB and Heroku. At AirBnB the interview went great, but then I was given a 3 hour programming challenge that including a written analysis of my code. The challenge was not at all related at all to building web apps, and even the use of a database was not allowed to be used to solve the problem.

At Heroku, we discussed a real issue they were having and halfway through the interview we were both up at the whiteboard bouncing things back and forth, drawing things up. At the end of the Heroku interview we both knew how the other worked and how we would work together.

"At Heroku, we discussed a real issue they were having and halfway through the interview we were both up at the whiteboard bouncing things back and forth, drawing things up. At the end of the Heroku interview we both knew how the other worked and how we would work together."

I find this kind of odd and correct me if you think I'm off because I'm not a programmer.

But for any company to give you a problem that they are having and for you to help them solve it... shouldn't you get compensation for that (outside of a job position)? That's basically free consultation. It's like how some companies give design tests for designers, which is basically spec work. Even if they don't choose you, they could still take some of the ideas and implement it.

It's one thing to give a general problem and analyze your problem solving skills and knowledge (as well as to verify your resume).

There is a difference between talking about how to solve a problem, and actually implementing the solution. Talking with a designer about the problems they would be facing and about how they would approach some of them is very different than having them implement the solution (a complete design). I suspect the same applies to programmers. As long as you're not asking for the implementation (working code), it's probably fine.

"There is a difference between talking about how to solve a problem, and actually implementing the solution."

Is there?

You are giving your expertise with the intention of improving their situation and potentially saving them time. It's not uncommon to get paid to consult about problems that a team is facing without actively implementing it yourself. How is this any different?

There is if you are being hired as a developer. If you are being hired as an internal consultant, that's a different situation.

Thomas, yes, what you mention is a problem. I have had quite a few job interviews that were free consultations. It's real painful when you have to fly out on your own dime for this, something I no longer will do at all. If the company can't afford to cover interview costs, it's not profitable and should be avoided. The experience the other guy described of it working out in the end does happen sometimes but it is a minority of cases. A lot of companies will contact domain experts and consultants and want them to come out for a chat. Sometimes they want to talk on the phone for 6 hrs. It's a huge red flag when they pull out specific problems that they are having trouble with and which are for their company, and start asking for a detailed technical analysis of how to solve it. Especially if they take written notes or video tape the interview. Usually what happens is their guy later implements the solution you give them.

It was actually a problem that they were already in the process of fixing, so they weren't gaining any value from my ideas. It turned out my solution a came up with was the same solution they were implementing. I definitely didn't feel like I was doing free work for them. It was pretty high level.

Relevant, my blog post from a couple of weeks ago.

http://blog.indextank.com/1030/interviewing-engineers-enough...

TLDR: Most companies put too much emphasis on testing IQ and don't know how to evaluate what makes people great at building stuff that the company needs.

Reply on news.ycombinator.com