[erichurkman]

Having a friendly interview process, to us, is a competitive advantage. As is not requiring multiple onsite interviews, too many phone calls, and even making the onsite interview not take all day (we try to wrap up by 1pm unless a candidate is shadowing an engineer for a day, which we typically do for more senior hires). Having a concise interview process often lets us get offers out the door while candidates are still navigating 'Round 3' and 'Coffee with a lead engineer' and other nonsense with the bigger companies.

[retreatguru]

I wanted to use and like hackerrank as a hiring tool but found the questions had nothing to do with what devs do every day - mainly solving business problems in elegant ways. I even contacted them and told them so but did not get much response.

I treat interviews more like going out for coffee and often do just that. I like to understand what people are passionate about both in tech and personally.

[initram]

Do you find that you can determine a person's technical skills from such a discussion? I've found that I'm not very good at determining such things from just talking. Often I talk with people who sound like they know what they're doing, only to find out later that they don't.

As for coffee - do you ask your interviewees if they want that? I don't drink coffee and generally hate coffee shops because the only other options are sugar and fat-filled starch bombs like scones and cakes, and other drinks I don't enjoy like tea. I usually eat a decent meal before interviews so I don't end up unable to think due to hunger during the technical part.

That said, I also find puzzles and unrealistic tests to be annoying. One thing I've done for the technical side is to pull questions from codereview.stackexchange.com and ask the candidate to review them. (I generally print it out and ask them to do it on paper in front of me, so they aren't looking at the existing answers.) This gives me a better idea of their technical skills without the "gotcha" feeling of whiteboards. It also normalizes for different background (e.g. I'm used to Xcode, but this interview had me working in Eclipse and I couldn't find anything!).

[retreatguru]

We discover people's technical skills with a take-home question. We took a real business problem that we already solved and get them to solve it. They don't write any code, but just give an explanation as to how they would go about solving it and why. There is a little bit about database normalization in it too. It's incredible how well this simple 'test' works in seeing how people think.

Often the interviews are over Skype, but we keep things pretty causal, and give the interviewee lots of opportunity to ask questions about the company and culture.

Cultural fit is very important to us. We live in Nelson, BC, small town Canada - very far away from Silicon Valley. Our team is very friendly and care for each other. We want to ensure any new hires contribute to that positive vibe.

[erichurkman]

To your latter point, any time we do technical exercises, we _always_ let the interviewee use their own IDE. Nowadays it's easy because most people have laptops, though we do offer to set one up if they do not have a laptop to bring.

Their choice of toolsets and setup can also be a really interesting discussion topic. More than once during an interview, someone has shown me something really cool that I adopted (new key binding, a new tool, a particular way someone had their terminals split-paned, etc).

[huac]

I've done a couple interviews over screenshare, where I setup my own IDE, and liked that more than the typical Google doc or CoderPad

[dmoy]

What if the candidate doesn't have a machine of their own (company owned)?

[erichurkman]

We have a laptop they can use and make the offer that they can use it. It hasn't happened often, but I could easily see it being set up with a few different environments already. (Adding that to my todo list.)

[greenyoda]

"I wanted to use and like hackerrank as a hiring tool but found the questions had nothing to do with what devs do every day"

But then...

"I like to understand what people are passionate about both in tech and personally."

OK, so what do people's personal passions have to do with what devs do every day? Are you really going to hire someone based on whether they prefer playing music, or bicycling, or spending time with their kids?

Also, since we have a limited amount of time for the interview, I'd much prefer that you didn't waste time asking me personal questions that are irrelevant to the job requirements (or telling me personal things about yourself). I'd rather have time to ask you questions about the job and the company.

[BJanecke]

Hiring someone purely on technical skill is myopic, I'm not going to blabber on about "Cultural Fit" but in small to medium teams hiring someone with vastly opposing viewpoints can be detrimental or it could be greatly beneficial.

How could you expect to measure the social impact of a new member on your team when you look at them as a technical robot and not a human being.

[falcolas]

> I even contacted them and told them so but did not get much response.

Probably because it's much easier to rank a algorithmic solution. The question of "does your code compute the correct answer in the allocated compute time" provides a nice clear answer. Solving business problems in elegant ways, on the other hand, takes a human to judge, and the results are not always clear.

The difference in the difficulty grading the two is exactly why the former is so popular as an interview technique (requires low effort to get a binary answer), and the latter is better at actually judging an applicant (reflects the human behind the test).

[tome]

> I wanted to use and like hackerrank as a hiring tool but found the questions had nothing to do with what devs do every day

Surely you can add your own questions.