> On Mar 23, 2017, at 11:59 AM, Mark Engelberg <mark.engelb...@gmail.com> wrote: > > On Thu, Mar 23, 2017 at 11:24 AM, Luke Burton <luke_bur...@me.com > <mailto:luke_bur...@me.com>> wrote: > > * So … if I was in your position, knowing what I know now, if I couldn't find > companies that had very progressive hiring practices, I would make my resume > stand out by leading in with an offer to spend a few hours writing a small > implementation of anything the hiring manager would like me to write. Many > hiring mangers are scared by take home projects because they're afraid of > what the best candidate will think. "It's an insult to experienced > candidates!" or "how would a rockstar candidate possibly spare the time?" But > secretly I think all hiring mangers *really* want to know what it will be > like to have you write code on their behalf. It's just not the industry norm > to ask. > > Insightful post about a lot of things related to hiring, but I have to take > exception with this very last point. Recently, a friend of mine sought out a > data science position in the Seattle area. Each prospective employer gave > him a take-home assignment that required 30-40 work hours to complete. Some > of the assignments were real problems the company was facing, so he was > effectively being asked to do free consulting work for each company. This is > a horrible, burdensome interview practice and it would be dreadful if it > became the norm in the software industry. Suggesting that someone offer to do > a take-home project may make sense in specific cases for an inexperienced > candidate, but I fear it starts our industry down the slippery slope.
I definitely share the concern. 30-40 hours is totally not what I'd consider a take home project. I also think "real problems facing the company" has a host of issues associated with it, including the one you pointed out which is that it blurs the line between free labor and hiring pipeline. While I believe that a hiring pipeline this onerous is very unlikely to catch on and be the industry norm, I would put forward the proposal that a take-home project must *not* be work that directly contributes to the hiring company's value stream. I'd like to give you a sense of how I approached this problem, just to give a counterexample that is maybe more hopeful: * We encouraged the candidate to have fun with the problem! The goal was not to stress them out under a deadline, but to give them enough time to relax into their normal engineering mindset. They could use any resource they liked, any framework or language they felt would suit the solution. * They got to pick their own starting date, and deliver us a self-contained artifact of some kind a week later. Having to write "hand off" instructions was surprisingly telling! It was also surprising to see a candidate's git repo, to see how their solution evolved over time. * The project was very, very general in specification. Almost uncomfortably open ended. I value candidates that can work with loose specifications, but I also wanted to let the candidate decide what they felt was "done" enough to share. And I wanted to ensure it wasn't possible to find canned solutions on the internet (Facebook found that their iOS candidates became increasingly adept at writing exactly the same tic-tac-toe interfaces, hmm …) * Their project solution would be the primary focus of any in-person interviews we followed up with. This is no small point, it really gave those interviews a sense of structure and purpose that I had not seen before. The candidate's memory for their code is fresh and they feel confident, while the interviewers all had plenty of good questions having checked out the candidate's repo and deep dived into it. There was other minutiae specific to the role and company that isn't interesting here, but hopefully that gives some sense of how I tried to balance the various concerns. I think it parallelizes nicely too, in the future I would not hesitate to send a project like this out to *everyone* who submitted a resume, just to see what comes back. I guess I've spilled this many words I may as well share what the project was. Aside from lots of preamble explaining the above, what I sent out was: > The city of San Francisco has an open data repository located at > data.sfgov.org <http://data.sfgov.org/>. The amount of available data is > pretty impressive. Your task is to create a composite metric for city > restaurants, based on at least two variables from data in the repository. It > need not take itself too seriously, if you want to rate a location based on > its seismic activity and wind speed, go for it. It could be qualitative or > quantitative. > > The end result should be a full stack web application that gives us the > ability to browse or search your calculated results. We'd like to see what > you can do in a week. Keep it simple! A working, but simple result is more > impressive than a complicated, but half-finished result. At the heart of it I'm really asking them to embark on a small descriptive statistics problem. They have to ingest some data, calculate a score based on potentially uncorrelated data points, and present it. All in a self-sufficient web application. The results were really, really revealing. I am looking forward to trying this on Clojure / ClojureScript positions in the future :) But I guess I'll have to change the problem now! Luke. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
