Ask HN: My First Interview as the Interviewer | Hacker News Reader

Ask HN: My First Interview as the Interviewer

5 pointsfny16 comments

After many "fun" interviewee experiences, the tables have turned. Not only am I the interviewer: I'm also crafting the process. After contemplating my gripes from past interviews, creating a do-at-your-own-pace code project for candidates to complete just felt right. I'm also doing resume-blind reviews, which has proven assumption shattering. Now for the questions:

- Have any of you had failures/success with a similar approach?

- What are the risks of this approach? Any horror stories?

- What are the best next steps to take with candidates? Is there any value to live coding?

- Do you think the project is too much? (https://github.com/AthletesResearchInstitute/warmup) I worry that it's a bit long.

- What's a reasonable time frame to decide on a candidate after they've submitted a project?

- Any general advice for a first timer?

View on HN

> Any general advice for a first timer?

1) Build a scorecard. Be clear on what it is that you need/want this person to do the next 12-36 months.

2) Basic screening criteria- Can they do the job? Will they do job? Can you live with them?

Know that there is a wooing aspect to this process. The candidate is also checking you and your company out for potential fit. It's likely they are talking to other employers. Pay close attention to their interests. (BTW, Do read their resume & bio beforehand). You might imagine these people as your peers, quite possibly even smarter and more capable than you. Show professional courtesy. If your market is hyper-competitive, same day decision cycles are often the norm.

Honestly, there have been amazing candidates that I would have probably written off had I seen their resumes alone, so looking at the code first affords the chance to judge them based on merit before being biased by the glitz and glam on a resume. I highly recommend this approach.

Right -- Don't judge a book by it's cover. Turns out most people are lousy resume writers. But often there's a subtle sign to dig deeper. You can find those hidden diamonds during a quick 15-30 minute Skype/Phone screen.

I did a code project as a test once. Mostly out of desperation to find a job quickly. And it taught me to refuse and ignore any work-at-home tests, no matter what they are. Either you look me in the eye and we talk like men about software development. Or you play alone with your tests and quizzes until you find someone desperate enough to care.

Why I don't do code tests:

- Artificial problems with artificial constraints. I have to understand some weird context you dreamed up and figure out a solution that matches your expectations. Give me real world problems. I don't work in la la land.

- Solving your test takes at least a couple of hours. I can send three more resumes in that time. Or I can start hacking together a side project to compete with your company. I don't waste my time and neither should you.

- Skewed expectations. Your test is prepared in advance. And because you already know the solution, it seems easy. But it's not. Want a real test? Let's try one you haven't seen before side by side. We'll see then if I'm good and if you are as competent as you think you are. But if I figure it out before you do, I expect a salary higher than yours. Not so fun anymore, is it.

- Skilled people don't need tests to determine skill. They assume it's there and look for potential problems. If I built at least one side-project and you can see it, don't treat me like someone that can't code. If I have 7 years experience, don't test my coding skills like I'm a graduate. Because the 3-5 guys that hired me before you did that already. And they found me good enough to hire.

Show respect to your candidates. Treat them like they are as good as they claim, and look for discrepancies subtly. Don't assume everyone is an incompetent liar. And definitely don't test the living shit out of them just to prove yourself right or wrong.

I agree with you that it would be insulting to pass this on to an industry veteran, and I wouldn't send this to someone who had that kind of resume. A lot of the candidates we've had so far have only been coding for a few years, so I think it's a fair ask, especially from people who don't have a portfolio at all.

I really like your example project. It's good that you go into detail about some of the calculations, which could trick people up otherwise.

As for the interview, just try to be relaxed and friendly to the interviewee--you want them to fail on their own merits, not because they got stressed out or anxious.

Your project is a very strong filter, both positively and negatively:

1. it will select coders who are very familiar with that exact same stack, and find your test trivial (good)

2. it will also select bad coders desperate for a job, who will google to death to eventually come to a solution, even though you would never hire those people (bad)

3. it eliminates good coders who have better things to do than fiddle with installing a different stack, etc. (bad)

Overall, as long as you get enough people from the first category, you win. If it turns out that you are having problems convincing people to take your test, think about category 3 again...

As a quest for the best fit, that was the intent: we need someone who can hit the ground running. I figured we could always try broader interview method if this didn't work out.

Do you think the project is too much?

I think "fix whatever you think is wrong with the code" makes it so because it moves it out of the realm of objective answers and into open-ended apple polishing. It also has the "interview smell" of a game of 'gotcha': a candidate may worry that if they miss some hidden trick, they automatically fail.

But what you [hopefully?] want is people who make changes based on evidence. People who refactor based on profiling or muddy code not because a yak has five o'clock shadow.

Good luck.

Very true. I'm going to remove that line.

'Anything else would you change and if so why?' would make a good interview question.

Does the sample project have comprehensive test coverage already? My Rails foo is...well it's not foo...but I don't see much in the way of unit or integration tests.

If I am correct, there are two problems. One is that the problem is more time consuming than it should be. The second is that skipping tests for a Rails project is contrary to convention. That probably looks like a red flag to some of the class of people you hope to attract.

Nope. I thought about it, but I felt that writing a spec would impose a design, so it's up to the candidate to add tests if they choose. I actually didn't expect anyone to do that, but some (to my surprise) did.

Having some design constraints would provide more standardization. It would also provide interview questions.

This doesn't mention a time estimate anywhere. As an interview candidate it might be nice to have an idea of how much time I'm committing to with this project. Even if it is a wide range.

I had a time range in an earlier draft and dropped it once I realized how skewed my perception was as the author. A broad of a time range didn't seem very useful either.

Reply on news.ycombinator.com