I know it's important to make sure someone can code, but projects introduce a lot of time and stress to the equation because as a candidate I want to make sure they're perfect. Even if it's just a URL shortener, I'd end up spending a lot of time on setup, using the latest tech, unit testing, refactoring, optimization, build tooling...it quickly becomes overwhelming, especially when the company isn't thoughtful enough to provide a list of specific things my work will be graded on.
Asking candidates to do several hours of example work can shut valuable people out of your hiring pool--people who don't have the spare time, people who are very junior, even people who are too senior (if they can get other offers easily, why should they spend an entire day applying for one?). I myself have declined to interview for a role or two because the process was too much work.
A better (and more scientifically-proven) approach to interviewing would be a brief face-to-face followed by an hour of pair programming with an actual employee doing actual day-to-day work. If the experience is positive, you have reason to believe the candidate will be a very good fit.
I don't know of a "quick" way to pick the most qualified candidates from a set of 100. Every study I've seen indicates that a resume review or phone screen is about as good as a random number generator.
We can use the 37% rule as suggested by the Optimal Stopping algorithm, I suppose this is very similar to the Secretary problem. So, in a pool of 100 applicants, talk to the first 37 people, stop there, and choose among the 37. This is the first chapter of "Algorithms to Live by" (B. Christian and T. Griffiths)
Je cherche à vous aider à atteindre vos objectifs #code en #français . My goal is to help you work faster by sharing what I know about #SQL, #Python, and #Salesforce in #English and #French
I'm always inspired by the "2nd interview" quiz I was given for an entry-level job that was going to require putting data from spreadsheets into Mailchimp-like and Microsoft Word Mail Merge documents:
I was given a 3-column, 2-record spreadsheet. First & last name, plus M or F.
I was told that I had 15 minutes of quiet time with a computer, open internet, to edit a letter in Microsoft Word so that, when merged, would greet the person as "Dear [Mr./Ms.] so-and-so."
I've always been inspired by that exercise. Nothing about it that you can agonize over whether you're doing it "nicely enough" -- pure "testing output" answer. Short timeframe.
When I interviewed for a more senior position with a company that ate or starved based on the quality of its estimates (consultants), they asked me to tell them how I'd estimate the number of pennies that would fit in the room they were in. I kind of bombed the question (never been good at candy jars), but I thought it was a great "don't agonize over this ... we just want to get some quick idea of whether you're completely untrainable, in the wide band that is normal, or frighteningly off-the-charts fast" type of skill test.
But pair programming sounds like a good idea when more time and effort is necessary.
I like the idea of pair programming but even that can be stressing for even a senior developer.
I like the original article outline, I just wish that the candidate is told before hand what is he graded on instead of just guessing where to spend more of his/her time.
I know it's important to make sure someone can code, but projects introduce a lot of time and stress to the equation because as a candidate I want to make sure they're perfect. Even if it's just a URL shortener, I'd end up spending a lot of time on setup, using the latest tech, unit testing, refactoring, optimization, build tooling...it quickly becomes overwhelming, especially when the company isn't thoughtful enough to provide a list of specific things my work will be graded on.
Asking candidates to do several hours of example work can shut valuable people out of your hiring pool--people who don't have the spare time, people who are very junior, even people who are too senior (if they can get other offers easily, why should they spend an entire day applying for one?). I myself have declined to interview for a role or two because the process was too much work.
A better (and more scientifically-proven) approach to interviewing would be a brief face-to-face followed by an hour of pair programming with an actual employee doing actual day-to-day work. If the experience is positive, you have reason to believe the candidate will be a very good fit.
What if there are 100 interviewees? How do we quick sort them out without being stressed?
I don't know of a "quick" way to pick the most qualified candidates from a set of 100. Every study I've seen indicates that a resume review or phone screen is about as good as a random number generator.
We can use the 37% rule as suggested by the Optimal Stopping algorithm, I suppose this is very similar to the Secretary problem. So, in a pool of 100 applicants, talk to the first 37 people, stop there, and choose among the 37. This is the first chapter of "Algorithms to Live by" (B. Christian and T. Griffiths)
I have that book but did not complete read yet. Looks like I need to give it a shot. :)
Thanks for pointing that out.
Nice idea! Pair programming is something I love, too! :)
Pair programming sounds like a great idea.
I'm always inspired by the "2nd interview" quiz I was given for an entry-level job that was going to require putting data from spreadsheets into Mailchimp-like and Microsoft Word Mail Merge documents:
I was given a 3-column, 2-record spreadsheet. First & last name, plus M or F.
I was told that I had 15 minutes of quiet time with a computer, open internet, to edit a letter in Microsoft Word so that, when merged, would greet the person as "Dear [Mr./Ms.] so-and-so."
I've always been inspired by that exercise. Nothing about it that you can agonize over whether you're doing it "nicely enough" -- pure "testing output" answer. Short timeframe.
When I interviewed for a more senior position with a company that ate or starved based on the quality of its estimates (consultants), they asked me to tell them how I'd estimate the number of pennies that would fit in the room they were in. I kind of bombed the question (never been good at candy jars), but I thought it was a great "don't agonize over this ... we just want to get some quick idea of whether you're completely untrainable, in the wide band that is normal, or frighteningly off-the-charts fast" type of skill test.
But pair programming sounds like a good idea when more time and effort is necessary.
I like the idea of pair programming but even that can be stressing for even a senior developer.
I like the original article outline, I just wish that the candidate is told before hand what is he graded on instead of just guessing where to spend more of his/her time.
I like the idea of pairing!