So here's where we have to agree to disagree. A pleasant conversation about your previous work is great, really, and as part of a complete package, likely to send you right to the top of my list.

However, in my experience, the tech industry is overflowing with pretenders. If I haven't met you personally, those github records are of limited use as there's no way to prove you actually did the work in question. I apologize for the paranoia upfront, but once a bozo gets into the foodchain, they can do a lot of damage before getting expelled.

And in the end, the kind of technical questions I ask are so basic that unless you haven't programmed in years or you've never read a programming or algorithms book in your life, you'll get them. What's really disappointing is how few do get them lately. But I attribute that more to the current environment of recruiter cold-calling as opposed to a decline in the expertise of programmers.

Much like in dating, most of the "good ones" are taken, and if not, they don't stay on the market very long.

Is your mentality typical of Google hiring practices? As long as we're going by anecdotal evidence here, nothing you've said here rings true. I've found great engineers by chatting with them -- if you can't separate a great, well-accomplished engineer from a faker by talking with him/her at length about their previous work, then IMHO the problem is with you, not them.

You said it best -- the process you describe above is reflective of a paranoid, neurotic obsession to have "the best" engineers, for some definition of best. Whether or not we agree on what constitutes "best" is not important, but if you insist that people who refuse, or fail, your particular method are bozos then you have your head stuck firmly up your ass.

I think the problem is the fact that we have two types of engineers: the academic geeks, and the creative geeks.

I wouldn't give anyone a pass if they show no personality, creativity and out-of-the-box thinking with good product intuition during my interview. Vice versa, I don't think any academic geeks would give me a pass if I couldn't solve their math puzzles with a proof.

I could be just talking out of my ass here, but it is nonetheless how I see this situation. I don't like it, but I don't see any evidence of it changing anytime soon.

In an interview, I have 30-60 minutes to figure out whether I want to hire you or not. My team writes a lot of code.

Therefore, I'm going to ask you what your favorite language is and then test your ability to write 10-20 lines of code in that language to solve a relatively simple problem.

If you can't do that, it seems to me that a) you don't like to write code and therefore I shouldn't hire you or b) you're out of practice and shouldn't have claimed expertise or c) you're a poser.

If your expertise is with something else, go apply for positions that require skill with said "something else" as we'll both be a lot happier that way.

It's a completely different situation if I know you personally but 95% of the time I don't and I have to make a quick decision.

Keep in mind that if we only have 30-60 minutes together, I'm going to be putting forth a lot of energy in determining if you are even worth working for or are just another bozo boss/company. It is just as risky on my part as it is yours. That doesn't leave a lot of time to think about any challenges you send my way, no matter how easy they may be.

It feels to me like such a process tries to shift the power towards the employer, to make it seem like you would be lucky to even have a chance to work there and focus the time wholly on the business needs, when it really should be a mutual discussion to see if both parties feel it is a good fit. Passing your test with flying colours only to find we are a terrible match is just as damaging as hiring a bozo to begin with, no?

Both are important; match is obvious, but what about the prospect of working at a place with a fair amount of deadwood? Even if they're on the way out, that's going to be ugly.

Failure to do the most basic of technical screening will result in the latter; as I've said in more detail before, in the '90s it was reverse a linked list in C/C++, look at this dozen or so lines of code and find some of the errors in them, and do some design (quiet, no one in the same room time allowed for that, with a discussion to follow). I didn't think it was too much to ask back then, but it sure weeded out a lot of people who couldn't program their way out of a paper bag.

I'm curious to know if you would reciprocate in kind? That is to send me code samples of the work your dev team has done on your company. Your goal is to ensure I'm not a bozo and my goal is to not have to work with bozo colleagues. Hence the exchange of code samples. Fair?

Heh, I'd go father than that, I'd set them in front of a console and let them look through the code base. Of course, this test works both ways ^_^.

Never had anyone ask for that, though. They would have gotten major bonus points for asking....

Before you spend those 30-60 minutes, I want to know if you're worth working for. If you go straight into coding tests, I a) know you're not, b) expect you to be a formalistic stickler, c) I know you haven't done enough homework to at least have a reason to believe I am good enough to have plenty of options.

If you have done your homework when interviewing me, you'll understand that you need to sell me on your company, your team and the position first to let me assess whether you're worth my time.

The candidates who will bend over backwards to satisfy your coding tests before you've spent at least 20 minutes explaining why they should care, are the candidates who are fanboys and/or don't have other decent options. You should ask yourself why.

I've called off interviews and called the recruiter back to tell them I don't want to deal with that company again over interviewers who conducted bad technical interviews, for the reason that I know my value and I know the value of my time.

Conversely, when on the hiring end, I don't want candidates that are happy to bend over backwards for me without any sales effort first, or who don't ask me pointed questions about the company, the job, the terms. It makes me immediately suspicious about why they are willing to make such a big decision without sufficient information to evaluate if it would be a good fit for them.

I don't quite support your position and am more in line with the parent one. It may be possible to find the "truly great" by a nice discussion but for those that are good and above it isn't so easy to separate them from the good talkers without some deeper technical discussion that gets started by an innocent technical question. The question is used to weed out the complete bozos and the deeper discussion to understand the depth of the person interviewing.

I truly don't understand someone who claims to be a great talent and not willing to put up with an hour or two if interview on technical topics. He might or might not be a bozo but by such a stance he failed my personal fit test.

If the question were simply, am I going to go to company X or not, then sure let's do the bozo test to your satisfation.

However, most candidates are going to have several options, and perhaps 7 or more opportunities that they want to chase down. In light of that, and considering that companies like Google want the person with 7+ opportunities chasing him/her, why grind them down by putting them through such an impersonal process? IMO it shows a complete lack of respect or understanding of the position the candidate is in.

If you are the only one who says "great talent should be willing to jump through my hoops" then it's not a problem. The problem is when everyone wants you to jump through their pop quiz, which is what happens when smaller companies see the leaders of their industries institute these bullshit procedures.

To your point about "7+ opportunities":

Last time I spoke to Google, I had two offers on the table from companies who contacted me after Google, before Google even managed to put me through a tech interview. They then proceeded to mess up the tech interview so badly that the recruiter got the result thrown out and got approval to bypass the whole thing. In the meantime said two companies invited me for dinner and lunch and an informal gathering to meet the teams I would manage if I said yes. In the end I ended up staying where I was, but Google was by far the easiest company to turn down: I didn't proceed through the second interview, because I didn't see the point when comparing the treatment I got.

This is what their rigid bureaucratic process results in. Perhaps Google would not have wanted me at the end of it, if I continued the process. But if so, then presumably any candidate they would want for that position would find it even easier than I did to line up other offers in the same time frame.

I don't espouse the Google interview process, just some technical questions. I've done at one point the Google interview process and actually wouldn't suggest to follow it.

to be honest, many positions are filled through referral.

If your concern is to ensure that you're not getting a coding bozo, I think that your tests are designed incorrectly.

Instead of having a 'simple test', just find some random, buggy sub-optimal code sample online (shouldn't be hard) and ask them to identify the problems with it and refactor.

I can almost guarantee you that bozos won't see half the problems, and they definitely won't know how to fix them.

Asking someone to code up simple examples on a board ends up just testing a dude's ability to code up simple coding questions. Bug finding/fixing, creating readable and elegant code and the ability to refactor are all much more relevant and important than asking if someone can implement a sorting algorithm or parse a custom data structure.

In the end, I think that by testing candidates this way it'll make it more likely that the people you hire actually have skills that are important to their daily work.