The irony is whenever someone posts some esoteric "gotcha" programming trick here on HN, inevitably there'll be comments like "have to include this in our next interviews."

So what would you do differently? This is a genuine question after I came off 3 months of interviewing daily. I'm curious what does represent a good developer and how to decide this in 30 minutes over the phone? What's important? - Past projects? - Communication? - Open source contributions? - Ability to write code? - Telling me how they'd Google a problem? - How to break down problems? - Some % combination of these?

My interviews are generally structured: 10 min: introduction to the role, expectations, motivations, try to start a conversation, get a feel for the candidate, nerves etc 15 min: technical questions: - fundamentals on the job's tech stack (must provide code) - turning a requirement into a design - troubleshooting issues (db performance, web server issues) 5 min: - wrap up, q&a

You mention that there isn't a better solution. IMHO, I disagree.

I think Github has figured out a way. They've been around 5 years and haven't fired anybody and nobody has quit.

Most firings are due to a job / job skill mismatch. At Github, they do a week long paid interview so both sides really know what they're getting into.

I don't work at Github, but am such a fan of their company.

Lesser companies simply have to take more chances on people if they want to have a shot at growing their teams. They will naturally fail more than companies that don't have to take that shot.

Also, GitHub just have 166 employees (https://github.com/about) - presumably not all engineers. Any ten random selected medium sized software companies easily eclipses their volume.

Certainly the hiring practices of Google et al, generally the worst perpetrators of cs bingo in my experience. Started a startup, you say? Rebuilt a non-trivial webapp? Won a hackathon? That's great, but we're going to need you to implement red-black trees and variations of fizzbuzz until your brain bleeds.

But I didn't give a crap, because hiring is something you're kind of coerced into doing (it's not technically required, but not doing interviews looks bad at promotion time). And I hated doing interviews with a passion, so I'd just give them one impossibly hard question, which is easier than asking a bunch of questions.

Sometimes I have to stop myself doing this before conducting interviews. I think it's an ego thing, or perhaps an insecurity. When I worked at Amazon the culture drove this kind of rubbish and skewed our hiring process immensely.

There was something perverse about being in an interview loop, all 8 of us "not inclined" to hire a single candidate because they missed an recursion terminator in a solution to something properly complex and scratched out on a whiteboard in 15 minutes. All of us nodding like "that's so stupid" and I was sitting there 100% certain of the 8 people in the room the 7 of us who hadn't conducted the same interview 50 times would drop a bollock somewhere along the way. Yet there was no way this "otherwise competent, and quite nice guy" was as technically astute as all of us gathered here today indulging in our nice cup of ego massage while other people got actual work done.

Now when I interview candidates I want to see some code you have written you are proud of. Above all, I'm looking for pragmatism, effective reasoning and discipline in execution.

I love the idea of a paid working trial of some length, followed by a permanent hire but I've yet to convince the powers that be that it's an effective strategy.

I prefer to hire a candidate that might take 2-3 months to get productive but have some really innovative ideas, that others in the company might have missed. Puzzle questions do give me a sense of how someone approaches and solves problems, and I think you can infer how they will handle real problems since the building blocks to problem solving are essentially the same regardless of what domain. Solving puzzle questions is just a component of things I look for:

1. Experience in solving challenging problems 2. Good university results 3. Personality fit, easy to get along with 4. Leadership potential 5. Enthusiastic/passionate

Not all five are needed, but candidates need to be strong in more than 1-2 areas.

If you have issues with interviews specifically, you could enter a TopCoder competition, or Google Code Jam, and use that as evidence that you can solve those types of problems.

As a passive job seeker, I think this is something I've used to filter out companies. Ones that want to hire someone yesterday are more likely to suffer from poor planning and may only care about short term results.

I'd rather have someone who may take 2-3 months to get up to speed, and then spend years with me returning that investment more than a simple mercenary that will be with me a year or two and then move on.

How long of a trial are you thinking of? If it's a significant amount of time, I think this could be hard to do from the perspective of the candidate.

If I'm currently employed, there's probably no way I'm going to quit my job for a month-long paid trial period somewhere else. If it didn't work out, I'd find myself without a job and would be forced to take a hopefully short sabbatical for more interviews (and this wouldn't be possible at all for people who haven't saved up enough money to do so). It just seems too risky.

If it were longer, say six months, I might consider it, but I'd expect a decision to be made well before the end of the sixth month--that way if you didn't want to hire me full-time I'd have time to talk to other companies before losing my income. Even with this concession, I'd have to want to work for your company an abnormal amount to do this, though.

Perhaps a happy medium is a take-home project taking one or two weeks of part-time work, paid for at market wage.

Would you be willing to share any of the questions you asked? Your description here has piqued my curiosity.

However, I do meaningfully disagree about "variations of Fizzbuzz". It does make sense to vary fizzbuzz, if you suspect that your candidate will have literally memorized the solution, character for character. If that's a concern, though, trivial variations are sufficient: replace the 5 with a 7, or change the ELSE case from "print the number" to "print nothing", or something.

I agree that if your "variation" makes it "interesting", you're not doing Fizzbuzz.

Whether or not interesting programming puzzles are a good element of interviewing, well, there continues to be a wide range of opinions on that.

What I was responding to was "variations of fizzbuzz until your brain bleeds". Which I interpret to mean doing a fizzbuzz, then the interviewer changes it a bit, and a bit more, and keeps dragging it out, having misinterpreted its purpose. Certainly the one and only "fizzbuzz" test you give a candidate can vary from individual to individual.

It may be counter-intuitive, but the more qualified you are, the longer you have to look for a job. A fresh-faced junior developer just out of college can be hired pretty quickly, because he/she isn't a big risk: the salary is lower, the responsibility is lower, and it's assumed there will be some adult supervision from an experienced developer. A senior developer is expected to hit the ground running, and a bad fit can create a lot of team friction and technical debt in a short time. (And your own standards are higher, so not every company will do.)

I think that the problems with technical interviews is that they focus more on algorithms than actual code. While this practice is good for recruiting students out of school who should know by heart the most efficient search or sorting algorithms, it puts people who have been in the industry or who often work in freelance jobs at a considerable disadvantage.

Unless you are working at Google or Facebook where efficiency is super important, the interview questions that Silicon Valley companies ask often do a bad job of filtering out the right candidate.

I thought that your hack was very good. I think that you could turn it into a business if you wanted to.

I was told that the only reason I didn't win the grand prize was some of the judges didn't think I could have made the app by myself during the competition/I had cheated.

Honestly, I'm more flattered that they thought I was too good to win than I would have been if I had won. :)

Right on the spot I was told I wasn't a perfect match. Not directly saying it but definitely implying it, they said they needed someone who can actually code.

I guess having deployed multiple projects and code to show for it isn't worth anything if you can't code a variation of fizz buzz.

The hiring practice is a little off. If anyone ever asks me for advice on job hunting, I'll definitely tell them to exhaust all networking outlets e.g. programing meets, hackathons, friends of friends, before applying directly.