
On the unreasonable reality of “junior” developer interviews - ingve
https://samphippen.com/on-the-unreasonable-reality-of-junior-developer-interviews/
======
innocentoldguy
I've been through many, many tech interviews during my 25-year career, and not
one of them has been objective. I have always been hired based on whatever
opinion the interviewer formed about me within the first minute of meeting me.
The rest of each interview has always been a drawn-out, cumbersome attempt for
them to justify their initial, subjective decision.

In my experience and opinion, software engineers are some of the world's most
incompetent buffoons at interviewing; myself included.

~~~
meric
There has been times when we've made a subjective decision to hire someone
based on a first minute impression, and later changed our minds due to the
interviews when we found out the candidate was not nearly as technically
competent has we had hoped for the position.

~~~
collyw
Based on what out of interest? A 3 hour coding challenge? Whiteboard
excersice?

~~~
meric
Asking for an example of good code the programmer had written previously and
bringing it in and asking them to explain what they thought was good about it.
Sometimes this can tell you the programmer is being too clever / not clever
enough. E.g. when they override javascript prototype classes for the sake of
succinctness, or going too far the other way when they repeat some boilerplate
code excessively. You could ask them questions about why they did things that
way, and see if they can provide a good reason, or they just didn't think
deeply about the code they picked to show us.

~~~
dev360
I prefer this style of interview to the 'quiz' oriented style which revolve
around the interviewers ego 90% of the time.

------
ivraatiems
As somebody who just dealt with about a dozen rounds of these kinds of
interviews as part of a job search, this post was extremely close to home.
While I never got a question nearly that intractable, I did get a lot of
questions that toed the line between "this is a useful algorithmic test" and
"this is about minutiae and what you remember."

One thing I've found interesting was examining the various ways different
companies handle the tech screening process. I've had everything from no real
tech screen to back to back algorithm-based interviews. It's definitely
possible to suss out what a company cares about from the sorts of questions
they asked.

The biggest issue for me was that I never really was unable to get the right
answer, but that wasn't always what the interviewers were looking for. I got
told at least once that they expected me to simply be faster. I wasn't sure
how to take that.

Looking back, all but one of the several companies from whom I received job
offers had processes requiring coding-intensive tech screens that placed only
minimal restrictions on the time one could take. The job I took was actually
with the company that had the MOST intensive process (though that wasn't
really a factor in my decision).

I don't think I'm incapable of doing the jobs at the algorithmic-questions
companies who rejected me, any more than I think myself incapable of the job I
was hired for. In fact, the work at each organization was quite similar. So,
am I missing something, or are they, or both?

~~~
soham
Interviews, by definition, are not standardized tests. The more you think like
they are standardized tests that should be done objectively, the more useless
agony you're taking on yourself. It's never going to happen. It can't.

On the spectrum of human interactions, interviews are closer to a date, than
they are to an exam. If you make a connection with your interviewer during
that hour, (via whatever topic it is), they will go at lengths to hire you.
Yes, you're expected to solve the given technical problem reasonably well, but
beyond that, you have to leave it to "chance" and "pray" that you get a good
panel.

That's how it SHOULD also work. Because YOU are also interviewing them at the
same time. If you don't get inspired with the interviewers, you should also
not join that company. i.e. you're also looking for a human connection.

I train for technical interviews for a living, at our exclusive bootcamp for
interview prep: [http://InterviewKickstart.com](http://InterviewKickstart.com)
. Our entire theory is based on this premise i.e. that interviews are not a
standardized exam; they cannot be gamed. All you can do is practice technical
stuff really really well. In the end, who gets hired is not in your hands. And
that's okay.

------
joeld42
If you're going to ask a whiteboard question, solve it yourself (on paper,
without references). If you can't solve it in a few minutes, it's probably not
a good question. I do this with every whiteboard question I ask.

I ask these types of questions not because I really care if an interviewee can
reverse a linked list or whatever, but to gauge their familiarity with the
language. If their resume claims several large projects, and they claim to
work with a language every day, but they struggle with the basic syntax,
something is off. And that happens all the time.

------
doug1001
maybe the most insightful recommendation w/r/t the developer interview process
i've read (approx. 3/4 through the post):

"A technical discussion makes a much better place to start an interview. One
isn’t under pressure to perform. Instead, one gets the opportunity to talk,
correct previous mistakes, listen, react, and, generally learn about the
person. Communication is the most important thing we do as developers. All
computer problems are people problems. Let’s interview like that’s the case.
One walks out of a technical discussion usually feeling pretty good.
Interviewees like to spout reckons. Interviewers like to hear and react to
those reckons. We get to work out if we can work together based on how
reasonable our reactions are, whether we’re willing to give ground where we’re
wrong, and, generally demonstrate how we like to work."

------
memracom
I like the fact that this writer ends up discussing how all interviews are
really people interviews. Finding out in the interview whether or not a
candidate can fit into the team is probably more valuable than finding out
their level of technical skill.

Also, the blind focus on coding interviews forgets the hiring market. So what
if a candidate fumbles in front of the whiteboard. When there are 10 jobs
chasing every candidate, you would be better off hiring people who barely
demonstrate the technical skill you need, but who fit in the team AND
DEMONSTRATE A STRONG DESIRE TO WORK WITH YOU.

Employees who have a strong desire to succeed, will learn what is needed for
your technical environment, and won't run away for a higher salary after 6
months.

People don't really consider the downsides of the whiteboard interview. They
often fail miserably on the criteria of dialogue and end up being a
candidate's monologue in a room full of silent observers. I've gone through
such interviews in which only one of the observers ever spoke, and mostly just
hints/reminders about the coding problem. At the end, I knew nothing about the
company's technical environment or the way that the team worked. And they knew
little to nothing about me and my technical skill.

People view whiteboard exercises as a proxy for getting to know the candidate,
and in my opinion, this is far from reality.

I still see some value in a test about the same level of complexity as
FizzBuzz, but only as an opener for an actual dialogue with the candidate
about what they are capable of.

I think the fascination with whiteboard tests comes from the influx of CS
types used to greenfield development into the flood of startup companies doing
greenfield development, who were faced with a flood of candidates whose entire
previous work experience was in brownfield development. In reality, most of
those who failed at the whiteboard tests were competent developers who simply
had no experience working with a blank slate Given an existing system, and a
feature to be added or a problem to be fixed, they do just fine. And most
greenfield companies get to the brownfield stage within months of starting up.

In fact, now the industry has become more of a brownfield industry than it was
a few years ago and needs more people who can refactor legacy code, or at
least cope with the mess.

I suspect that the mess would have been less if whiteboard interviews had not
become so important because more startups would have hired brownfield
developers who could have warned of how quickly technical debt can overwhelm
you.

Common to see a startup go from startup to legacy big ball of mud in only two
years.

