5 ms·

So much nope to this. > They would put you to the test for like 2-3 days to see how you perform And pay you. And give you some level of feedback along the way

So much nope to this. > They would put you to the test for like 2-3 days to see how you perform And pay you. And give you some level of feedback along the way, not just "here make some salads" and then "nah nevermind" after 3 days of hard work. And you get to work with them and decide if you like working there too. It's not a one-way street like these bullshit homework interview pipelines. Unlike in food, you're not going to be productive with real code for a few months. Unlike in food, just doing the coding is only 40-60% of the job. Unlike in food, it's hard to improvise code in a language, framework, test-style, knowledge-domain, or other toolset you may not be familiar with. Hiring for restuarants is not a relevant comparison. This just seems like the typical unpaid homework assignment--which is usually a couple softball algorithm questions mixed with some arbitrary glue-code riddles--with some CI-flavored slop on top.

site-packages1 6y ago
WordPress does the take home assignment but they pay you for your time, which is very cool.
yakshaving_jgt 6y ago
> you're not going to be productive with real code for a few months I've hired several engineers who get productive within the first week. Most manage to get in a PR and deploy to production by the end of the first day. If it's taking a few months before the candidate can get productive, something has gone horrifically wrong.
- rootusrootus 6y ago
  > ... something has gone horrifically wrong Agree 100%. And in most cases it probably isn't a problem with the candidate. It's a problem with the existing software and development process. It shouldn't take someone months to become useful on a new project.
- masonhensley 6y ago
  We've probably all seen or heard of places where a developer sits around for weeks, going to standups with their status update - "waiting on license XYZ" or waiting for access to the project (git, TFS, jira, vpns etc). It's a huge problem in many orgs. It's also a good sniff test if you're interviewing. Slow and steady might be up your alley too. There's definitely a hierarchy of security and compliance needs depending on the org, but many orgs loose the forest for the trees.
- pmiller2 6y ago
  > If it's taking a few months before the candidate can get productive, something has gone horrifically wrong. There's a big difference between "deployed their first PR" and "getting productive." The latter implies the engineer knows or has figured out how to use your source control, CI, and deployment processes. That probably is something most people can manage in a day, with proper instruction, provided the code change itself is simple enough. The latter means they're familiar with large parts of the codebase and are able to make changes, and have an idea how the major parts interact. This is what takes a few months.
- ryanianian 6y ago
  Solving a maze problem or fixing a gimme CSS or unit-test bug is significantly different development from what even junior-level engineers do on a regular basis after a few months in. The kinds of code you get on any sort of interview or one-day homework assignment are significantly different from what you'll see in 3 months. If not, as you say, something has gone horrifically wrong.
lliamander 6y ago
I actually like the homework assignments. As an interviewer, I think they are the best at assessing the coding aspects of job performance. Not perfect, but better than high-pressure in-person whiteboard/coding tests. As an interviewee, I like the flexibility to work on it as I have time (rather than using up PTO). The point of using algorithms isn't to test your algorithm skills (though using job relevant algorithms is a good idea if you can) but to test your ability to translate requirements into code by eliminating the quality of requirement specification as a variable. That is, because algorithms have an unambiguous specification, failing the coding assignment due to poorly specified requirements should impossible (or much less likely). For the non-coding part of the job, I find a (relatively short) structured interview works best.
- 908B64B197 6y ago
  The issue with homework is that the top percentage of engineers really won't have any time to complete a multi-hour homework assessment that might not even be graded by a human. For spammy applications or bad colleges sure. But that's not the target demographic.
  - pmiller2 6y ago
    How will said engineers have an entire day to do an onsite interview loop, if they can't carve out a couple of hours to do a homework assignment? My real problem with take home assignments is that while they take away the stress of being put on the spot in front of a whiteboard, often, the reward for doing well on them is... being put on the spot in front of a whiteboard. If anything, it might get one past the phone screen, but phone screens are not the biggest problem in SWE hiring.
    - lliamander 6y ago
      > often, the reward for doing well on them is... being put on the spot in front of a whiteboard. Ha! That can be true. So for me personally, I had candidates do a little bit of whiteboarding, but all I do is ask them to walk me through the execution of the algorithm they just implemented using minimal input parameters. Really what I'm looking for is the ability to explain how their code works (and to make sure they didn't copy someone else's work).
spankalee 6y ago
And how many candidates do they think you can interview this way? Let's say you hire 1 our of 10 candidates. Can you afford to give these types of assignments and manage them for 10 people to hire 1? Sounds completely implausible to me.
- cercatrova 6y ago
  That's not my problem as an interviewee. Competence is expensive, yes, and compared to an actual salary a few days' work is nothing.
- jlokier 6y ago
  Conversely, let's say a candidate joins 1 out of 10 companies they apply for. Can they afford to spend a few days coding or interviewing with each company? That's more than a solid month of work for the candidate.

site-packages1 6y ago

WordPress does the take home assignment but they pay you for your time, which is very cool.

yakshaving_jgt 6y ago

> you're not going to be productive with real code for a few months I've hired several engineers who get productive within the first week. Most manage to get in a PR and deploy to production by the end of the first day. If it's taking a few months before the candidate can get productive, something has gone horrifically wrong.

rootusrootus 6y ago
> ... something has gone horrifically wrong Agree 100%. And in most cases it probably isn't a problem with the candidate. It's a problem with the existing software and development process. It shouldn't take someone months to become useful on a new project.
masonhensley 6y ago
We've probably all seen or heard of places where a developer sits around for weeks, going to standups with their status update - "waiting on license XYZ" or waiting for access to the project (git, TFS, jira, vpns etc). It's a huge problem in many orgs. It's also a good sniff test if you're interviewing. Slow and steady might be up your alley too. There's definitely a hierarchy of security and compliance needs depending on the org, but many orgs loose the forest for the trees.
pmiller2 6y ago
> If it's taking a few months before the candidate can get productive, something has gone horrifically wrong. There's a big difference between "deployed their first PR" and "getting productive." The latter implies the engineer knows or has figured out how to use your source control, CI, and deployment processes. That probably is something most people can manage in a day, with proper instruction, provided the code change itself is simple enough. The latter means they're familiar with large parts of the codebase and are able to make changes, and have an idea how the major parts interact. This is what takes a few months.
ryanianian 6y ago
Solving a maze problem or fixing a gimme CSS or unit-test bug is significantly different development from what even junior-level engineers do on a regular basis after a few months in. The kinds of code you get on any sort of interview or one-day homework assignment are significantly different from what you'll see in 3 months. If not, as you say, something has gone horrifically wrong.

lliamander 6y ago

I actually like the homework assignments. As an interviewer, I think they are the best at assessing the coding aspects of job performance. Not perfect, but better than high-pressure in-person whiteboard/coding tests. As an interviewee, I like the flexibility to work on it as I have time (rather than using up PTO). The point of using algorithms isn't to test your algorithm skills (though using job relevant algorithms is a good idea if you can) but to test your ability to translate requirements into code by eliminating the quality of requirement specification as a variable. That is, because algorithms have an unambiguous specification, failing the coding assignment due to poorly specified requirements should impossible (or much less likely). For the non-coding part of the job, I find a (relatively short) structured interview works best.

908B64B197 6y ago
The issue with homework is that the top percentage of engineers really won't have any time to complete a multi-hour homework assessment that might not even be graded by a human. For spammy applications or bad colleges sure. But that's not the target demographic.
- pmiller2 6y ago
  How will said engineers have an entire day to do an onsite interview loop, if they can't carve out a couple of hours to do a homework assignment? My real problem with take home assignments is that while they take away the stress of being put on the spot in front of a whiteboard, often, the reward for doing well on them is... being put on the spot in front of a whiteboard. If anything, it might get one past the phone screen, but phone screens are not the biggest problem in SWE hiring.
  - lliamander 6y ago
    > often, the reward for doing well on them is... being put on the spot in front of a whiteboard. Ha! That can be true. So for me personally, I had candidates do a little bit of whiteboarding, but all I do is ask them to walk me through the execution of the algorithm they just implemented using minimal input parameters. Really what I'm looking for is the ability to explain how their code works (and to make sure they didn't copy someone else's work).

spankalee 6y ago

And how many candidates do they think you can interview this way? Let's say you hire 1 our of 10 candidates. Can you afford to give these types of assignments and manage them for 10 people to hire 1? Sounds completely implausible to me.

cercatrova 6y ago
That's not my problem as an interviewee. Competence is expensive, yes, and compared to an actual salary a few days' work is nothing.
jlokier 6y ago
Conversely, let's say a candidate joins 1 out of 10 companies they apply for. Can they afford to spend a few days coding or interviewing with each company? That's more than a solid month of work for the candidate.