It’s certainly possible but it’s obviously much harder to do. Let’s say I own a professional basketball team and need to make a hiring decision on a player who walks in the door. Am I going to be able to, with just an interview, determine whether they are a currently good player, or a formerly great player who has only been coaching in recent years and has forgotten how to play? Rather than trying to determine this just by asking questions, why not take the much easier approach of putting them on the court for 2 minutes to see how they play?
This is unrealistic because coding in an interview is not similar to coding in reality, at least for me. When I develop software I silently get to think about reason about problems, try things and read things on Google. In an interview I am with a person I don't know staring at my hands and expected to talk and impress them, all while a timer is ticking.
Strongly agree, I know there is some literature on that, but just wanted to add that for me the process of solving problems is very asynchronous and usually the a-ha comes out in the most unexpected times.
“Let’s say I own a professional basketball team and need to make a hiring decision on a player who walks in the door. Am I going to be able to, with just an interview, determine whether they are a currently good player, or a formerly great player who has only been coaching in recent years and has forgotten how to play?”
No, that would be phenomenally stupid. You would do what teams actually do, and look at their recent playing history.
Note that this is also entirely possible for engineers.
> Note that this is also entirely possible for engineers.
How exactly? Most people cannot take their code with them and show off. It belongs to previous employers, and please do not begin with the "show me your GitHub" - it's unrealistic to expect people to devote their life 100% to coding. Just as I wouldn't expect a carpenter to build houses for fun in his spare time, I do not expect programmers to spend their spare time in front of computers. In fact I believe that socially it's a benefit if they have other hobbies.
This is the problem with programmers: everyone gets obsessive about finding perfect unicorn universal solutions, and gives up on obvious stuff that works 95% of the time. Get out of your own way!
First, most programmers have at least some code they can show you. Stop fretting about the 5% who don’t. If you give up here simply because you have a theory about programmers “devoting their life to coding”, you lose.
Second, you call their references. Yes, really. I know it’s not “objective”. Do it anyway. You will learn a lot. Really.
Third, look around for other people they’ve worked with, who weren’t listed as references. Call some of them. See if you get different opinions.
If your candidate truly, honestly has no code available, no enthusiastic references, and you can’t find anyone who worked with them who will vouch for their skill, then do you really want to hire them?
Finally, yes: do a trivial fizzbuzz coding test to filter out the total fakes.
Listening to coders complain, you’d think that nobody else in the world hired anyone, ever. Let go of your need to make hiring a failure-proof system, and you’ll discover a bigger world.
The majority of my successful senior programmers do not have any private code to show off. Reasoning and ability to think abstract is important and impossible to judge from code they have written. I need programmers that can do those thing in a reasonable time frame and in a group.
Most junior programmers have code to show, and most of the time I don't use it for anything. I'd rather do some FizzBuzz level whiteboard that we spend some time discussing and extend on. It gives a far better picture of their future as a developer. I know this excludes some, but that's the trade off I'm making.
I call references every time, but calling around willy nilly is not a good idea. Apart from the fact that it's not legal, most of the time I get "Yes I've worked with X as a developer for Y years" and nothing more.
”The majority of my successful senior programmers do not have any private code to show off.”
You’re exaggerating or you are an extreme exception.
Given the number of qualifiers (“successful senior programmers”, “private code”) I strongly suspect you’re just trying to find a reason to justify your opinion.
What I see in your comment is someone who has decided the answer, and refuses to consider alternatives.
More than half have no code "they own" or OSS contributions they would show off to an interview (the last part is important). That's neither an exaggeration nor trying to find a justification.
They are fathers, amateur musicians, or like to restore old cars. Just to mention a few things. Could they spend 5-10 hours weekly writing code and hacking things together? Yes, but that would be a significant chunk of their spare time, so understandably they do not.
> If your candidate truly, honestly has no code available, no enthusiastic references, and you can’t find anyone who worked with them who will vouch for their skill, then do you really want to hire them?
Graduates?
> no enthusiastic references, and you can’t find anyone who worked with them who will vouch for their skill
This will make your diversity even worse unless you're extremely careful with it.
Usually the only people who see engineers playing are their own team members, while basketball players play in public, in front of crowds, recorded simultaneously from many angles by video cameras.
Most junior level developers these days have open source code to look at it (as schools really push that). For higher-level developers you can ask more complicated and telling questions.
That's good and valuable, and it's laudable in its own right in a way that basketball isn't (since open source is a contribution to the intellectual commons) but it's not the same thing as working with someone. A lot of people only publish the projects where they were happy with the results, and often it's hard to tell how long someone took or what kind of help they had when they were writing something.
Unlike basketball, coding is not reproducible and has no clear rules nor set of tools even. Thus your analogy is flawed from the outset.
Additionally, a person who can adapt but has lower specific testing skill might actually be better at everything. As in your coach example, a slightly rusty to player from years past might be better than slightly better new guy with no track record. You're taking a gamble either way.
The lowest rung coding test is only good to filter out people who cannot code at all, and that if simple enough. They tend to be stupidly worded though instead.
Trying for anything tough tests for specific tricks, tooling and skills. Giving a longer time task is comprehensive but rules against people who are actually busy, presumably working, thus already kind of tested.
> why not take the much easier approach of putting them on the court for 2 minutes to see how they play?
If every basketball team did that, every player would practice for that 2 minutes of play and you'd have no idea if they would handle an entire game.
The effect is the same for developers: interviewing developers practice for coding tests; memorize common interviewing patterns, quick solutions, and junior level algorithm stuff from their university days.
If you were interviewing a player, you'd probably look to their past experience and teams they played on, their positions on the court, and you'd check with their teammates.
