[gsibble]

If the person requests it, we pay for interview time as long as the hourly is reasonable. Not a problem.

The real question I have for you is, how would you prefer to prove to me you can actually do the job? In person coding exercise? Isn't that more stressful?

[andrewingram]

How long do your take home exercises take?

I've always conducted interviews where I've given system design questions, and data modelling questions. Never found that coding exercises give good enough signal to justify the time investment on either side. If you want to catch someone in lie, i.e. they can't code at all, just give them something of fizzbuzz-level difficulty as a basic filter.

[gsibble]

Depends upon how much proof I think I need to see. Both min/max are an hour but you can spend as long as you'd like on some. We take fun problems (github challenge projects I've spent days on just for fun) and give them as tests. We ask you just to spend as much time as you want to give us a sense that you can actually code and give us a sense of your coding style. We're mostly looking that you can 1) actually solve problems 2) write legible code 3) write maintainable code.

We don't give out dumb, tedious quizzes or anything. These are actual projects written to be fun. We don't get many/any complaints.

We also give out the coding test very late in the interview cycle. I'd say we hire 80% of the people we give tests to. We already have a pretty good idea you'll be a good fit by that point. So we're not wasting your time.

[intelVISA]

No issue with take home approach, I think it's incredibly valuable if done in a manner that respects everybody's time.

Personally I'd probably do some sort of FizzBuzz/LC easy type low filter and then a fast (i.e. no compiled langs) take home in an area adjacent to the job description paid at said job's rate with a time expectation so you don't end up getting billed 20hrs for a Node RESTful API.

[gsibble]

We very infrequently get asked to reimburse for time but we do limit how much when we do.

We usually give various challenges as take homes which people find fun and engaging, projects that I myself have spent hours or even days trying to solve in my spare time. We want them to be fun. We rarely get complaints.

We're happy to accomodate if you'd rather do it in person or over zoom. It's really up to the applicant.

[intelVISA]

I can appreciate that and obviously what you're doing is working out for you :)

Guess I'm prob the odd one out here -- unless the job was incredible (like pair programming with J Carmack) I wouldn't be able to commit to any meaningful unpaid take home as I can spend that time programming for profit rather than solving challenges for a company that may or may not work out.

[gsibble]

That's fine and up to you. Our interview process is extremely streamlined and requires 1/2 - 1/5 the time of most engineering interview processes. We do require someone to show they are capable of doing the work. How would you prefer to do that so I can take your feedback into account?

[intelVISA]

That really is the $1m question huh, wish I knew tbh. Even ignoring the unpaid work aspect the other Catch-22 is sure, you might filter a few "only good on paper" candidates but if you're hiring "top talent" what is a 5min Flask API going to prove?

For a coding eval like that to be useful beyond jr level it'd need to be decently complex which usually takes a while to develop. Maybe an open ended (upfront no expectation of completion) kinda "see how far you can get in 1hr on this complex thing" could be a fair middle ground as laying some good groundwork is a pretty solid insight into their coding process.

[gsibble]

Indeed. That's why our most common coding challenge is this: https://github.com/mshang/python-elevator-challenge

We ask you to see how far you can get in an hour and then review your code. We're looking for how you approach the problem and if you can write readable, maintainable code. You can learn a lot from how someone approaches this. We've seen dozens of different approaches, and in fact learned a lot ourselves from the different answers. Some are incredibly impressive. Some are just a bunch of if statements that lead nowhere. It's a great way of separating wheat from chaff quickly.

edit: The flask API was an interview I took, not one I gave. I considered it a very poor take home since it was ridiculously simple and didn't prove any actual skill, but as I said, less than 40% of their applicants were able to pass even such a simple question. They had very poor screening processes. It was also step 2 in their interview process right after a screening call and they spammed it to hundreds of people while our coding exercise is our final step after we've screened you past several people and had several hours to get to know you and are already pretty sure you're a good fit.