
Technical Interviews aren't merely technical - nicolodavis
https://nicolodavis.com/blog/interviewing/
======
TrackerFF
I honestly enjoy take-home assignments more, because they (well, at least the
proper ones) mitigate many of the risks that are listed in the post.

My experience is that the interviewer can pretty much make or break a
technical interview.

I've had interviewers that used them in like they should (get a feel how you
solve problems and think, how you communicate, etc.), and I've had garbage
interviewers that read a script, with problems they themselves didn't
understand.

I know the view on take-home assignments is very polarized, but you know what?
The net time spent is usually far, far less than the prepping game for
technical interviews. You see people grinding leetcode for hundreds of hours,
memorizing problems and solutions, trying to get every edge-case they can -
just in case the interviewer throws something obscure at them.

At least with assignments you get a well-defined problem, where you get time
to think and reflect, and can work/learn enough to have a meaningful
discussion.

~~~
nicolodavis
> My experience is that the interviewer can pretty much make or break a
> technical interview

Yep, that's exactly what I've tried to communicate here.

I like the idea of take home assignments as well. Maybe the industry will get
to a state where these can be done completely remotely (and even graded
automatically) in order to determine whom to bring onsite, where you just have
a general discussion.

------
rvz
I agree with the points outlined here as both a former candidate and as an
interviewer. They are not really technical but the questions I ask to
candidates are relevant to the job and I always look for honest individuals
that have substance in their experience.

In my experience, as a former candidate, I have met bad interviewers who
deliberately focus too much on syntax and like nitpicking candidates knowledge
on libraries while they attempt to implement or solve a problem for which they
openly admit afterwards that they do not use and go far to secretly record
candidates struggling. I even met some 'engineers' claimimg that they are
senior in C++ and I brought up LLVM in the conversation and they had no clue
on what that was. Likewise for 'JavaScript experts' having no idea about
JavaScript engines such as V8, JavaScriptCore and SpiderMonkey.

I don't usually go technical in these interviews but only when asked and
before that, I research their open-source contributions to ask relevant
questions. Unfortunately, Most of these engineers had little to no open-source
contributions or have only private (Obviously work related) which is very
unfortunate.

As an interviewer, I have ultimately done away with take-home projects unless
candidates are expecting something out of it (I used to pay all second stage
candidates for their projects) otherwise it becomes a waste of their time if
they are not considered.

Instead, I ask them about relevant open-source contributions to significant
projects which is more or less a straight-forward free pass to a on-site
interview and at the same time already eliminates beginner/intermediate level
candidates. Which I go slightly technical on those patches as if I was
conducting a code review. If the candidate is honest and everything matches
up, I'll hire them on the spot and that is it. If I find that the candidate is
suspiciously dishonest, That is the only time I will give a problem to solve
without interrogating them.

By doing this I don't even need to waste money on Hackerrank/Leetcode/Codility
tests which are useless in finding competent software engineers.

