
Ask HN: My First Interview as the Interviewer - fny
After many &quot;fun&quot; interviewee experiences, the tables have turned. Not only am I the interviewer: I&#x27;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&#x27;m also doing resume-blind reviews, which has proven assumption shattering. Now for the questions:<p>- Have any of you had failures&#x2F;success with a similar approach?<p>- What are the risks of this approach? Any horror stories?<p>- What are the best next steps to take with candidates? Is there any value to live coding?<p>- Do you think the project is too much? (https:&#x2F;&#x2F;github.com&#x2F;AthletesResearchInstitute&#x2F;warmup) I worry that it&#x27;s a bit long.<p>- What&#x27;s a reasonable time frame to decide on a candidate after they&#x27;ve submitted a project?<p>- Any general advice for a first timer?
======
JSeymourATL
> 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.

~~~
fny
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.

~~~
JSeymourATL
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.

------
mrcold
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.

~~~
fny
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.

------
angersock
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.

------
alain94040
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...

~~~
fny
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.

------
brudgers
_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.

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

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

------
brudgers
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.

~~~
fny
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.

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

------
natdempk
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.

~~~
fny
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.

