There's no magic bullet for hiring programmers. But I can share advice on a few techniques that I've seen work, that I've written about here and personally tried out over the years.
Great ideas here. The only suggestion I would make is to replace point 5 ⌠instead of having an âaudition projectâ why not just have a âprobationary periodâ (e.g. 3 months) during which time either the developer or the employer can decide to end it if things donât work out. Its fairly common in development jobs in Australia.
Saying knowing how to program is actually different from actually knowing how to program.
One job that I applied for (and got hired) I was asked to do using a flowchart (this was long long time ago) of determining the day of the week given a specific date.
Once I finished the flowchart they gave it to a programmer who wrote the COBOL program for it and with a few changes it worked!
Lots of good points here. Number 2 is the only one I take issue with. I think there are solid developers (hopefully myself included) that do not have any sort of public portfolio.
I think for every dev contributing to open source projects, working on websites, and spending there time on stack overflow, there are five that work 50 hour weeks for large companies in government, automotive, health care, finance, etc. who donât work on on products that are public and canât show code theyâve written. Itâs also tough when you work on a team of 50-100 in parallel and only pieces (maybe not even entire features) are solely written by you.
As for working on projects outside of work, maybe I just donât possess the proper dose of passion but in my free time I want to spend time with friends, family, and other hobbies - thatâs why itâs free time. But that doesnât mean I donât bring my best during business hours inside the halls of my office.
I think this division in mentality is a core difference between Silicon Valley startups and large corporations. Regardless though, I think youâre other metrics help to solidify a candiate and are excellent suggestions; I wish we exercised more them.
Donât hire anyone that you donât already know, trust, and will fit in to your organization.
Now, how you get to know and trust any potential hire are details that can change depending on the situation. The steps that Jeff outlines above are good if you have had no contact with the applicant before the interview.
Personally, Iâve had good experience hiring grad students who already have some work experience and come recommended by their professor. It definitely helps to have strong connections to local universities, but hiring these kinds of students makes me fairly confident that they are: hard working, smart, experienced but still open-minded, and tend to have a good mindset for the place where I work.
In a similar vein to what TravisVT said about 2, I have concerns about 5. The time commitment alone is going to disqualify a lot of people who are currently employed and most corporates have employment contracts that specifically prohibit doing other work outside of office hours.
There should be a step 0 consisting of an introductory conversation to make sure that both sides know who theyâre dealing with in terms of basic things like the kind of workplace you are, the kind of person youâre looking for and the recruitment process.
Last year I applied for a job through a consultant where all I knew was the name of the company and the content of their marketing website. The first communication I had with them was âdo this code testâ, then the next communication was ânow answer this 5 question examâ. When the consultant told me they wanted me to come in for a âtechnical onlyâ interview, I told him to get lost. It has to be a two way street, these people had sucked hours of my time without even giving me a hint of who they were and what they were offering. I got the impression they had no respect for what I might be looking for.
At another company, the manager contacted me directly and told me about what their recruiting process involved (e.g. how many code tests, interviews etcâŚ) and the kind of working environment they offered. In the course of this conversation, it became apparent that the workplace culture was one of intense social engagement where the employees lives were centred around the job. While I could see the appeal of that kind of job for unattached people, I didnât think it would be great for me as a father of young kids. I was able to self-select out of the process early rather than waste everyoneâs time doing code tests etcâŚ
Step 0: Introduce yourself, talk about your goals and outline the process.
Great post. I agree that companies should do all of thisâŚBut, itâs very one-sided. Granted, the best hires are ones who, like you said in 3, are already part of your community and want to work for you. Most of the time, though, an amazing programmer will be amazing for many companies. You also have to tell them what your company has to offer. Especially in this market, the interview process shouldnât be about vetting the programmer, but figuring out if thereâs a fit, for both sides.
I feel youâll miss out on a lot of really good programmers if you approach interviews as a way to see if you want them to work for you. Interviews should be about figuring out if you can work together, and that goes both ways. In a sense, both sides should be interviewing each other.
Great ideas here, though I also disagree with point 5. There are a lot of people who a) want to be employees not contractors and/or b) are currently employed (and are âcontentâ if not âhappyâ at their current job - these are usually the most desirable hires, and requiring an âauditionâ contracting period means youâll miss out on great people.
Also, Iâve used collabedit.com (I have no affiliation with them) for phone screens and found it very useful. I like the idea of codility and Interview Zen, but Iâd worry about the interview questions being posted at various sites online (that I wonât mention here to avoid giving them pagerank ).
Much like some of the commenters above, I think points 2 just eliminates 80% of the valuable workforce. And having something else to do than programming during your spare time is not the only reason, contractual agreements sometime mean everything you code during your spare time must be first submitted to your company before going public.
About point 1, in 20 years I never meet anyone who was not able to code during a programmer interview, but I guess we have less script kiddies in Europe (or, may be, better engineering schools).
To me the network is the most valuable thing, however, the worst programmers I ever met had been recruited because someone knew them, so this does not dismiss formal interviews with someone who doesnât know the guy.
I was with you until point 6. If I was asked to do that I would politely decline and carry on looking elsewhere for work. It seems more like a talent show audition than anything useful for me (the interviewee). I can see how it may be of value to the employer, plus the unwritten benefit of the occasional cringeworthy and uncomfortable presentation. Thatâs one of the reasons why shows like Americaâs got Talent are so popular after all right?
Iâd much rather be put on the spot and have my area of expertise tested in a Q&A format so I canât just cherry-pick my strong points.
Maybe itâs because I am more introverted, although still fine communicating and getting along with people. I wouldnât have applied to a role that needed me to present as part of the job in the first place so I certainly wouldnât expect it as part of an interview process.
Anyway, Iâd be happy with any company doing the first 5 suggestions if I applied there.
Moneyball is an excellent allegory for software developers.
Can they code. Thatâs really all that matters. The only way to know if they can code, put them in front of a whiteboard and make them code. Everything else doesnât really matter as much to me.
For those that donât have time/desire to work on projects outside of their normal day job, understand that you are competing with people who are equally as smart, who put in just as much time at the office, but also work on projects outside of work.
The problem with the audition project is time.
If itâs something that can be done over a weekend then maybe this is fine (for most people at least).
But if you need someone to take a week or two away from work then your relying on them being able to get that time off from their current job or to quite their current job just on the risk of getting hired.
This is going to rule out many experienced candidates who may have family commitments and will want to use their limited holiday time to actually take their family on holiday.
I would struggle a little with 2 because I can only infrequently publish my code. However I have done a couple of presentations to user groups that are online, and I have a collection of StackOverflow accounts (one per employer). Itâs not a completely unreasonable requirement, but it does suggest that youâre hiring at the top of the market. Whether thatâs a top 5% graduate or a top 5% senior software engineer, it means youâre going to have to pay a premium to get those people interested.
Point 6 would wipe out pretty much every non-Merkin programmer I know. Itâs a very USA-centric thing, and possibly even US-startup specific. And I do wonder if youâre selecting for people who are likely to quit on short notice because their out-of-hours project got funded.
I think this kind of process for interviews is really prevalent in the US, especially for big companies.
And when I read here and there how easy it is to get fired there, I donât understand why you put such a barrier for the entry!
As a programmer, Iâd feel insulted if I had to pass through 5 layers of requests and experiments until seeing someone face to face. Iâd let go after the 2nd or third.
If a company is making his future employees pass through hell just to have a chance of going in, thanks but no thanks. Thatâs not the company I want to work for.
My 2 last job interviews (for 2 small companies in France) went in 2 shots: one on the phone, then face to face, where I was faced with 1 or 2 âprogrammingâ questions, then ~1 hour of discussions about what the job was, what I did before, and how comfortable I was feeling doing this job.
Now, these were (are) small companies, where there was no HR that was PAID to design lengthy interview processes. I directly talked to the guys Iâd be working with, and I donât think they made a mistake taking me. Iâm still working in the 2nd one, as an happy programmer.
Thereâs a question of trust in an employer/employee relation. I had a 3 month trial after both my interviews, and I was absolutely ok with that. This period is made for that: if I didnât fit, it would show in the first 3 months and Iâd be thanked. No need for a 2 month recruiting process!
I think itâs important to respect the candidates time. Paying a candidate for a project is the right thing to do.
Iâve seen application process where the candidate is asked to write a whole app. They said it should only take 2 hours, but from experience I know it would have taken at least a day to do it correctly. I strongly doubt that they would have checked the code other than compile and run. Due to this I didnât even apply.
Just give person 4 problems from projecteuler.net or similar site starting from really easy to any difficulty. Leave candidate for X hours and come back to check progress.
âportfolioâ? Nice if you have one. Many donât.
âaudition projectâ? I donât have free time for that.
â15 minute presentationâ? As somebody mentioned - talent shows are not for me.