We ask candidates to pick a work sample of something they already have, if they have one they can provide. If they don't we give them a relatively painless coding test instead.

It's not perfect, it'd be great if everyone could have a work sample but as you say that's just not the world we live in.

I appreciate this approach. I'd love to be more active with outside-of-work projects, but my days are usually already full. And I can't provide a lot of code samples because the majority of my work is IP.

This is true for most good people at big companies. Your day is already 60 hours long, and your company forbids (via IP ownership) coding outside of work. I fear that most of the interview approaches pointed out in this thread select against people who are already successful at well-regarded companies. Don't you want people like this in your interview funnel?

You'd be surprised. There are an increasing number of folks who get to at least occasionally work on open source projects as part of their day job, and many other less obvious ways of getting a prior sample. But if they don't have one we don't hold it against them for the reasons you cite

Exactly. Furthermore my experience has been that requiring prior work samples unfairly biases towards younger developers. Our system is far from perfect but it allows us to see prior work where possible by provide a fallback when it isn't

I was one of this vast majority once, so I know how it feels. Eventually though however slowly, but I've gathered enough code samples on my github account, samples that are actually rather unique and at the same time useful and getting starred. It takes time, polishing, sure, but as a result quite a few companies stopped asking me doing coding tasks, so I'd say in the end it's worth it.

I built something specifically for that purpose, but people still seem to want me to do pointless coding tests.

Exactly. My after-work profile consists mainly of my non-driving kids getting to their non-school activities on time, the custom-built furniture in my living room, the lawn calibrated to give the HOA conniptions without actually breaking any covenants, the brake fluid level in my 2001 car that is definitely leaking it very slowly, my almost-completed low fantasy novel that I started for NaNoWriMo in 2012, DIY pajamas that my kids wear, a well-socialized terrapin, and yes, even all my online gamer achievements.

The reasons I don't like long coding assessment projects and the reasons I don't already have an example code profile are the same. Reinventing all the same wheels in different programming languages just isn't as fun for me as it once was, and I don't have as much time to dick around with any specific side project, especially ones that don't have any immediate utility to me or my family.

Does anyone ever ask about how I spec'd, designed, built, installed, and maintained my DIY entertainment center? No. Same methodology as building software, you know, except the problems are solved with different tools from a different toolbox.

If you're truly really looking for someone "T-shaped", you have to realize that the tittle on that T might include things entirely outside the realm of software or computer hardware, like how to hang a bear bag when camping, or how to fly a small single-engine aircraft, or how to train cats to use regular toilets, or how to run for political office, or what to do when you get a flat tire, or how to hold someone else's baby, or how to hit a gong target from 300m, or how to make a longbow for under $10 at Home Depot, or how to report a pothole so the city will fix it, or how to repair a pothole when the city won't do it, or how to play "Flight of the Bumblebee" while slowly rotating your B-flat concert tuba through 360 degrees.

All those miscellaneous, general-purpose skills do, in fact, make someone more effective at quite a lot of software-related tasks, sometimes in unexpected ways. But they are never going to appear on a resume, or crop up in the answers to any of the stock interview questions. When you include a criterion that specifically selects for people whose after-work hobbies also involve software, you are implicitly selecting against those who do other things, because there is much, much more to life than writing code.

There was only a very narrow slice of time when I actually wrote code for fun in my free time, from the ages of 15-25. It basically stopped after I got laid off from my first software job, and interviewing for software jobs became my next full time job. That's when I realized that I needed to do other things in my life, because it didn't matter how much I loved software if it didn't love me back.

So if you think need a portfolio to get a job, you might want to build one up that includes more than just code samples. The software industry does not love you back. It will move on to someone younger when it gets bored of you.

Seriously considering putting a write up of how I repiped the natural gas lines in our house. One inch pipe to the utility room, valves on all tees and a stub for the meter so I could pressure test the whole house by zones at the first tee after the meter.

Systems, problem solving, engineering. Happens everywhere not just on a computer screen.

So what did the code inspector have to say about your DIY work?

Leaky brake hydraulics aren't anything to mess with, you should fix it or have it fixed soon. It could be something (relatively) harmless like a common hydraulic system shared between the clutch and the brakes (VW uses this design, perhaps others) in which case a failing master/slave cylinder in the clutch could cause the level to drop without compromising the brake system, but even then, soon you will be clutchless. But barring that unusual circumstance, the brake system is compromised and that's dangerous.

Otherwise I agree with what you said, and the best way to tease those details out of a candidate is to have an informal, personal discussion like getting lunch or getting beers together. But that's not enterprise scale.

Funny you say that, I once worked for someone who interviewed potential product managers by asking how they would spec, design, and build their own entertainment center. Seemed to work pretty well.