Nothing beats a referral from someone you've worked with before, endorsing someone else they've worked with as well. Beware of the "they're a mate of a mate" referral, you want I've worked with this person and would work with them again.

Let me explain this with a story.

10-12 years ago, the international cricket council picked the best players from around the world and formed a team called the World XI to play against the world champions, Australia. Mind you every player in the World XI was a legend. Now, you have all these great players playing together and you would assume that they would thrash Australia. Instead, the World XI lost pretty badly.

What's the moral of the story here? You don't pick the best people and expect to win, instead you pick a group of people (if they're strong from an aptitude perspective, even better, but I think you can always establish a bare minimum threshold and hire only above the threshold) who can all gel well together and establish a brotherhood of sorts, so to speak. Never hire for aptitude, but for attitude. The former can be learnt.

You ideally need a smart guy who knows the best practices already in the team and that's usually the CEO/CTO/VP-of-Engg. and the new guys can pick up the tricks from the smart guy.

How to know if a guy is going to be a good hire, that's the crux of the question here. A take home assignment can be a good way to judge whether or not the candidate passes the bare minimum threshold of knowledge you would need to work with them. If someone fails at this stage, they're out.

The next step is determining the attitude. Now, this is not going to work when you're just going to have a Skype call or an hour long in-person chat, since anyone can bullshit through that span of time and make you believe that they're someone that they're actually not. You need to work with a person for a week or so, to really evaluate them. If they pass the basic coding rounds, invite them over to your office and work on a side project with them for a week. Pay them for that duration. By the end of the week, you can make a hiring decision.

The best advice that I can offer you is: Check for the culture-fit first. Next, evaluate the ability to ship code. Both are equally important, but if there is no culture fit in the first place it doesn't matter even if you hire the best possible candidate to work for you. I have seen people hire great coders without checking culture-fit, professional etiquette first (myself included) due to several reasons. Even if you need to build your team quickly and you are under pressure, don't work with people who lack basic level of professional courtesy. Take your time and hire the right set of people. As Mark Zuckerberg says,

You should never hire someone to work for you unless you would work for them in an alternate universe.

Regarding the second part, I would say referrals + take home assignment works best for me. If the assignment is a bit challenging, consider making it a paid one (if possible).

I hate whiteboard interviews, but not because I suck at them. My handwriting looks bad, and I often end up telling the solution instead writing it.

I don't mind referrals, but this type of candidate has to go through the same interview process as the others. Otherwise it's plain discrimination.

Now the more interesting ones. Take home exercises. I don't mind them, either, with clear boundaries. If that thing is not done in the company before, it's not an exercise, but work. We can write a separate contract on it and I will happily do it for a fee. If it is done already, and can be proven I'm in, but if my work beats theirs I, again, want payment for my extra work. I'm not greedy, but if we can't handle each other as business partners at the beginning, we won't be able to do it later.

Pair programming. I haven't done this during interviews before, and I think it's really weird. This either removes one dev from their team for a while (if the work we do doesn't have a value; that's definitely a loss to the company), or puts an extra dev, me, on the team for a while (for free, I guess). In this case, the same rules apply as for the take home exercise.

Thankfully I haven't had many bad experiences with tech-industry hiring practices - most of my interviews were more design-focused than tech-focused, so things like whiteboard and pair programming weren't even in the question. I have been asked to complete take home assignments (LOL no!) as well as to demonstrate basic coding ability via screensharing.

I do have an experience I think is the right way to hire people, and from now on I would really recommend this to anybody hiring people in tech:

One of my clients (my best client!) had put a job listing looking for a UX Designer on an online job board, and they had already filled the role before I even contacted them.

Realizing I had still had skills that could be useful to them, and their projects were becoming more successful, they decided to go ahead and speak with me anyway just to make the introduction and see whether or not I might be somebody they might want to call on later if they grew.

Not too long after that, they realized they actually had a much better fit for the first person they talked to than the role where they had put him, so they wanted to give me a try as well.

First we agreed on four hours of paid work that was very clearly defined, they were giving me pieces I needed and defined precisely what they wanted delivered from me, and wanted to see how well I could adapt how I work to fit their project and workflow. They only risked 4 hours of work, I got paid for my time, and they had a chance to decide whether they wanted to work with me again after that.

After the first four hour project, they came back and asked if I was free to take on eight hours of paid work. This was great, working in an 8-hour chunk let me show them what I was capable of a little better, and it felt like I did one complete thing, rather than just one part of one thing. I got paid for the eight hours and they had another opportunity to say goodbye or choose to hire me again if they wanted to.

They moved on to offering five days of paid work (one week), and then a month of paid work. By the time I was finished that, I was more or less as integrated into the team, their systems and tools, and learning their workflow.

It's been years that I've been happily working with this client, and it's still the best hiring experience I've ever had.

What made it so good?

• start small and grow a relationship together
• extend a little trust first, but keep extending trust with each success
• both parties put a small but equal amount of risk on the table
• both parties stand to benefit if the work and relationship is good

So if you're considering hiring somebody, consider what it might look like to ramp up from a small task to full-time work rather than having the interview process be a strong filter to protect a full-time position with 100% trust and risk.

Just my 2¢

I would also say none of the above.

I will not work for free, unless it is for my benefit. For example if it was to fix an issue on an open source project. If I am applying for a job it is to many and do not have time for working on your project. If payed it would be at the Salary I would be getting if the position was landed.

I have anxiety and most of the time solving a problem requires me to sit and think about it with my music on.

Referrals I would say are great but what about people who have been working in a closed network and have not had a chance to make as many network referral opportunities. I feel like you would close out many developers because of this.

Pair programming can be nice but it is just like any group project. If it was pair programming it would be nice if the person to pair with was working with the company and they could give the okay if the person could work there or not. But I would not base it on just one person's opinion. Possibly multiple people to pair with to have many team members input.

I don't see testing someone as a good way of seeing if they can solve a problem. I don't have a time limit to solve problems at work. But I do finish my work quickly because I am not expected to do so. I work for my respect, I work for myself, and lastly I work for my company to gain as much from me as possible. I would like to work with someone with the same ideals as myself. But this is my opinion.

Take home assignments can be a pain for candidates who are in the exploring phase of job hunting. There's no incentive for them to spend hours doing an assignment when they already have a job with plenty of other opportunities. There is a very small edge case in which candidates REALLY want to work at said company and are willing to put in the time.

None of the above.

Now I have your attention

First and foremost; attitude. Everything else is secondary.

Otherwise the process I've chosen is a coding test, so a take home assignment basically. But I don't make the decision based off the test alone. I also look at if they have any contributions, not because I care more about open source or anything, all I want to do is be able to determine how pro-active a candidate is and their level of competency. Previous code examples, as well as the test, aid in this.

Definitely stay away from Whiteboard interviews. That was the old way of doing things, the candidate isn't in an exam hall anymore. So definitely stay away from these.

Pair programming assignments have their place, but as an interview process I'd only do it if they show promise but I was unsure how they would work in a team. But usually this isn't required.

Referrals are useful, and could (I say could because this has never swayed my decision before) aid in the decision process but I try and find/let the candidates code speak for itself.

Final Note:

Each company and therefore each company's needs are different. This means that processes and best practises will always be different. They may be well adopted methods but really, these are all altered in some small way.

Try out different things, if one doesn't give you the information then change it or choose another method :).

The first time you hire someone can be a scary process because you're letting them into the family, your business, so it's difficult. Their needs to be that feeling of trust, from both parties, in order to get the best for/from both candidate and employer.

Hope it helped :)

I would prefer "Take home assignments" and "Pair programming" both. The first one tells you about the programmers' approach to a particular problem whereas the second will test the compatibility with the existing employees.