Hacker News Reader

Or is the hiring practice of reducing someone's technical competence to a handful of esoteric questions arbitrary and broken

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

I look for relevant experience, personality, and problem solving skills. I start off with questions that'll get me an insight into the person then I give them a written problem that'll take them 10+ minutes to answer. I want to see them work through it, see what they get stuck on, see when they ask questions and what questions they ask. I ignore syntax errors, and similar minutiae. If you don't have good problem solving skills I don't see how you can be a useful member of my team.

Ya, I've been the victim of "couldn't balance a B-Tree fast enough so you're not hired but you'll never see a B-Tree at work."

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.

Github and many other high profile companies have the benefit of a much larger talent funnel than more average companies. They can literally sit back and wait for the proverbial rock-star ninja to make a passionate appeal to come and work for them. They can filter anyone without a 4.0 from a top school (not that they would, but that's not the point) and still be working with a bigger pool than lesser companies do, pre-filtering. Never mind actually selling yourself so those you might want to hire will actually accept your offer.

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.

True, they have a bigger talent funnel than smaller companies, but don't forget that they also need far more new hires than smaller companies. I wonder which factor dominates.

I didn't say "small", I said "lesser".

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.

What make you think GitHub haven't fired anybody? I don't know that they have, but it seems very unlikely.

In fact, they have fired a few people.

Holman has in the past made the claim that nobody's quit. I wonder if that still holds up?

Ya, I got my info from Holman. My info's old.

A friend of a friend was recently fired from Github. I don't know where you got this information from.

> Or is the hiring practice of reducing someone's technical competence to a handful of esoteric questions arbitrary and broken?

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.

Did interviews for 5+ years at Google... the real problem is that there's no uniformity to the hiring process. I was allowed to just make up my own questions and judge candidates based on those. And I did so. And admittedly, the questions I asked were so difficult that I seriously doubt I myself could've answered them when I first got hired.

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.

Wow, glad I've never been interviewed by you.

> And admittedly, the questions I asked were so difficult that I seriously doubt I myself could've answered them when I first got hired.

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

No, but I would like to hastily assure you that it is solely because I am a coward when it comes to NDA issues.

> And admittedly, the questions I asked were so difficult that I seriously doubt I myself could've answered them when I first got hired

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.

There are some problems with the trial period. It doesn't account for those that don't have specific domain knowledge. From my experience, I have worked with people that have hit the ground running and been really productive straight away, but in the long run have not been as innovative as others.

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.

I think your onto something.

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.

> I love the idea of a paid working trial of some length

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.

I've seen six months work - that's time enough to ramp up somewhat and deliver. In that regard, it's plenty of time to assess the traits that we're looking for in strong developers.

Do you get back to them with the decision well before the end of the period, though, or do you just leave them without an income at the end of it if you decide you don't want to hire them?

That is the usual practice in countries like France, where new hires are on a trial basis for a period of one to six months (all other things being equal, the trial period only means that both the employee and the employer may terminate the contract at the end of the period with minimal administrative fuss).

There's a brilliant algorithm. In the interest of looking good for promotion, waste everybody's time, miss out on the good people that would help the company succeed (and presumably that would grow the stock valuation), and, the good interview candidates miss out on a job that feeds them and helps them grow their career. Just brilliant.

The problem is a bad metric of evaluation (if not doing interviews actually looks bad at promotion time). I'd suggest that the fact that some people can look at themselves in the mirror in the morning with statisfaction while screwing over both their employer and prospective employees is also a problem.

People really need to stop lumping fizzbuzz into their hatred of "trivia" questions. You don't do variations of fizzbuzz. Fizzbuzz is not a challenge, it is not trivia, it is not a trick question or a brain teaser. It is the simplest, most inane function you can ask someone to write. It exists purely to filter out people who simply can not write any code at all. It is a test of "does this person understand the concept of a loop, and the concept of a conditional". That is it.

I agree that Fizzbuzz isn't a trick question or a brain teaser. If I disagree with you about "trivia", I think it's because I disagree what the word "trivia" means, not because I disagree about Fizzbuzz. Whatever.

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.

>However, I do meaningfully disagree about "variations of Fizzbuzz".

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.

First, congratulations. Good luck wherever you choose to go.

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.)

Also, it goes the other way: A senior engineer will be a lot more picky, and take more care to scope out good places with hard problems: The places that have higher bars for hiring.

My uncle is a senior marketing executive and I can confirm that whenever he conducts a job search it is an epic undertaking. So this tends to be true in many industries, not just software engineering.

I saw your hack at AngelHack SF. It was a great product and I was surprise that you did not get the grand prize.

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.

Thanks! I am still working on Coderang (the version I showed yesterday is up at http://coderang.com), and I think I could definitely turn it into a business.

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. :)

Great. contact me at doanhqdo at berkeley.edu if you want some free business advice. I am currently working on a start-up that is being incubated out of the UC Berkeley's Skydeck incubator. I should be able to connect you with some people if you'd like.

I had a similar experience. I was asked to do some coding, got hung up on one of the questions.

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.

Confirmed. I give interviews and people get offers or not based on my feedback. I also don't know what I'm doing. It could be Imposter's Syndrome or maybe that's just what imposters tell themselves.