29 ms·

>Maybe we should interview with small take-home tasks to be submitted with some write-ups to test how people research, reason, and write-up problems, rather tha

by dcow 6y ago

>Maybe we should interview with small take-home tasks to be submitted with some write-ups to test how people research, reason, and write-up problems, rather than writing code on the spot on a whiteboard. ...but maybe that's just me. I'm a huge fan of giving people tasks that somewhat resemble a real world problem they'd likely encounter or at least aligns categorically with their proclaimed resume feats and more importantly on top of that giving them the same environment they're comfortable working in on a daily basis which might be on a laptop in a quiet room from 6am to 10am in the morning. However, I'm usually instantly met with the "oh well we don't want to expect too much of our interview candidates" mentality as if asking them to do a "take home" (rather than telling them to figure out how to take a day off of work for an onsite panel) is somehow grotesquely disrespecting their time and would make the company look bad if the broader community even got a whiff that it had been considered. I'm so confused. People easily identify that white-boarding interviews suck for more than just the interviewee. And yet any time a solution is proposed that involves doing something other than putting the candidate in a room in front of a whiteboard for an hour, it's shot down. I've concluded it's a generational thing and the problem won't be fixed until we get a wave of hiring managers that weren't schooled on the Google interview process. But, also note it's a self perpetuating issue too so :shrug:.

quadrifoliate 6y ago
> However, I'm usually instantly met with the "oh well we don't want to expect too much of our interview candidates" mentality as if asking them to do a "take home" (rather than telling them to figure out how to take a day off of work for an onsite panel) is somehow grotesquely disrespecting their time and would make the company look bad if the broader community even got a whiff that it had been considered. I'm so confused. People easily identify that white-boarding interviews suck for more than just the interviewee. And yet any time a solution is proposed that involves doing something other than putting the candidate in a room in front of a whiteboard for an hour, it's shot down. I would be (and have been) one of those people. Why? In short, likely because your take-home tasks are tedious, boring, and unrepresentative of real-life work. They are not whiteboarding, but they aren't necessarily any better. I have done take homes as a candidate, and also have reviewed them on the hiring side. Most of the time, as a candidate, any take home I have done has been wasted time. Nothing I feel like I could count as a significant contribution, or something I could add to my resume. Take homes usually have some boring cookie cutter problem, with your most nitpicky code reviewers as the judges. Or it's something that's grotesquely oversize that's expected to be done in two hours (hedging with "but feel free to use up more time if you want"). As a reviewer, I see that it also leads to candidates doing ridiculous things like overusing decorators or metaclasses in an attempt to impress the reviewers. Honestly, as a candidate, I would be 100% satisfied with a bitesize fix to an open source library that your company maintains, or even a bitesize fix to a closed source library under contract. Or pair the candidate with an employee who is working on a real, minor task at your company, and let the candidate "drive". Give me something real to do, not some contrived situation about an ordering system or building the next Twitter. My mini-conspiracy theory about this is that most companies are so embarrassed about their codebases and internal process that they don't let prospective employees look at them until after they are hired.
- UnFleshedOne 6y ago
  A number of small tasks one can do in a few hours _and_ add to one's resume is probably approaching zero...
  - quadrifoliate 6y ago
    I guess portfolio is a better word I might use? Like if you ask me to write an interesting API, I could convert it into a project for future work. If you ask me to write a cool script, I could put it into an existing "interesting scripts" repo I maintain. I have never seen a take-home project yet that I could do this with. Also they come with scary "You may not show this to anyone else, ever!" disclaimers which are more off-putting.
- heavyset_go 6y ago
  > Honestly, as a candidate, I would be 100% satisfied with a bitesize fix to an open source library that your company maintains, or even a bitesize fix to a closed source library under contract. Or pair the candidate with an employee who is working on a real, minor task at your company, and let the candidate "drive". Give me something real to do, not some contrived situation about an ordering system or building the next Twitter. It can take relative ages to become familiar with a code base, especially a large one, such that you can easily hop in and commit fixes that actually work. I'm not going to spend hours trying to gain context for the code, or deploying and testing it. The employer is going to ghost 80% of their candidates anyway, and if your fix does work, you just did free work that benefits the company for little to no gain for yourself.
  - quadrifoliate 6y ago
    > It can take relative ages to become familiar with a code base, especially a large one, such that you can easily hop in and commit fixes that actually work. I'm not going to spend hours trying to gain context for the code, or deploying and testing it. If none of their codebases are easy to jump into, then that might be a red flag in of itself. One thing I suppose I have been lucky about is that I have worked for companies that have some (albeit very minor) open source presence. I'm not talking new features. IMO a small fix to an existing codebase can be as minor as adding a new CLI flag, or lightly modifying some existing behavior. In many cases, it's what you'd give a new intern as their first fix. > if your fix does work, you just did free work that benefits the company for little to no gain for yourself. Well the gain is that you learned to work with a real-life codebase. The thesis of my comment is that take-home projects do not often approximate a real life codebase well.
Sivart13 6y ago
"Take home" questions are heavily biased in favor of the employer because they're not required to put anything on the line. An asynchronous test is definitely more flexible for all parties, but it also means the employer can more forward with far more interviews than they would be able to do in person. Leading to more candidates wasting their time doing nonsense work when they have proportionally less of a chance of getting the job. Possibly I'm just bitter because of the time I spent 4 hours on a take-home only for the company to ghost me (name-and-shame: Instacart). But at least for in-person interviews they have to buy you lunch before the ghosting can occur.
- ccajas 6y ago
  >"Take home" questions are heavily biased in favor of the employer because they're not required to put anything on the line. Not to mention it doesn't test the collaboration aspects of real work. Imagine doing your job but you're not allowed to talk to your teammates in case of a blocker. How are we doing our jobs here? But when it comes down to actually starting them, I will always pass if they come before any interviewing round. You don't yet have a stake in the process.
  - cutemonster 6y ago
    And maybe excludes short of time people taking care of kids? Maybe more often women
- voltagex_ 6y ago
  The "easy" fix for this is to pay the candidate for the time spent on the take-home.
  - pmiller2 6y ago
    That has the down side of some potentially sticky legal issues. For instance, people on visas can't do paid work for any company other than the one sponsoring them. It introduces a small annoyance at tax time, as well.
nend 6y ago
I don't like take homes for two reasons: 1) It's less time spent talking with potential coworkers. Which for me, coworkers (and how we work together/get along) determine about 90% of how satisfied I am with my job (assuming pay/benefits are standard). 2) You're still going to require me to take a day off and stand up in front of a whiteboard anyway eventually. Every take home I've done is an early stage filter. The final round is still a whiteboard panel.
- bllguo 6y ago
  2. is the biggest thing for me. Exactly the same experience. I would be happy with take-homes if companies actually trusted them. The biggest reason I'm willing to do them is to avoid the whiteboarding. Of course from their perspective I could be getting someone else to do it for me or something. Or maybe the take-home leaked (which becomes more probable as the company grows).
  - doteka 6y ago
    I’m surprised this is your experience. At my current employer, that’s exactly how we approach hiring. I send the candidate a take-home that broadly covers the basic tech skills they need to be effective in their role (implement a simple test api, some questions about scaling web apps in production, and a possible architecture sketch for a described system). It’s expected to be around 4 hours of work. If they pass that, the interview is free of technical topics - we just talk about your past experience and assess whether you’d be a good fit for the team. Is this not how other take-home assignments work?
    - jwikstrom 6y ago
      Yes, it should be. This is how we do it
      - pmiller2 6y ago
        Do you feel comfortable saying who "we" is?
ccajas 6y ago
> People easily identify that white-boarding interviews suck for more than just the interviewee. And yet any time a solution is proposed that involves doing something other than putting the candidate in a room in front of a whiteboard for an hour, it's shot down. Most people take issue with the repetition of similar tests and evaluations for multiple companies. If A, B, and C were considered different stages of a technical interview, candidates are repeating A and B too often, whereas applying A and B once would suffice for several companies. It's a problem that is realized when opportunity cost is compounded when interviewing multiple companies and it's not something that a single company alone can fix. A more "Docker-ish" solution where using one of "A" to lay the foundation for many company interviews (and not just the ones expecting you to practice Leetcode) might curtail the problem of using more time and resources than necessary. But more than that, there is also a cognitive dissonance with the beliefs of how to reform a broken system. Programmers largely oppose industry-wide regulation while also expecting the vetting process to be more consistent and make more sense. This is a tough nut to crack because we seemingly want to have it both ways.
- derefr 6y ago
  > Programmers largely oppose industry-wide regulation ...of programming (because the regulation would never be able to catch up to the state of the art), sure. Of HR practices? I don't think I've ever heard an engineering lead lament that their company's restrictive HR practices prevent them from testing candidates the way they want. > and it's not something that a single company alone can fix Sure they can: micro-credentials. Someone needs to be the CompTIA of tiny programming challenges, where you prove once-and-for-all (in a proctored situation) that you can solve FizzBuzz or whatever, and get that fact recorded in some database. Hopefully, candidates could then put their MicroCredentialsCorp username on their resumes or into companies' application forms or what-have-you; and then first-stage HR automation (the same kind that matches resumes to keywords) could run through a bunch of RESTful predicate-endpoints checks like https://api.example.com/u/derefr/knows/fizzbuzz https://api.example.com/u/derefr/knows/fizzbuzz (which would return either a signed+timestamped blob of credential JSON, or a 404.) Hopefully also, allow anyone to create a test (maybe have the end of that HTTP route just represent the username+repo of a GitHub repo where an executable test for the micro-skill lives?), such that these micro-credentials can live or die not by central supply, but rather by market demand. (I think someone suggested doing this with a blockchain once, but there's really no need for that.)
Deestan 6y ago
We do take-home, and tell the candidate to not use more than 4 hours on it and deliver it any time during the next week (this is to respect their time). The testing system logs their activity, so if someone decides to spend two days on it, we'll know. Not a problem as such, but it raises our expectations of the delivery. :) Next stage is a technical interview of 60-90 minutes where we a) try to find what their strengths are and how deep they go, and b) ask them to explain how they solved the take-home. b) is critical. Of course it tests for the skill that is critical in teamwork: communication ability, but it also lets us catch cheaters. After this it's HR and reference checking. It's worked well so far.
bananaface 6y ago
Take-home tests are stupid because they instantly filter out anybody with options. If I'm being hit up by recruiters, I might come for an interview with you, but I'm not going to waste time with your test. You're going to end up with monkeys. But even beyond that, it's so dumb to re-demonstrate coding chops to every single employer, especially when I have no idea what my chances are to begin with. Are you interviewing 100 candidates, or 2? Go look at my GitHub.
- collyw 6y ago
  Yes, I did one recently, got told it should take 2 or 3 hours, so I spent a morning on it. Got failed for a number of the most trivial reasons - it didn't meet PEP 8 (it was two white space errors, as I didn't have pep installed on my home laptop, so I missed them). A load of stuff about not mocking tests (setting up that would have doubled the scope of the project). The spec and said if you don't have time, then describe what you would have added in terms of tests - which I did). I did provide the most difficult to implement integration test to prove the system worked. There was a complaint providing an HTML webpage rather than a JSON endpoint (the spec described it as a "page" and said not to bother with styling - so implied that it was HTML). Plus a couple of other equally ridiculous complains. Don't waste your time with takehome tests without speaking to someone in engineering first. Sennder is the company if anyone else wants to avoid, I think we should be naming and shaming such companies.
  - bananaface 6y ago
    Good God. That sounds awful.
- yahyaheee 6y ago
  Yes, if an employer doesn’t understand how to look at my GitHub then they aren’t worth my time.

by dcow 6y ago

quadrifoliate 6y ago

> However, I'm usually instantly met with the "oh well we don't want to expect too much of our interview candidates" mentality as if asking them to do a "take home" (rather than telling them to figure out how to take a day off of work for an onsite panel) is somehow grotesquely disrespecting their time and would make the company look bad if the broader community even got a whiff that it had been considered. I'm so confused. People easily identify that white-boarding interviews suck for more than just the interviewee. And yet any time a solution is proposed that involves doing something other than putting the candidate in a room in front of a whiteboard for an hour, it's shot down. I would be (and have been) one of those people. Why? In short, likely because your take-home tasks are tedious, boring, and unrepresentative of real-life work. They are not whiteboarding, but they aren't necessarily any better. I have done take homes as a candidate, and also have reviewed them on the hiring side. Most of the time, as a candidate, any take home I have done has been wasted time. Nothing I feel like I could count as a significant contribution, or something I could add to my resume. Take homes usually have some boring cookie cutter problem, with your most nitpicky code reviewers as the judges. Or it's something that's grotesquely oversize that's expected to be done in two hours (hedging with "but feel free to use up more time if you want"). As a reviewer, I see that it also leads to candidates doing ridiculous things like overusing decorators or metaclasses in an attempt to impress the reviewers. Honestly, as a candidate, I would be 100% satisfied with a bitesize fix to an open source library that your company maintains, or even a bitesize fix to a closed source library under contract. Or pair the candidate with an employee who is working on a real, minor task at your company, and let the candidate "drive". Give me something real to do, not some contrived situation about an ordering system or building the next Twitter. My mini-conspiracy theory about this is that most companies are so embarrassed about their codebases and internal process that they don't let prospective employees look at them until after they are hired.

UnFleshedOne 6y ago
A number of small tasks one can do in a few hours _and_ add to one's resume is probably approaching zero...
- quadrifoliate 6y ago
  I guess portfolio is a better word I might use? Like if you ask me to write an interesting API, I could convert it into a project for future work. If you ask me to write a cool script, I could put it into an existing "interesting scripts" repo I maintain. I have never seen a take-home project yet that I could do this with. Also they come with scary "You may not show this to anyone else, ever!" disclaimers which are more off-putting.
heavyset_go 6y ago
> Honestly, as a candidate, I would be 100% satisfied with a bitesize fix to an open source library that your company maintains, or even a bitesize fix to a closed source library under contract. Or pair the candidate with an employee who is working on a real, minor task at your company, and let the candidate "drive". Give me something real to do, not some contrived situation about an ordering system or building the next Twitter. It can take relative ages to become familiar with a code base, especially a large one, such that you can easily hop in and commit fixes that actually work. I'm not going to spend hours trying to gain context for the code, or deploying and testing it. The employer is going to ghost 80% of their candidates anyway, and if your fix does work, you just did free work that benefits the company for little to no gain for yourself.
- quadrifoliate 6y ago
  > It can take relative ages to become familiar with a code base, especially a large one, such that you can easily hop in and commit fixes that actually work. I'm not going to spend hours trying to gain context for the code, or deploying and testing it. If none of their codebases are easy to jump into, then that might be a red flag in of itself. One thing I suppose I have been lucky about is that I have worked for companies that have some (albeit very minor) open source presence. I'm not talking new features. IMO a small fix to an existing codebase can be as minor as adding a new CLI flag, or lightly modifying some existing behavior. In many cases, it's what you'd give a new intern as their first fix. > if your fix does work, you just did free work that benefits the company for little to no gain for yourself. Well the gain is that you learned to work with a real-life codebase. The thesis of my comment is that take-home projects do not often approximate a real life codebase well.

Sivart13 6y ago

"Take home" questions are heavily biased in favor of the employer because they're not required to put anything on the line. An asynchronous test is definitely more flexible for all parties, but it also means the employer can more forward with far more interviews than they would be able to do in person. Leading to more candidates wasting their time doing nonsense work when they have proportionally less of a chance of getting the job. Possibly I'm just bitter because of the time I spent 4 hours on a take-home only for the company to ghost me (name-and-shame: Instacart). But at least for in-person interviews they have to buy you lunch before the ghosting can occur.

ccajas 6y ago
>"Take home" questions are heavily biased in favor of the employer because they're not required to put anything on the line. Not to mention it doesn't test the collaboration aspects of real work. Imagine doing your job but you're not allowed to talk to your teammates in case of a blocker. How are we doing our jobs here? But when it comes down to actually starting them, I will always pass if they come before any interviewing round. You don't yet have a stake in the process.
- cutemonster 6y ago
  And maybe excludes short of time people taking care of kids? Maybe more often women
voltagex_ 6y ago
The "easy" fix for this is to pay the candidate for the time spent on the take-home.
- pmiller2 6y ago
  That has the down side of some potentially sticky legal issues. For instance, people on visas can't do paid work for any company other than the one sponsoring them. It introduces a small annoyance at tax time, as well.

nend 6y ago

I don't like take homes for two reasons: 1) It's less time spent talking with potential coworkers. Which for me, coworkers (and how we work together/get along) determine about 90% of how satisfied I am with my job (assuming pay/benefits are standard). 2) You're still going to require me to take a day off and stand up in front of a whiteboard anyway eventually. Every take home I've done is an early stage filter. The final round is still a whiteboard panel.

bllguo 6y ago
2. is the biggest thing for me. Exactly the same experience. I would be happy with take-homes if companies actually trusted them. The biggest reason I'm willing to do them is to avoid the whiteboarding. Of course from their perspective I could be getting someone else to do it for me or something. Or maybe the take-home leaked (which becomes more probable as the company grows).
- doteka 6y ago
  I’m surprised this is your experience. At my current employer, that’s exactly how we approach hiring. I send the candidate a take-home that broadly covers the basic tech skills they need to be effective in their role (implement a simple test api, some questions about scaling web apps in production, and a possible architecture sketch for a described system). It’s expected to be around 4 hours of work. If they pass that, the interview is free of technical topics - we just talk about your past experience and assess whether you’d be a good fit for the team. Is this not how other take-home assignments work?
  - jwikstrom 6y ago
    Yes, it should be. This is how we do it
    - pmiller2 6y ago
      Do you feel comfortable saying who "we" is?

ccajas 6y ago

> People easily identify that white-boarding interviews suck for more than just the interviewee. And yet any time a solution is proposed that involves doing something other than putting the candidate in a room in front of a whiteboard for an hour, it's shot down. Most people take issue with the repetition of similar tests and evaluations for multiple companies. If A, B, and C were considered different stages of a technical interview, candidates are repeating A and B too often, whereas applying A and B once would suffice for several companies. It's a problem that is realized when opportunity cost is compounded when interviewing multiple companies and it's not something that a single company alone can fix. A more "Docker-ish" solution where using one of "A" to lay the foundation for many company interviews (and not just the ones expecting you to practice Leetcode) might curtail the problem of using more time and resources than necessary. But more than that, there is also a cognitive dissonance with the beliefs of how to reform a broken system. Programmers largely oppose industry-wide regulation while also expecting the vetting process to be more consistent and make more sense. This is a tough nut to crack because we seemingly want to have it both ways.

derefr 6y ago
> Programmers largely oppose industry-wide regulation ...of programming (because the regulation would never be able to catch up to the state of the art), sure. Of HR practices? I don't think I've ever heard an engineering lead lament that their company's restrictive HR practices prevent them from testing candidates the way they want. > and it's not something that a single company alone can fix Sure they can: micro-credentials. Someone needs to be the CompTIA of tiny programming challenges, where you prove once-and-for-all (in a proctored situation) that you can solve FizzBuzz or whatever, and get that fact recorded in some database. Hopefully, candidates could then put their MicroCredentialsCorp username on their resumes or into companies' application forms or what-have-you; and then first-stage HR automation (the same kind that matches resumes to keywords) could run through a bunch of RESTful predicate-endpoints checks like https://api.example.com/u/derefr/knows/fizzbuzz https://api.example.com/u/derefr/knows/fizzbuzz (which would return either a signed+timestamped blob of credential JSON, or a 404.) Hopefully also, allow anyone to create a test (maybe have the end of that HTTP route just represent the username+repo of a GitHub repo where an executable test for the micro-skill lives?), such that these micro-credentials can live or die not by central supply, but rather by market demand. (I think someone suggested doing this with a blockchain once, but there's really no need for that.)

Deestan 6y ago

We do take-home, and tell the candidate to not use more than 4 hours on it and deliver it any time during the next week (this is to respect their time). The testing system logs their activity, so if someone decides to spend two days on it, we'll know. Not a problem as such, but it raises our expectations of the delivery. :) Next stage is a technical interview of 60-90 minutes where we a) try to find what their strengths are and how deep they go, and b) ask them to explain how they solved the take-home. b) is critical. Of course it tests for the skill that is critical in teamwork: communication ability, but it also lets us catch cheaters. After this it's HR and reference checking. It's worked well so far.

bananaface 6y ago

Take-home tests are stupid because they instantly filter out anybody with options. If I'm being hit up by recruiters, I might come for an interview with you, but I'm not going to waste time with your test. You're going to end up with monkeys. But even beyond that, it's so dumb to re-demonstrate coding chops to every single employer, especially when I have no idea what my chances are to begin with. Are you interviewing 100 candidates, or 2? Go look at my GitHub.

collyw 6y ago
Yes, I did one recently, got told it should take 2 or 3 hours, so I spent a morning on it. Got failed for a number of the most trivial reasons - it didn't meet PEP 8 (it was two white space errors, as I didn't have pep installed on my home laptop, so I missed them). A load of stuff about not mocking tests (setting up that would have doubled the scope of the project). The spec and said if you don't have time, then describe what you would have added in terms of tests - which I did). I did provide the most difficult to implement integration test to prove the system worked. There was a complaint providing an HTML webpage rather than a JSON endpoint (the spec described it as a "page" and said not to bother with styling - so implied that it was HTML). Plus a couple of other equally ridiculous complains. Don't waste your time with takehome tests without speaking to someone in engineering first. Sennder is the company if anyone else wants to avoid, I think we should be naming and shaming such companies.
- bananaface 6y ago
  Good God. That sounds awful.
yahyaheee 6y ago
Yes, if an employer doesn’t understand how to look at my GitHub then they aren’t worth my time.