Ask HN: Small companies, how do hire without Leetcode

4 points by 100-xyz 4 years ago | 5 comments

Hi,

I joined my current 300 people company about 2 months ago. We are trying to hire Software engineers and are using Leetcode type problems as a selection mechanism.

The problem with it, is if a candidate is very good at it she will be getting an offer from some of the larger companies who follow a similar process and there is no way we can compete with them on salary.

Additionally, internal Google research has also found poor correlation between such tests and performance at the job.

So question for HR and hiring managers from smaller companies - what alternative approaches do you use to interview employees?

One option is take home tests. I have taken them while job hunting and wasted numerous hours only to get 'we will not be proceeding' emails or even ghosted. Too many hours wasted.

Any good alternatives?

Thanks.

AnimalMuppet 4 years ago |

We talk to them (phone screen). If we bring them in, we just talk to them for a half hour about what's on their resume and stuff.

Then we give them a code sample, a single function that fits on half a sheet of paper. We ask them what it does. We ask about ways it could break, corner cases. We ask them what they would name the function.

Then we give them a small coding problem. They can solve it in any language they want. It's not as trivial as FizzBuzz, but it's not very complex. It's certainly not leetcode. We watch them think through how to write code that would do what we asked. We aren't really watching for syntax errors, but if the code was full of them it would be a concern.

Then we give them a small design problem, one that's not all that clear-cut. We push them on some of the corner cases of the design, and watch them try to adapt the design to cover them.

Total time: Two hours.

This approach has gotten us a pretty solid, competent team.

100-xyz 4 years ago | |

Thanks. It sounds like a solid plan.

Out of curiosity, how big is your company? How often do you interview? Approx what % of the candidates get an offer?

quantified 4 years ago |

One of the worst projects I participated in was led by a Leetcode master, good at the 30-line algorithm and terrible at code design and service design.

The best process I participated in included, along with some design scenarios, handing a candidate a laptop computer with their usual IDE and a home directory with a readme and a source tree. They’d read the readme and do the work against the code that was present, find and fix a bug and then add a feature. You learn a lot about what they know and how they think. Google and everything available, if they didn’t know what something meant they looked it up. Simulated work very well.

Probably Covid has put this mode on ice, and it cost a bit of effort to set up, but well worth it.

earpwald 4 years ago |

I do interviews at a decent sized company, but our office is really only 15-20 people. Our process is a bit lacking as we generally do 2 rounds of discussions (1 hour or less each) which has a focus on technical and soft-skill questions.

Its an ok process, but I personally would like to change one of the sessions to be an interactive dev... give a codebase ahead of time, nothing crazy and then get them to drive a solution, be the partner and then also work through a bug. Nothing complicated, I want to see their thought process and how they work as a team. Obviously google etc should be available.

In terms of being able to compete with larger companies, thats not always the case. Maybe not in salary, but thats only part of a job. Culture, perks, and the project itself can all be draws to bring in great devs.

I'd add that my worst ever interview was a coding one, similar to what I described, but the difference was that there were 3 people sat opposite me just watching me, no talking, no chat or fun, nothing. Dont be those people!

MattGaiser 4 years ago |

I don't do any hiring, but my company mainly does system design tests. Your technical interview will consist of an hour or so discussing how you would design, say, Stack Overflow.