4 ms·

> 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 h

> 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.
dcow 6y ago
Interesting. I think we're getting into the implementation of take homes. My proposal is (1) that a take home technical challenge entirely replace any in-person spontaneous white board drills, and (2) that it only be issued to candidates who you're prepared to bring on-site or otherwise schedule to meet the team if they present you a working solution. I'm not advocating for them to be used as a low-pass filter and spammed to all candidates without some mutual engagement first. The expectation of the onsite is that everyone has reviewed your solution and people can discuss why you made certain decisions or how the introduction of new requirements might impact the design. Or you can talk about why you hate kubernetes or the mini pineboard cluster you built. I disagree that the goal of an interview experience should be to necessarily give the candidate a new portfolio accomplishment. It's cool if it works out that way, for sure, but that can't be the expectation. I'm mostly interested in incrementally improving the status quo which also isn't focused around an interview day that bolsters your portfolio as an engineer. I will say my favorite and most memorable interview experience was a phone screen followed by a take home to implement bottles and kegs (a fizz-buzz game) in javascript, a language I was/am not proficient in. Come onsite day, we worked though a ux design problem and a database design problem, we pair debugged some ruby code, and then we wrote a multiplayer back-end for my fizz-buzz client, something I'd also never done before. It definitely ticked the "add something to your portfolio" box but also wasn't stressful in the same way flash 1-hr whiteboard sessions are because I was bringing something to the table that we expanded on during the day-long session.
bananaface 6y ago
I like this solution a lot, but if they asked you to contribute to a public codebase, you'd be able to tell who the other interviewees were, and how many of them you were up against.

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.

dcow 6y ago

Interesting. I think we're getting into the implementation of take homes. My proposal is (1) that a take home technical challenge entirely replace any in-person spontaneous white board drills, and (2) that it only be issued to candidates who you're prepared to bring on-site or otherwise schedule to meet the team if they present you a working solution. I'm not advocating for them to be used as a low-pass filter and spammed to all candidates without some mutual engagement first. The expectation of the onsite is that everyone has reviewed your solution and people can discuss why you made certain decisions or how the introduction of new requirements might impact the design. Or you can talk about why you hate kubernetes or the mini pineboard cluster you built. I disagree that the goal of an interview experience should be to necessarily give the candidate a new portfolio accomplishment. It's cool if it works out that way, for sure, but that can't be the expectation. I'm mostly interested in incrementally improving the status quo which also isn't focused around an interview day that bolsters your portfolio as an engineer. I will say my favorite and most memorable interview experience was a phone screen followed by a take home to implement bottles and kegs (a fizz-buzz game) in javascript, a language I was/am not proficient in. Come onsite day, we worked though a ux design problem and a database design problem, we pair debugged some ruby code, and then we wrote a multiplayer back-end for my fizz-buzz client, something I'd also never done before. It definitely ticked the "add something to your portfolio" box but also wasn't stressful in the same way flash 1-hr whiteboard sessions are because I was bringing something to the table that we expanded on during the day-long session.

bananaface 6y ago

I like this solution a lot, but if they asked you to contribute to a public codebase, you'd be able to tell who the other interviewees were, and how many of them you were up against.