I can often type the answer to a tee-ball question in under two minutes; I really don't understand people who are angry about being asked to demonstrate the skills they are selling. We spend more time in interviews introducing ourselves.

Look at it from the point of view of somebody who's been able to somehow acquire a master's degree in computer science without knowing how to write a simple Boolean expression that correctly implements a well-defined predicate. When you bomb a tee-ball question that exposes you, how are you likely to react? (a) Wow, I don't know how to program, or (b) THIS PROCESS IS UNFAIR.

What's an example of a tee-ball question?

Given 3 numbers (a, b, c), determine whether c is in the range that spans from a to b.

In these threads I always end up linking this article:

http://blog.interviewing.io/you-cant-fix-diversity-in-tech-w...

The salient point is about halfway through when they put up the big chart of a couple thousand interviews and the stddev vs. mean of technical score, and say:

As you can see, roughly 25% of interviewees are consistent in their performance, but the rest are all over the place. And over a third of people with a high mean (>=3) technical performance bombed at least one interview.

Now, what this points to is a very clear failure of these standardized interviews with their allegedly "tee-ball" questions, because the results shown would be astoundingly unlikely in a world in which the interview process had any kind of consistency in identifying technical skill.

So, no. You're not doing what you think you're doing, and if you've got a high failure rate the problem is almost assuredly not with the candidates. It's with your interview process, or with you.

False negatives are not good, but false positives are really bad. The process is designed to avoid false positives.

I don't necessarily accept either of those statements. But since most companies just copy Google's interview process, it's worth pointing out that Google can afford to reject, say, 100 qualified people in order to avoid accidentally hiring one unqualified person. The average non-Google tech company cannot afford that.

You're exaggerating my point to make it look ridiculous.

Well, the whole industry operates on a model of avoiding false positive at literally any cost. So I don't think it's an exaggeration, though I certainly agree it's ridiculous.

Is it possible this is more a human failing? Inconsistency of performance might just be nerves.

Out of curiosity. Would you still ask these questions if the candidate has a github/gotlab/whatever profile with X repositories where they are the main / only contributor? Could you explain why yes / no and what the specifics would be? (Volume? Complexity? Commit history? )

I absolutely do. I can't assume that the person before me is the person who actually wrote the code on github.

I think you'd get more value out of talking with them about those repos, and the process of building them, design choices, then any silly question like "how would you design a database". Of course, that would also mean you'd have to actually put more then a few minutes into prep for the candidate's interview...

I've had many, many interviews where I actually had to ask the interviewer "Did you take a look at my GitHub repositories and contributions?" only to be answered with "No, I didn't have enough time, etc. etc." It's shocking to me. Can we please cut through the songs-and-dances and talk about actual, real-world code?

To be fair the days when Github was a strong signal are long over. When interviewing it is rarely worth the interviewers time to look and figure out if it is original code or just forks. Whether the CV is well formatted and free of spelling mistakes is actually a much stronger signal than whether it has a Github link on or not.

Agreed. Every single time I've ever looked at a github profile for a candidate they've had 1 or 2 original repositories that are as bare bones as possible and 18 forked repositories so it "looks" to the untrained eye (i'm guessing recruiters) that they have an active profile.

And then you have others with 90+ repos, and 75%+ of them are original code, and have thousands and thousands of lines of code. Maybe all your candidates have been weak/just out of school.

Also, forked repos are fairly obvious, and there's a dropdown to just show source repos, and if they are manually forking to prevent it from showing as a fork on there, that's a pretty shady indicator that you may want to follow up on...

Those candidates are 1 in 100, seriously. If you have a stack of CVs to filter, it literally is not worth looking at everybody's Github to check. Just filter by formatting and spelling and you're probably good.

And that's why I think resume based hiring is shit, cause my resume isn't great, but my github and skills are stellar. But people like you would chuck my resume in the trash without thinking twice cause I'm not currently working as a programmer.

If that's true, the target of your blame should be the weak candidates who flooded Github with junk repos. And/or whichever journo or blogger started telling those people that "having a Github" was a shortcut through the hiring process.

While I agree with you for the most part, many companies want a "standardized" interview process, for both diversity and CYA reasons. Tailoring the interview to the candidate is actually illegal in certain organizations (like government), as it has large potential for abuse.

That's kind of bullshit though. There's no way for it to be truly objective or standard. You already know what university I went to and made assumptions based on that, you know where I worked before and what my hobbies are.

An interview is not like the SAT. And even the SAT is not an unbiased test.

Objectivity is not a binary, and just because we can't be 'truly' 100% objective doesn't mean we shouldn't try to be more so. If you ask everyone different questions, you don't have a baseline of responses, so you can basically fail or pass whomever you want without anyone being the wiser.

It may surprise you to know that I prepare extensively for interviews that I conduct, and that my questions do not include time-wasters like "how would you design a database". My questions are carefully tailored so that candidates who can program computers can sail right through and get to talk about interesting things.

I wish more interviewers would look at helpfully included links to public code... Didn't happen (or at least wasn't brought up) last time I applied at places. On the other side as an interviewer, I'm lucky that I haven't yet done a phone screen with an outright failure of my tee-ball question (returning true if input positive int is even), though when I see if they can do it in different ways there have been flounders, but I still ask it independent of public code since I hear so many stories like parent's of utter failure. Depending on the contents of the public code (not so much its size) I may then drop some followup sections (I do a slight variant of https://sites.google.com/site/steveyegge2/five-essential-pho... to mainly test presence of areas of knowledge, details can be googled) and make things more informal with some time to make sure they actually wrote their public code.