7 ms·

Whats the general consensus on take home projects? How helpful are they?

shados 7y ago
Anecdotal survey in my city's community across a couple of companies say 30-50% of people never turn them back in, so while its a powerful tool that gets rid of a lot of issues with typical screens, it introduces friction a lot of people don't want to deal with. They'd be more useful in a buyer's market.
- jethro_tell 7y ago
  Also, I can set aside an hour or two during the day to chat with you. If you ask me to spend hours implementing something on my own time, I will assume you also ask your employees to do that and will completely blow that off. What you'll end up with is people who are desperate for your job, which may or may not be a great sign.
sys_64738 7y ago
I'd bill the company asking for them a minimum of eight hours at contracting rates. My time isn't free.
gravypod 7y ago
I haven't been able to find a better screening method than take home projects. A major issue that I find when watching hiring take place is people don't separate learnable/domain specific skills from the "inherent" skills you need as an engineer. Hiring someone who has a 10 year track record as a software engineer in systems software for a web-stack backend role should be an easy "Yes" if they are a skilled software engineer. Because of this I usually encourage people to make take home problems that are limited in scope and follow the restrictions: - Should not take longer than 3 hours for an inexperienced developer. - No learnable skills tested like tooling, language, and domain experience. - Simple to understand problem - Problem should be obviously mappable to a solution - Provide sample input and sample output data (only 1 case). I then score using the following questions - Did the code work on the sample I provided? - Were edge cases in the spec accounted for? - Has the engineer followed a language standard (PEP/PSR)? - Were docs (install, compile, comments) provided? - Were unit tests provided? - Were sample cases the engineer ran manually provided? - Was the code "elegant"? Could another engineer at the company look at the code and maintain it in a year. I think the actual project should have low bearing on completion and the state and cleanliness of the code has a higher mapping to quality.
- hysan 7y ago
  Would you be able to give an example of how limited in scope you're talking about? Is it just a single "write a method that does this" type problem? I ask because I did a take home very recently which I know I could knock out quickly, but it took much long because everything you listed ballooned the amount of time it took me to complete it. Specifically: - Has the engineer followed a language standard (PEP/PSR)? For JavaScript, it takes some time to setup a new project from scratch with linting and formatting configurations. Then documenting it in your README. - Were unit tests provided? - Were sample cases the engineer ran manually provided? Once you go beyond a few "features" to write, this balloons in time due to both writing it with good descriptions and documenting it for the reviewer. - Was the code "elegant"? Could another engineer at the company look at the code and maintain it in a year. If what you ask is of sufficient complexity, it would just be normal to take time to think about what the interviewer is expecting here. Like what future features could there be? How might this be used in a larger codebase? etc. Then once you've decided on this, you'll want to spend time commenting and/or writing up an explanation in your README about your design choices. Lastly, this isn't mentioned but I did this on the take home I recently completed - using version control and properly branching & merging on each deliverable. Doesn't take time, but if you are making atomic commits with good comments, that's just another way for you to lose time. Of course, I don't think the fact that I did this is going to be noticed as it wasn't written out as a requirement. If you notice what I'm nitpicking, it's all the setup and writing that becomes a time sink for most. In isolation, it wouldn't break the bank, but with all those requirements combined, you've lost much more than 3 hrs. When I'm given take homes for interviews, this is where I've burnt the most time - taking the time to document well.
  - mburger 7y ago
    What about having a discussion on how the candidate would solve a given take home? You could check if she would think of the required parts. For instance, would she think of unit tests? If she wouldn’t mention tests, you could ask „How would you ensure that your program works as expected?“ Thus, solving the take home theoretically.
    - 7y ago
scruffyherder 7y ago
If you like to roleplay as a tenured professor, sure it's great. Otherwise it's a total waste of everyone's time. Extra points if you have a tweed vest and a smoking pipe.
n_ary 7y ago
Take home has two sides to it. Group A: People who excel at face to face interviews(extroverted) will complain that it is waste of time and disrespectful, because it demands significant time commitment compared to a 1 hour in-person interview. Group B: People with interview anxiety(introverted) will excel at this type of test because they have the freedom to set aside their own time, do things at their own pace and environment. However, people from Group-A has a point, because certain take-home assingment are notoriously complex and will take multiple days of effort if you want to meet all requirements, which are not an option for people with family & existing job.
- djhworld 7y ago
  > significant time commitment compared to a 1 hour in-person interview. I don't think I've ever been in a software engineer interview where the face to face portion is less than 3 hours (at minimum!)
  - lubesGordi 7y ago
    I think they're talking about the initial 'phone screen' portion of the interview.
- AnimalMuppet 7y ago
  I don't know that I'm extroverted. I'm still in group A, though, because I don't have interview anxiety. My problem with take home stuff is that it's asymmetrical. That is, if we're doing a phone interview, it takes my time, and it takes your time. Ditto an in-person interview. You're serious enough to commit some of your time to it, so I'm willing to also do so. I know you're looking at other candidates, but if you call me in for an in-person interview, I figure I've got at least a 30% chance of landing the job. That's enough for me to be willing to invest the time. But with a take-home assignment, it costs me much more time than it costs you. So you could be giving it out to tons of people. How many? I have no way of knowing. So you're asking me for 6 hours (which may turn into 12), but what are my odds on getting the job? Are they still 30%? Or are they now 1%, because you just gave this assignment to 100 people? I'm not going to plow 12 hours of my time into a 1% chance at a job. Just no. And the problem is, if you tell me "oh, we're only looking at a couple of people", I have no reason to believe you. But if you're actually interviewing me, I believe you, because it's too expensive for you to interview 100 people to hire only one.
mjfisher 7y ago
Really helpful, as long as they're done well and respect the candidate as much as possible. In my experience, they provide a great way of understanding a candidate's skills. It also lets them work in a low-pressure environment with their own tools, which tends to let people achieve their best. I actually recently launched a service to help make managing take home tests through git more efficient: https://candidatecode.com https://candidatecode.com It's still early stage, so any feedback is appreciated

Anecdotal survey in my city's community across a couple of companies say 30-50% of people never turn them back in, so while its a powerful tool that gets rid of a lot of issues with typical screens, it introduces friction a lot of people don't want to deal with. They'd be more useful in a buyer's market.

jethro_tell 7y ago
Also, I can set aside an hour or two during the day to chat with you. If you ask me to spend hours implementing something on my own time, I will assume you also ask your employees to do that and will completely blow that off. What you'll end up with is people who are desperate for your job, which may or may not be a great sign.

sys_64738 7y ago

I'd bill the company asking for them a minimum of eight hours at contracting rates. My time isn't free.

gravypod 7y ago

I haven't been able to find a better screening method than take home projects. A major issue that I find when watching hiring take place is people don't separate learnable/domain specific skills from the "inherent" skills you need as an engineer. Hiring someone who has a 10 year track record as a software engineer in systems software for a web-stack backend role should be an easy "Yes" if they are a skilled software engineer. Because of this I usually encourage people to make take home problems that are limited in scope and follow the restrictions: - Should not take longer than 3 hours for an inexperienced developer. - No learnable skills tested like tooling, language, and domain experience. - Simple to understand problem - Problem should be obviously mappable to a solution - Provide sample input and sample output data (only 1 case). I then score using the following questions - Did the code work on the sample I provided? - Were edge cases in the spec accounted for? - Has the engineer followed a language standard (PEP/PSR)? - Were docs (install, compile, comments) provided? - Were unit tests provided? - Were sample cases the engineer ran manually provided? - Was the code "elegant"? Could another engineer at the company look at the code and maintain it in a year. I think the actual project should have low bearing on completion and the state and cleanliness of the code has a higher mapping to quality.

hysan 7y ago
Would you be able to give an example of how limited in scope you're talking about? Is it just a single "write a method that does this" type problem? I ask because I did a take home very recently which I know I could knock out quickly, but it took much long because everything you listed ballooned the amount of time it took me to complete it. Specifically: - Has the engineer followed a language standard (PEP/PSR)? For JavaScript, it takes some time to setup a new project from scratch with linting and formatting configurations. Then documenting it in your README. - Were unit tests provided? - Were sample cases the engineer ran manually provided? Once you go beyond a few "features" to write, this balloons in time due to both writing it with good descriptions and documenting it for the reviewer. - Was the code "elegant"? Could another engineer at the company look at the code and maintain it in a year. If what you ask is of sufficient complexity, it would just be normal to take time to think about what the interviewer is expecting here. Like what future features could there be? How might this be used in a larger codebase? etc. Then once you've decided on this, you'll want to spend time commenting and/or writing up an explanation in your README about your design choices. Lastly, this isn't mentioned but I did this on the take home I recently completed - using version control and properly branching & merging on each deliverable. Doesn't take time, but if you are making atomic commits with good comments, that's just another way for you to lose time. Of course, I don't think the fact that I did this is going to be noticed as it wasn't written out as a requirement. If you notice what I'm nitpicking, it's all the setup and writing that becomes a time sink for most. In isolation, it wouldn't break the bank, but with all those requirements combined, you've lost much more than 3 hrs. When I'm given take homes for interviews, this is where I've burnt the most time - taking the time to document well.
- mburger 7y ago
  What about having a discussion on how the candidate would solve a given take home? You could check if she would think of the required parts. For instance, would she think of unit tests? If she wouldn’t mention tests, you could ask „How would you ensure that your program works as expected?“ Thus, solving the take home theoretically.
  - 7y ago

scruffyherder 7y ago

If you like to roleplay as a tenured professor, sure it's great. Otherwise it's a total waste of everyone's time. Extra points if you have a tweed vest and a smoking pipe.

n_ary 7y ago

Take home has two sides to it. Group A: People who excel at face to face interviews(extroverted) will complain that it is waste of time and disrespectful, because it demands significant time commitment compared to a 1 hour in-person interview. Group B: People with interview anxiety(introverted) will excel at this type of test because they have the freedom to set aside their own time, do things at their own pace and environment. However, people from Group-A has a point, because certain take-home assingment are notoriously complex and will take multiple days of effort if you want to meet all requirements, which are not an option for people with family & existing job.

djhworld 7y ago
> significant time commitment compared to a 1 hour in-person interview. I don't think I've ever been in a software engineer interview where the face to face portion is less than 3 hours (at minimum!)
- lubesGordi 7y ago
  I think they're talking about the initial 'phone screen' portion of the interview.
AnimalMuppet 7y ago
I don't know that I'm extroverted. I'm still in group A, though, because I don't have interview anxiety. My problem with take home stuff is that it's asymmetrical. That is, if we're doing a phone interview, it takes my time, and it takes your time. Ditto an in-person interview. You're serious enough to commit some of your time to it, so I'm willing to also do so. I know you're looking at other candidates, but if you call me in for an in-person interview, I figure I've got at least a 30% chance of landing the job. That's enough for me to be willing to invest the time. But with a take-home assignment, it costs me much more time than it costs you. So you could be giving it out to tons of people. How many? I have no way of knowing. So you're asking me for 6 hours (which may turn into 12), but what are my odds on getting the job? Are they still 30%? Or are they now 1%, because you just gave this assignment to 100 people? I'm not going to plow 12 hours of my time into a 1% chance at a job. Just no. And the problem is, if you tell me "oh, we're only looking at a couple of people", I have no reason to believe you. But if you're actually interviewing me, I believe you, because it's too expensive for you to interview 100 people to hire only one.

mjfisher 7y ago

Really helpful, as long as they're done well and respect the candidate as much as possible. In my experience, they provide a great way of understanding a candidate's skills. It also lets them work in a low-pressure environment with their own tools, which tends to let people achieve their best. I actually recently launched a service to help make managing take home tests through git more efficient: https://candidatecode.com https://candidatecode.com It's still early stage, so any feedback is appreciated