>> enforces time limits on challenges

But there is a problem. In the past when I have worked on take home challenges which usually take 3 hours or thereabouts, I have done them in 3 sessions of 1 hour each in the evening after work:

1 hour: think about the problem in detail making some notes for scenarios, edge cases, high level API design etc 2nd hour: first rough cut working draft with some test coverage 3rd hour: polish it up with more tests, docs, a README and sending it out.

I think `takehome.io` should account for time boxing across multiple sessions, else it might be pretty much useless for working engineers who do it across time boxed sessions :-)

PS: I apologize in advance if you already have this feature, but is not so readily evident on your product home page.

Thanks for the feedback! I appreciate your perspective on time limits.

I don't have that feature, because I would argue that a problem you attack in three 1 hour stints across a span of 72 hours is a 72 hour problem.

Writing software is so much more than just typing. I tend to do my best coding in the shower or driving, nowhere near a computer. As soon as the challenge has been loaded into your brain, the work starts and the timer starts. How much of that time you spend in front of the keyboard is up to you.

Incidentally, I also think that a time limit of longer than an hour is probably too long. Uninterrupted multi-hour blocks are pretty hard to come by. Even if the time limit given isn't enough time for you to complete a perfect, working solution to the problem, it should be enough time for you to do enough work that we've got something meaty to talk about in the next interview.

This is how I do it, as a Director dn hiring manager. 4 hours max, and the exercise is entirely freeform against a set of 10 typical requirements; as a Front End Engineer candidate for my team, I want to see your opinion and execution matched to the problem at hand.

It can be done in 2 hours in the most simplistic, undeliberated way using legacy practices, but 8 if you're a perfectionist. Come in somewhere in the middle, but stop at 4 hours no matter where you're at.

I don't even require that the exercise is completed, but I want you to speak to your thought process and where you went/were going when you hit the 4 hour mark. The ability to understand our space, make good decisions, and show progress toward executing on them is ultimately what matters in the end.

That fits exactly with my method and thus the ethos of https://takehome.io

I don't mean to shill, but I think it'll be a great fit for you.

Thanks for the tip; we've been doing it in a similar fashion, and this solves the biggest variable: "How do we enforce that 4 hour maximum?"

This is really cool, thanks for sharing! I don't necessarily disagree with your point, though I do think an unrealistic time limit is even worse than no time limit. I also emphasize the importance of not taking on a challenge that is outside the scope of your ability here: https://www.fullstackinterviewing.com/2018/02/02/the-ultimat...

What are your thoughts on timed coding problems like Codility or Hackerrank?

Thank-you!

My contention is that it doesn't matter if the time limit is unrealistic (within reason) so long as it's consistent.

ie: the challenge is not "Show me the best solution to this problem" but rather "Show me the best solution to this problem that you can achieve within an hour".

As long as everyone is under the same conditions, the playing field is level.

It's part of a holistic approach, too. The coding challenge is not the only part of the interview process. I suggest that there be an initial interview to assess experience, fit, explain the job, etc. Then if everyone is still interested, the coding challenge. The candidate's response to the challenge then forms the basis for a discussion in another, technically focused interview.

It's not about saying "You gave the wrong answer" but "Talk me through why you solved it this way" and "If this criteria in the challenge changed, tell me about how that might change your response"

The Codility and Hackerrank style problems are okay, but I don't like how constrained they are. I also think it's pointless having someone outside your organisation grade the results. What matters is not having a candidate who is "the best hacker" but having someone who fits what you need. If your team values robustness and debuggability above all else, you _don't_ want someone who can punch out 3 kinda-right prototypes before lunch. If you're an ideation agency, the inverse is true.

That's why takehome encourages companies to create and administer their own challenges rather than the samples. They should fit the kinds of problems your organisation faces, not contrived ones.

Good point about consistency, which is hard to achieve with the open-ended take-home challenges. I still feel like there is a catch 22 for new developers though - if you're competing with more experienced candidates, your best solution that you can achieve within one hour will rarely be one of the better ones, and the only way to really get better is to have real experience working on a production app. And you still have to get hired to do that, hence the catch 22. So, that's why I advocate for spending more time on these challenges up front, especially for people first making the switch, because they can be used as a learning opportunity. So many companies don't have the time or just don't want to invest the time to train newer developers, which automatically eliminates hiring someone straight out of a bootcamp. Maybe someone with a CS degree and no work experience would have the same problem though.

I like what you said about the importance of companies administering their own challenges as well. I've encountered some like that and they do tend to be a better reflection of the types of challenges and problems the company is facing.