It’s pretty hard to have a reliable interview process if you don’t ask all of the candidates to do the same thing. Comparing how a candidate performed compared to other candidates on the same set of tasks is an important part of the evaluation.

Consistent processes are also important for avoiding bias. For example, take-home projects are more likely to make sense for young candidates who aren’t raising families and have free time after work. If you have most of your young candidates doing take-home projects and the older candidates doing whiteboarding, you will end up evaluating candidates differently based on age.

Candidates have different strengths and weaknesses. Sure, I'll ask the base questions but in terms of assessing their coding ability I'll go with whatever they feel the most comfortable with.

If they have github, I'll ask them to walk me through a few files, asking their reasons for doing X, why not Y - what does this do?

If they prefer take-home, I'll give them something to create/improve.

Want to do something now? knock yourself out - with or without me watching.

I don't need to sort the candidate into an ordered list, just filter out the "over confident".

The questions I want answering is: Can they actually code? Does their skill match their experience? Is their skill level similar to the codebase?

The only time I've ever told a recruiter off was when I was asked to "spend about a half an hour to write a solution for [problem]" for Microsoft and it turned out to take about that long for me to set Visual Studio up on my laptop at home, and then an equal amount of time to figure out how to navigate the project files, etc. etc. and I could see that the interviewer A) had not given this any thought and B) had no idea how long this would actually take for someone who doesn't develop software at home.

> for someone who doesn't develop software at home.

Are you saying in general - or just for Windows-based software (since you mentioned needing to set up Visual Studio)?

The latter I can understand; but the former makes me want to ask, "Who applies for an SWE position who doesn't write code at home?"

I've been an SWE professionally since 1991 when I was 18; I got my first computer in 1984, and have been "coding at home" ever since. I'm not saying "to be an SWE you need a similar experience" (I know that's untrue) - I'm just relating that I've been coding for a long time, and "at home" is very much a part of it.

Then again, I've heard of people who absolutely hated coding, but were extremely good at it (and I assume made good money doing it), but when they went home, they didn't even want to think about such a thing. Maybe you are similar in that regard?

I guess I am just curious and a bit fascinated by your comment...

I'm someone who does it for 8-10 hours a day at their day job. My fiance works in a retail store. She doesn't come home and immediately start doing retail sales out of her house. Another friend is a teacher and she doesn't run a school out of her house.

Professional baseball players rest after games. They don't finish up and then immediately start practicing again. And soldiers and police get down-time.

Just because I'm doing something I enjoy and that I want to do, doesn't mean I should do it all of my waking hours. I'm not doing this to code, I'm doing this because my employer is paying me to build cool shit and I like doing that. I don't lift weights 24/7, I don't run 24/7, I don't hike 24/7, and I don't program 24/7.

Frankly your attitude is one of the reasons why we don't have any diversity in this profession at most self-described tech companies, and it also underlies a lot of the seeming ageism today. All of these self-described non-conformists expect everyone in the profession to conform to their attitude and it's sickening.

I wonder how many surgeons do operations at home.

That was assuming you even had a Windows laptop to set VS on. I know a lot of people have to say no these days since they just have a MBP running OS X.

> I know a lot of people have to say no these days since they just have a MBP running OS X.

That's where the person who knows how to set up a VirtualBox VM running Windows and VS would have a large advantage; when they brought in the result, showing their MBP running VS in a virtualized manner, and explained what they had to do - that's a bit more of an impression than someone who says "they can't do it because MBP".

You can actually run Windows just fine on a mac using bootcamp. The big problem is just getting a legit Windows license, and then the hurdle is just a few hundred bucks (or whatever a non-OEM non-upgrade license costs these days).

Also, I'm nowhere near ops jobs, so I don't think those people interviewing me would care much about those kind of logistics (anyways, they wouldn't want to know the details). It wouldn't score any "points" beyond just getting the task done at all.