So... imagine you are starting your dream company with the smartest guys in the coolest office ever.... :) And you are looking for a software devel...
For further actions, you may consider blocking this person and/or reporting abuse
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 like the idea of pairing!
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.
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.
What if there are 100 interviewees? How do we quick sort them out without being stressed?
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.
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.
Nice idea! Pair programming is something I love, too! :)
I like your list a lot. One thing I'd add: A step 0 that will disqualify me right away if I'm not the right fit. Nothing worse than being dragged through a process that won't end in anything.
Yes... I agree, a quick return statement is absolutely needed in the beginning! :)
Hehe definitely needs a guard clause
On a similar note: responses from employers when they've decided to go with another candidate is a huge plus!
Hey there. My two cents:
For junior devs I'd only test their motivation and if they align with company culture. Talk about programming, ask questions (fundamentals) and look how he/she reacts to them especially when they don't know the answers. You'll see a pattern right there.
As for experienced ones - imho, it is very important to ask why they're changing jobs, also, find out if the candidate still has the passion for programming (doesn't mean he/she still does). Basically, test for motivation to learn/improve themselves. Then test for culture and only then give 15 to 45 mins of coding. You don't need these stupid whiteboards, meaningless hackaday project sessions after coding let seniors talk to them, talk about a project you're working on, see if the candidate asks any questions. This last one is very important. It not only shows that the candidate is interested but also shows his experience.
These are very broad strokes but the main idea is that, in my opinion, testing for motivation, culture and character (discipline, no bullshit attitude, curiosity, etc) will yield better colleagues than them passing some algorithm test. As far as coding skills go - not everyone is equal and everyone has their style, I would definitely leave quite some space for improvement (this is what code review is for actually) if I see the fire in candidate's eyes.
And that's it folks. Cheers! :)
I once interviewed a coder for an entry-level data entry position (he needed a job and had limited legal options) who, when I explained the bad data he'd been cleaning up, asked me what approaches I'd looked into for preventing the bad data.
I didn't end up hiring him, but did get a chance to brag on him to my boss when we ran into him over lunch, and my boss got him a way better job that's led to him being one of the most valuable new employees at my workplace.
Questions to other coders most definitely do show quality of thinking!
Sounds like they will spend a lot of time, and that's not good if you are looking for a job. In the past, I hired developers and I just make an interview to know what are their skills, how they like to work and what are their expectations about the job, then I give them 15 minutes to solve a riddle to test if they have problem solving skills. If they convince me, I send them a test, otherwise later by a phone call I let them know that unfortunately they are not what I'm looking for.
In the test I prepare a repo with the setup of a project so they don't need to worry about that and give them a list of three simple things I want them to solve plus 5 extra things of more complexity as a challenge
To pass the test they need to do only the first 3 simple things but if they want to earn extra points they can solve the other 5 things. I give them 2 days to complete the test, the test is not so complicated, the average can complete it (the extra points included) in 2 hours or less.
Then I select the best solutions, again the candidates that didn't fulfill my expectations are disqualified. For the ones I selected, I schedule a code review via Skype, Hangouts or whatever they prefer, I ask questions about why they chose that solution and how it works, this is the last step, with the answers they give me I choose who to hire.
Sorry, maybe I will be unpopular, but I wouldn't like your process:
First problem is it would take too long. I don't have long hours for one company if I'm searching a job. And the ability to refactoring etc can be figured out by just checking any old code written by the candidate. I think a technical discussion gives enough information to the decision. But I like the idea, that the team can decide.
I'd forego projects in favor of reference checks done by your more skilled dev teammates.
Former teammates can tell other devs if someone can code, and they'd also send up any warning flags.
For hiring juniors, I've had luck hiring for aptitude rather than skill.
That said, if you want projects to work in that framework, I'd make them last in the process as freelance contract-to-hire projects.
This way you get their best work in a resource-constrained environment and you overcome some of the other commenters good points about folks who don't have the time/energy/money to commit to a large project. As a bonus, you solve a problem for your team!
From past experiences it s very important to design your interview to exactly suit u r role requirement. There is no point in having a very hard interview, hiring a super dev and making him do bau work on legacy codebase.
The reason I'm not a fan of that process is because how long it would take. I'm not a fan of when companies think the interview process has to be crazy long to vet people. I feel like you should be able to figure that out with 2 interviews in my mind.
Plus I feel the projects add soo much stress that you don't feel every day while working on the job. It also pretty much takes away anyone that is currently employed. Someone who works full-time already with a family at home should not be asked to take time away from their family to get a job. In my mind that process is asking for that. There are A LOT of very good programmers who don't take their work home with them nor should they be expected.
I am on board with the pair programming. Let them work with the team. See how they get along with the team. Maybe even a team lunch. You can figure out a lot about someone through that. Simulate how they would work everyday.
This sounds amazing! Are you hiring!? Haha