Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Take-home interviews

blog.triplebyte.com

Post reply on HN
Print view View original

191–200 of 295 posts

Re: Take-home interviews

#191

Post by Schwolop »

burger_moon wrote: post #127
robspychala wrote: post #106

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…

The best take-home interview I ever did had a time-limit. And of course, I panicked when getting close to that limit, and tried my best to tidy up my solution but didn't really manage. Then a pop-up appeared asking "Would you like another 5 minutes?" That was just enough time to calm down, tidy up sufficiently, and submit clean code.

It seemed like a good middle ground to me.

Re: Take-home interviews

#192

Post by nilkn »

philbarr wrote: post #179
nsfyn55 wrote: post #167

Earlier quoted context omitted.

yuck! why did you have 66 commits?

What's wrong with having 66 commits?

This is a completely generic response which is not at all tailored to the above poster's specific situation (since I'm not familiar with the details), but the general idea would be something like this:

If you asked someone to do FizzBuzz at home and they sent you a git repo with 60+ commits, you wouldn't be a little puzzled about that? That would seem to suggest they really struggled with it.

Re: Take-home interviews

#193

Post by giaour »

jasonlotito wrote: post #59
giaour wrote: post #54

Earlier quoted context omitted.

You can snap a picture of a filled board with your cell phone.

And you put the picture in version control?

There should be a time stamp in the exif data, so you could track progression from one photo to the next as a very primitive form of version control.

My original comment was mostly meant as snark, but I've had an interviewer take photos during a whiteboard exercise for this reason.

Re: Take-home interviews

#194

Post by 49531 »

robspychala wrote: post #106

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…

My co-worker once found that someone had posted the take home problem on one of those freelance job sites. Needless to say we didn't move forward with the candidate.

Re: Take-home interviews

#195

Post by robinson7d »

codeshaman wrote: post #177
robinson7d wrote: post #162

Earlier quoted context omitted.

As others have mentioned, the trade-offs can be pretty complicated. Perhaps the take-home is always better for you, I won't try to argue against your personal preferences, I'm simply going to list a few reasons why it turns out worse for a lot of people. For one thing, as expected, the take-home questions are typically far larger than in-person interview questions. When you go into the office you're generally asked,…

There's a lot of truth in what you write and I definetely see the problem. One solution is to have the take home interview as the final step in the process - after having screened the candidate and discussed general technology/framework/concepts without coding. When I did interviews, I found that just by discussing things like thread synchronization and let them explain the projects that they've worked on would weed…

I agree with all of those sentiments.

At the same time, I prefer the idea of presenting previous open source work instead of having a group of potential employers agree on a project that they can all judge. One benefit is that the work is less arbitrary, potentially useful for others. Another is it's more likely to be unique than an assignment is. Finally, do I want to work for any of those other employers?

Applying to a group that way would seem odd to me; part of me thinks that choosing companies is important, but another thinks that there's some chance that that's just because I haven't tried it.

Which, of course, leads me to agree that the OP is great as an experiment - it might well be a better solution in many cases. The fact that, in the OP, it's opt-in is a big deal as well. Though I'm still very skeptical of take-home interviews in general.

Re: Take-home interviews

#196

Post by blazespin »

robspychala wrote: post #106

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…

I agree, the solution is terrible, but the problem is real. Whiteboarding is an awful way to measure someone's skills.

Re: Take-home interviews

#197

Post by ytdht »

robspychala wrote: post #106

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…

as long as they don't assign you actual work that is useful to them....

Re: Take-home interviews

#198

Post by thoman23 »

One thing I always found interesting in these discussions is how the same people who are quick to cite The Mythical Man-Month when it comes to the futility of adding new people to a late project will also claim that working 1-3 hours on some trivial problem is "doing free work" for a company. How much value do you think your 3 hours of work with absolutely no context can possibly add to the company? A company trying to get meaningful work done by secretly farming it out to interviewees is beyond ludicrous. Interviewers are only interested in finding good hires, not in conning you into doing their homework for them.

Re: Take-home interviews

#199

Post by humbertomn »

In 2008, I was hired to work on a tech startup from Australia, while I was living in Brazil. After I went through an initial quiz and a few interviews, they were willing to give me a shot by giving me (and paying for) a small project to code. Only after succeeding at it, they hired me, sponsored my visa and paid for all the relocation costs. In your case, I really think this approach would be a good bet in cases that the YC company is willing to sponsor the visa from the potential employee, so giving him a paid project before even flying him, might be a good filter.

Re: Take-home interviews

#200

Post by pd1 »

nilkn wrote: post #192
philbarr wrote: post #179

Earlier quoted context omitted.

What's wrong with having 66 commits?

This is a completely generic response which is not at all tailored to the above poster's specific situation (since I'm not familiar with the details), but the general idea would be something like this: If you asked someone to do FizzBuzz at home and they sent you a git repo with 60+ commits, you wouldn't be a little puzzled about that? That would seem to suggest they really struggled with it.

That's not really a fair comparison though. It would be more like a typical "whiteboard coding" problem needing a couple commits.
Post reply on HN