

How to impress me in an interview - thebigkick
https://medium.com/@kevincennis/how-to-impress-me-in-an-interview-4fc00e96413

======
Jemaclus
I somewhat disagree with the premise of this post. I don't think someone
walking in and being able to code at whatever level I'm expecting them to do
is impressive. That's exactly what you should expect them to do before they
even walk through the door! If they can't do these things, you shouldn't even
be talking to them at all!

Furthermore, I believe that by the time you bring someone into your office for
an onsite interview, you should have already concluded technical tests. You
should have had an initial phone screen, a tech call, and/or a code challenge.
The candidate should have passed all of those with flying colors. If not, then
you don't bring them into the office.

Once you bring them into your office, your goal should be threefold: quickly
validating the results of your technical challenges, determining company fit,
and _letting them learn about you_. If you cannot quickly validate the results
of your technical challenges, then you should re-evaluate your tech screens
and/or code challenges that you send the candidates before they show up. Maybe
you need to do something a la TripleByte's quiz. Maybe you need to ask more
rigorous questions during the tech call. Maybe you need to impose constraints
on the code challenge.

If you're getting people that don't know the difference between .call() and
.apply() or how to use prototypal inheritance, then your top-of-the-funnel
filtering techniques aren't doing their job. Re-evaluate the code challenges
and tech screens!

The second part of the interview is "do I want to work with this person? Do I
want to sit next to them for the next year? How much hand-holding will I have
to do and is that amount acceptable? Do they seem trustworthy or particularly
experienced in something we need?" This is partly personality, but mostly
communication skills, attitude, and professionalism.

The third part is that interviews are a two way street. The candidate is there
to interview you just as much as you are there to interview them! Part of your
job as the interviewer is not only to assess their qualifications, but to
convince them that accepting your potential offer is the best thing they could
do. Always, always, always open up with an explanation of who you are and why
you're the one interviewing them, as well as how the interview process will
work and what you expect from them. Always, always, always leave 10 minutes
(or more!) at the end of the session to let them ask questions.

If I walk into your onsite interview, and all you want to do is discover
whether I know how to curry or pass functions as arguments or the difference
between .apply() and .call(), then you're wasting both of our time. (Not that
you don't need to know those things -- but there are easier ways to determine
those, and you could do that before I even walk in the door.)

Your time is valuable. Consider how much code you could write in an hour.
That's how much code didn't get written because you wanted to ask me, in
person, whether I know what "this" means or what closures are. You could have
verified that before I even walked in the door.

Instead, you should use your time as an interviewer wisely by asking only
questions you cannot verify before they show up. As a candidate, I don't want
to waste your time and I don't want my time to be wasted. As an interviewer, I
don't want to interview candidates that are unqualified and therefore waste my
time and the candidate's time.

~~~
arclyte
You make some good points about only actually interviewing competent
developers and not wasting anyone's time. But in my experience, the take home
assignments or coding challenges can often take hours to complete if they are
to weed out copy-pasta or dumb luck. For example - "Create a basic CRUD app,
with testing, in a configured environment" or some such takes time for me to
set up, write, test, and package for delivery.

For me as an interviewee, to have to devote hours of my time doing work for
free just to prove that I know how to code, all based on a short phone call,
is just as crazy. How do I know your company is one I want to work for? How do
I know you're offering the salary and benefits I need? We haven't gotten to
that part of the conversation yet and I'm already putting in real hours of
work - especially if I have multiple interviewers that ask me to complete code
challenges.

It's a catch-22 really. If you have no hurdles, you hire people who don't know
what they're doing. If you put too many hurdles, you scare off the folks who
don't want to waste hours of their time proving they know the basics. For an
interviewer, it's best to get this stuff right up front so you can more
effectively screen, but for the interviewee it'd be best that this comes at
the end of the process when they know they actually want the job.

All in all, I think this works better for junior level positions because
that's where you want to know where folks are at, but hiring senior level
people with years of experience, it just gets insulting to have to jump
through hoops at every single interview. Of course, I'm a bit burnt out on
interviews at the moment, so take that for what it's worth ;)

