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