[bpicolo]

Take homes are one of the single biggest turnoffs for experienced talent in interview processes. People don't want to do them. Especially good devs who can land a job anywhere.

> Don't make them jump through hoops

The take homes are the hoops.

[Ensorceled]

For people with side/brochure projects, my "take home" tests are always "add these simple features to your git hub project xxx". Often it gets done the same day.

Otherwise, I'll do something simple, on a shared screen in the language of their choice.

It shouldn't be hours and hours and, ideally, it's a win/win.

[bpicolo]

Not being facetious here - if they have notable github projects, why do you want a new feature versus viewing or talking through something they've already developed in one of them? Why is the novelty important?

The shared coding screen is definitely the most common method. And the one I've found most folk prefer. There won't ever be a one size fits all solution, but ideally your interview methods are equitable across all candidates, and ones that the majority of candidates are comfortable going through. Disparate processes hurts the former.

[Ensorceled]

> if they have notable github projects, why do you want a new feature

It might not actually be their project.

> but ideally your interview methods are equitable across all candidates

My candidates are not competing with each other, the tests do not need to be "equitable" between candidates, just fair for that candidate.

One problem, for instance, with github projects is that it's a fairly privileged position to be able to have significant side projects. So it's not fair to expect a candidate to have a github presence and you would be eliminating people without a lot spare time (single parents is the go to example).

[coupdejarnac]

Is this commonly done? I haven't seen this before. If I had an interviewer do this for me, I would be very impressed.

[gsibble]

That's why I try to make take homes fun. I like the elevator problem in Python. Try to make elevator software that passes the unit tests. Sounds simple, right? Wrong. Very hard.

I don't really care how successful you are. I want to see how readable and maintainable your code is. Sometimes I just ask for example projects that I can read.

But I do need to know you can, you know, actually do the job. I personally find in person coding significantly more stressful than take homes. So what would you suggest? How do I test someone's ability to code?

[harshalizee]

It's not about if the take homes are fun or not. Far too many companies have varied take home tests that can take an hour or a 40-hour work week only to be ghosted after submission. I don't partake in any asymmetric interview processes, and many places are happy to let me skip it. I'm happy to sit on a zoom call with one of your engineers for a couple of hours and do whatever they want me code in that time. I'm just not into doing it on my own time with no cost to the interviewer.

[jenscow]

So if I asked you to do to a 1-2 hour coding task, you'd only do it if I were on a zoom call with you while you did it?

[harshalizee]

Yup! The interviewer can see my thought process. I can also evaluate my peers and ask questions about the work. The interviewer can also see how easy or cumbersome it is to set up the environment and code in the allotted time. Win-win.

[jenscow]

If I was hiring a junior, perhaps that would have some use.

[naniwaduni]

It's not about what's useful to you. Not everything has to be about you. It's acknowledgement that the interviewee's time is worth something (approximately about as much as dev time) and that you're willing to pay for it.

[yupper32]

Yes. Put in the time with me to show you're serious. Otherwise you could mass spam candidates, most of which you don't actually care about.

[gsibble]

That's fine. We're happy to let you do that if that's how you'd prefer to show us you can code.

[ipaddr]

If you need experienced developers to show you they can code you are only going to get amateurs.

[ChrisMarshallNY]

My experience is that, whether it be via interview, take-home, or whiteboard test, what employers are looking for, is $buzzwordDuJour.

I may be being generous. I am noticeably “older,” so it may have simply been bald-faced ageism, in my case. Maybe younger folks would have been given more latitude.

I remember getting a take-home, once, where they asked me to write an iOS app that leveraged a specific library. They did not provide a template. They simply sent me an email with a fairly vague spec (I'm fine with that). They also wanted me to use a specific $methodologyDuJour, that would have resulted in needlessly complex, underperformant, and buggy code.

At the time they gave it to me, I had a pretty serious personal family emergency, so I did the app, using the industry-standard method. I wrote a full-quality, localizable, documented app, in less than four hours. While my house was trying to burn down, so there was a bit of extra stress.

Oh, and also, I had never worked with the library they wanted me to use, so I had to learn the API.

So, I wrote a full native Swift iOS app, from scratch, learned a commercial API, integrated it, tested the app, documented it, and delivered an App Store ship-ready iOS app, with very high-Quality code, in about four hours, while under serious personal stress. I did let them know that I had had to deal with a "personal emergency," so the test was a bit "rushed."

They ghosted me hard after that. I was actually shocked at how discourteous they were, as everything before that, was great.

[ipaddr]

Ghosting after take home tests are extremely common. Usually the longer the test the more likely you are to be ghosted.

[ChrisMarshallNY]

It was also pretty damn stupid. That was one of the motivators for me to stop bothering to look. I didn't need the work, and I was looking for work that interested me (this was a hardware company that made a system that interested me).

They maybe didn't like that I used classic MVC for the app, because it is ... less than optimal ... to use other patterns, when writing a UIKit app. Of course, it's also possible that they finally brought in a tech manager, who figured out I was old, so...

But I regularly write full apps in record time. My GH repos are full of test harnesses that I toss together in no time at all. Pretty much every test harness is one that many folks would be proud to submit to the App Store. I’ve had over 20 published native apps, over the last ten years (mostly deprecated, these days), so I’m used to regularly shipping (and maintaining) native iOS apps.

I'd suggest that someone that can chock together an app like that, in just a few hours, while under a serious amount of external stress, could be someone worth following up on. BTW: The library was MapBox. I'd never worked with it before. I enjoyed the opportunity to learn about it, as I may use it in the future (offline maps, and it's a pretty decent dependency).

But that was about three years ago, and I'm actually really glad that I got chased out of the rat race. It just took me a while to appreciate it.

[JamesBarney]

Maybe a better way to phrase it is, "make the hoops count".