Live data from Hacker News

Take-home interviews

blog.triplebyte.com

181–190 of 295 posts

Re: Take-home interviews

#181
My old employer Thoughtworks does this.

http://www.thoughtworks.com/careers/application-process

It's a fantastic way to vet candidates and there are multiple exits to the process. For obviously bad submissions, it's probably a no-hire, but I've even seen incomplete assignments get someone to the next level and then a hire.

Some people get sent to ThoughtWorks University which basically trains them to code, work in an agile environment and how to be a good consultant. Everyone that goes says it is a great experience.

Re: Take-home interviews

#182
We (Sauce Labs, Mobile Team) are experimenting with take-home tests as a first-contact screen. I'm familiar with the take home exam that takes a week to solve, so we went in a different direction.

We schedule time with candidates, send it to them at the right moment, and expect them to send in a solution two hours later.

Before we tried it on candidates, we all did our own test, and we confirmed it could be done in less than two hours. (Granted, we are very familiar with the problems we care about, but we usually get complete solutions from candidates.)

So far the results have been fascinating. The test is conceptually super easy, deliberately so, but with a very wide set of possible implementations. It is more about tying together moving parts in the right design. The goal was to do the opposite of the algorithmic brainteasers you normally get in interviews -- it's a miniaturized version of the problems we actually solve all day. Hopefully, it's a good test of what kind of coder the candidate is.

But we're still working on it and refining it.

Re: Take-home interviews

#183

From the employees' perspective: Take home tests are the worst. Company says take home test will take 3 hours to complete. They never do. Schedule 2x or 3x the estimate. Especially if you want to impress the reviewer. You send it over, then the company says no or yes, only to move to new stage. In the worst case you ruined your weekend and received a no. But the company just took 10 minutes to arbitrarily reject your…

After doing a handful of these and rejecting several handful of these tests I'd like to add a little to you comment. I agree that the time it takes is always muchuch longer than what they state. Companies that offer these tests before doing an initial phone screen get that email deleted. Why would I as an applicant who is applying to 10+ jobs spend time doing this test when I have never even had a chance to interact…

One take-home test I declined was for a advertised web job that turned out to require lots of PHP knowledge and plugin editing experience.

They seemed offended when I was frank that it would take much longer than the 1 hour they were quoting and that it wouldn't be a real demonstration of skills but more so what I could cram.

OTOH, my current work does a sort of take-home test but it can't be faked/cheated on because you have to record yourself teaching something.

Re: Take-home interviews

#184

From the employees' perspective: Take home tests are the worst. Company says take home test will take 3 hours to complete. They never do. Schedule 2x or 3x the estimate. Especially if you want to impress the reviewer. You send it over, then the company says no or yes, only to move to new stage. In the worst case you ruined your weekend and received a no. But the company just took 10 minutes to arbitrarily reject your…

Or, if they don't actually expect you to spend more than 3 hours on the task, they will compare you to people who have spent 9 hours on it. Had that recently: they said "spend no more than two hours on it" so I finished in about an hour and 45 that evening and flipped it over. Then they started asking why my 20 or so unit tests only covered the basics when other candidates had full unit tests in the two hour time fra…

If a company emphasizes quantity over quality during the interview process, run away.

Re: Take-home interviews

#185
We consistently do this in Sandglaz whenever we interview for a technical position. It most closely aligns with how work is done in real life, and we give candidates a reasonable amount of time to do the project. We ask them to document what they would do if they had more time. It is more of a way of peering into how they organize code, their understanding of technical debt and prototyping, and their ability to write unit tests.

It's been invaluable in determining candidate fit.

Re: Take-home interviews

#186

Earlier quoted context omitted.

This is very much true. We do take-home interview questions where they bring the output to the interview and we talk through their solution in person. We'll ask how long they took as a way to normalize expectations and also adjust the interview question to take more/less time in future instances. This does two things. In the long run, the time required converges towards where we want it to be (ASSUMING honest answers…

Tip: If you want honest answers about how long it took, ask them after they've been hired and working there for a few weeks. Otherwise they will absolutely lie. "That? Oh, it was no big, probably 20-30 minutes."

I'm not sure if asking after getting hired would make a difference. They may lie even more, you don't want to be seen as a newbie to your coworkers

Re: Take-home interviews

#187

From the employees' perspective: Take home tests are the worst. Company says take home test will take 3 hours to complete. They never do. Schedule 2x or 3x the estimate. Especially if you want to impress the reviewer. You send it over, then the company says no or yes, only to move to new stage. In the worst case you ruined your weekend and received a no. But the company just took 10 minutes to arbitrarily reject your…

The company I work for has a "coding assignment," and it works really well for us. I'm not sure we give a time estimate; I think we just ask for it back in a week or so. The devs reviewing the code don't even know how long it took for the applicant to return, and it isn't a criteria we use to judge them. In any case, I can't imagine it would take anybody more than a few hours.

IMO, it's a less insulting, slightly more realistic version of FizzBuzz.

As far as getting help goes, I'm not sure it matters too much. There's still an on site interview, and we ask a few questions about the assignment, along with some other coding questions, and regular interview stuff. I guess if their friend/roommate/spouse is going to help them code all the time, then it's like we hired two people for the price of one ;-)

Re: Take-home interviews

#188
post #156

I considered a job out in SF working for a decently well-known guy, Andrew Chen. I had gone through 4 coding interviews progressively working my way up their ladder to their CTO. Now, each of these I did well on but they didn't like how fast I went. Despite them saying "Our fastest done was 1hr!", they didn't seem to appreciate me going fast and came to the conclusion that I probably didn't know how to write producti…

That sucks. There was a time when being entrepreneurial was added to job descriptions as a nice to have. I went through something similar a long time ago; the reasoning was just as specious. Good luck.

Thanks -- specious is a nice word. Never heard that one before. Looks like I got even more out of that experience ;)

Re: Take-home interviews

#189
Historically, I've tended to do poorly in in-person interviews. I felt my critical thinking and problem solving skills plummet to a fraction of what I am capable of. I initially thought that with enough real-world interviewing experience, I could familiarize myself to the stress, but that never really happened. Interviews tend to be few and far between, so the familiarity never really sticks.

I usually perform better on take home interviews, but 90% the time I'm unwilling to dedicate what are usually days for just a chance to be accepted at a company I may not even want to join. I think many employers use the take home interview as a screener without realizing they need to first cultivate in the candidate the enthusiasm and willingness to complete it.

Some ways companies can encourage me to actually complete the take home interview:

- Provide compelling information about the job (estimated pay/equity, meeting the team, evaluating culture-fit, getting me excited about the problem, etc). Lots of companies save this step for the courting process that happens after the technical screen.

- Pay me a modest amount just to complete it, regardless if I pass or not. I don't care about the money, but at least it won't feel like wasted time.

- Make it way shorter, but then it might be useless.

--

What I'd prefer instead of all this interviewing is still:

1) meet the team, evaluate culture fit, etc.

2) discuss past projects in detail, maybe do a code evaluation if relevant

3) contract for the company for 2-4 weeks at market rate pay. Hell, make a 10-week "internship" out of it, whatever.

4) receive offer (or not)

This is not always practical or scalable, but I've gotten offers 100% of the time this way, including at YC companies and other startups. And from the company's perspective, I think it extricates any unreasonable expectations they have from prospective employees. It's always tempting to look for unicorns when you have hundreds of resumes to choose from, but when you have a likable contractor doing good work, there's no reason not to give him/her an offer. Plus, the employer can evaluate the single most relevant skill in an employee -- the ability to learn.

Re: Take-home interviews

#190
post #67

Earlier quoted context omitted.

Agreed. My reaction was "finally!". I really do not approach software engineering as Performance Art -- and I never write code on white boards when I work. I've been fortunate to have been asked only once to do such a performance in an interview, and my reaction was unfortunately (and unexpectedly) like the candidate they described. In that case I didn't write anything on the board, but instead explained verbally how…

You've got to be a little careful picking out items from their CV, though, especially if you go back far enough. I barely remember anything I did six months ago, and anything one or two years ago I couldn't explain to you in anything more than a really broad overview, despite being neck deep in the code. I've since moved past that, tackled other projects, stuffed my head full of knowledge of other systems (and hobbie…

If you put it on your resume, its fair game for the interviewer to ask about it.
Post reply on HN