
Interviewing the “Passé” Way, For a Reason - liveweird
https://no-kill-switch.ghost.io/interviewing-the-passe-way-for-a-reason/
======
aahortwwy
Every time one of these interviewing posts bubbles up I skim it to see if the
author mentions things like: company size, team composition, the nature of the
work the team is doing, the nature of the industry the company exists in, the
way hiring decisions are made, the desired properties of their hiring process,
their offer rate, acceptance rate, turnover rate, the amount of time positions
tend to stay open for, or really just anything that would offer some context
on what, specifically, their interview process is optimized for or achieving.

Nine times out of ten that stuff is absent and the post is just a bunch of
opinion and conjecture.

By the way, when you're doing something nebulous in an interview like seeing
"how the candidate thinks" what you're often doing (all too frequently without
realizing) is looking for justification for a decision you've already made
based on whether or not you like the candidate. The fact that you have them
writing code on a whiteboard doesn't instantly make the whole thing an
objective process.

EDIT: You can test the above by making a "prediction" about the candidate's
performance after the intro and comparing your prediction to your final
decision after the interview.

~~~
mpweiher
> decision you've already made

Abso-fucking-lutely, pardon my French.

To be a little more precise: unless you're going into an interview totally
unprepared, there is a résumé that you've read, hopefully read carefully. I
make a decision, based on said résumé, whether I would like to hire that
candidate. Maybe "decision" is too strong a word. Hypothesis. Yes, hypothesis
is better.

That means I have some sort of mental model of what the candidate might be
like, what they can do and whether and how they fit.

If the person is invited for the interview, the hypothesis is "yes, I would
like to hire this person".

The purpose of the interview is to try to _disprove_ the hypothesis. If you
fail to disprove the hypothesis, hire the person.

~~~
aahortwwy
A lot of companies instruct their interviewers to "default to no" when making
hiring recommendations. Effectively the opposite of what you're suggesting.

I knew a lot of interviewers at those types of companies who wouldn't bother
to read resumes, either. They'd cite "bias" or something.

~~~
Nimitz14
The issue with defaulting to yes is that then you're going to be a hiring a
lot of mediocre people who say just enough to appear "okay".

~~~
madmax108
I think the oft-repeated adage "A players hire A players, B players hire C
players" kind of falls into this.

"A" players want to hire people better then themselves who elevate both
themselves and the team.

Not getting into how most "B" players see themselves as "A" players (dunning-
kruger?), unconscious biases, or people who are just bad at playing
interviewer (esp. people who have done it a certain way for their entire
careers and are unwilling to even think that a different process might yield
betterresults).

------
maxehmookau
"mainly to check the chemistry between a potential new-joiner and the team
members"

"Chemistry" is just an excuse to allow unconcious bias to run rampant IMHO.
New hires shouldn't need to enforce the existing culture of the team you have
by matching it.

They should be adding to it, not neccessarily emulating it.

~~~
specialist
Ya. What he wants is conformity.

Which is a good filter, for better or worse.

Think sororities and fraternities recruiting pledges. For better or worse.

I've long accepted that I simply don't fit into most orgs.

"Oh yea, JIRA Agile SOA dynamic typing FTW, woohoo!"

I can say the words. But most people sense on some level that I'm lying.

~~~
maxehmookau
Homogeneous teams move fast, sure. It gives the illusion of growth and
progress.

However, they don't often move efficiently, or even in the right direction.

------
quickthrower2
This guy isn't going against the trend. Not the "what people actually do"
trend, that is!

The trend of what people like to blog or comment is a different thing!

------
mannekenpix
I tend to follow the same pattern when I do the interviews. I agree that the
technical part can be easily taught if the candidate has proper engineering
foundation. But I still ask technical questions. But only on the technologies
the candidate did put on his resume. I want to check if the candidate
understood the technologies he used. After that I ask a more logical question.
Not especially a real-life work problem. Like Sebastian Gebski says, it is
more to see how the candidate reacts towards a problem and how he tries to
solve it. I always start this exercise by saying to the candidate that there
is no good or bad answers and that I want him to talk to me like if we were
two colleagues trying to solve the same problem. And of course I help the
candidate when he's stuck. The goal is also to assess his communication
skills, which is a very understimated skills amongst developers.

~~~
maybe-idiot
I like the idea of asking tech questions based on the tech listed on
candidates resumes. And, sorry to call you out, but I feel a duty to point out
your use of gender pronouns.

~~~
mannekenpix
Sorry, English is not my main language. I'm still learning.

~~~
itronitron
I recommend using 'they/them/their' in place of (s)he or 'he/she' as it flows
better for the reader. For example... _see how the candidate reacts towards a
problem and how they try to solve it._

~~~
mannekenpix
Thanks for the tip and the explanation!

~~~
wccrawford
The reason that people now prefer "they" instead of "he" is that it causes a
bias towards a gender when discussing things. If you're talking about
something that has typically been male-dominated, it's kind of unfair to use
"he" when talking about unknown people. So people prefer the use of "they"
now, even though it's supposed to be plural. English just doesn't have a
neutral pronoun otherwise.

------
fennecfoxen
right. So when you’re done throwing the algorithm on the board, the candidate
either implements it from memory because he’s a new grad from college, or has
to deal with the overhead of communicating fending off your questions and
“helpful” suggestions. It’s annoying and random and and gets you less
interesting of candidates on net.

I swear, I was just dealing with this a week ago. “Excuse me, Mr. Interviewer.
I can either answer your questions about what’s going on here or attempt to
fix the last let of this code. Which is more valuable to you?” Proceeded to
use silence to fix code. Puzzle solving uses the uninterrupted brain.

And just the other day, I had the SQL schema question to design a schema … for
a calendar! Worst interview question I ever experienced, honestly. Nearly no
one designs calendars and they’ve got lots of ways to trip you up because
recurring events are exciting. (Also, when I did design something decent with
two tables and was asked to query both with a single SQL statement my
interviewer didn’t understand UNION but that’s another matter.)

I like take home projects augmented with short exercises to verify that I’m
not a plagiarist who’s incompetent at code. If you want to assess my puzzle
solving capabilities let me play a Zachtronics game like SpaceChem or the
like.

~~~
JonLim
I gotta ask... are companies you're interviewing with expecting you to have
memorized particular algorithms? Or to be perfect with syntax?

In my most recent round of interviews, I found almost no one expecting me to
recall a particular algorithm and implement it for a solution to a problem,
but I did find plenty of questions that involved dealing with data structures,
and writing my own code and algorithms to solve those problems.

Maybe I've been fortunate with not having been asked questions like "implement
the quick sort algorithm"?

~~~
fennecfoxen
In this case it's a "distance between two employees in an org chart", which is
basically a trivially modified closest-common-ancestor algorithm. The
complication was that there was no ability to index into the tree at an
employee and climb upwards, and they didn't want to incur the overhead of
building that at the start.

That's fine in and of itself, but when I'm having a bit of a time pruning the
common-ancestor paths, I want to use all 7 brain-registers for the problem
instead of devoting 2-3 for communication, or, worse, having to flush
everything from cache to analyze and respond to your "hint".

------
konaraddi
> That's why my interviews are aimed to check how does the individual think
> (instead of verifying her/his memorization skills). How does (s)he approach
> problems, split them, classify them, explore possible solutions? When does
> (s)he abandon the path that doesn't look promising anymore? Is (s)he able to
> effectively share her/his thoughts (verbally, graphically, in code)? What
> about focus - does (s)he navigate in terms of a given goal or roam
> chaotically around?

This sounds a lot like system design or leetcode-esque interview questions,
which is the trend among tech companies in the US.

> The problems candidates are facing at my interviews usually have NOTHING in
> common with the company's domain, BUT they have a super-low entry level
> (e.g. they are about common problems everyone encounters every day):
> building up the context takes seconds (literally), so the candidate can
> focus on tackling the problem, not understanding its basics.

Are they system-design questions? This post could use some examples of
interview questions the author has asked.

------
s17n
At my company, we interview a lot of intern / newgrad candidates who are also
considering careers in finance. The less these people know about what "real
work" in the tech industry actually consists of, the better our chance of
closing them. The main goal of the interview is to present a fun puzzle that
will make them like us.

~~~
bryanrasmussen
How do you keep them then? A fun puzzle once a week - or just lots of money?

------
carlsborg
Teams need a portfolio of brains optimised for different and often
complimentary workloads. Try to figure out what mental workload the candidates
brain is optimised for and if it’s a fit for your team.

If you’re going to war and recruiting infantry. Some people can lift 200
pounds easy but can’t run half a marathon. You likely want both types on your
team.

~~~
FeepingCreature
I wouldn't want to go to war with squads where half of them can't carry the
standard load and the other half can't keep up with a day's march. That seems
a recipe for getting team performance down to the lowest common denominator.

Not sure how that relates back to software.

~~~
carlsborg
Certainly you need to have a baseline for capabilities. All teams have
specialist roles be it infantry, sports or software.

A better analogy: the guy who wins the Nobel prize is not necessarily one who
churns out the most papers. You could consider each type a speciality and you
want both.

------
oDot
The article assumes that only an "easy" real-life scenario will fit in an
interview's timeframe. That is only true if you select scenarios unaltered.

A truly challenging real-life scenario can fit just fine after some
alterations.

~~~
pydry
This is how I do it too - normally I'll take a thorny real life issue we've
just had and decouple it from extraneous things I don't want to test and use
that.

I'm intensely suspicious of people who believe that this isn't possible.

~~~
anonymoushn
Do you mean a day or an hour?

One company asked me to find a bug in a library in a language of my choice out
of a small list of languages in a bit under an hour. So I pick a language from
a list of languages none of which I use regularly, and until the interview I
was not sure which of dozens of combinations of tooling will be used by the
project. It seemed like a reasonably sized bug that someone who was not
worried about time pressure and had worked on a project tthar used the same
tooling could reasonably do in the time given. So I failed, and I passed
comparably difficult sections at other companies that I did not want to work
at as much.

~~~
nicoburns
> So I pick a language from a list of languages none of which I use regularly,
> and until the interview I was not sure which of dozens of combinations of
> tooling will be used by the project.

Seems like this is where they went wrong...

~~~
bryanrasmussen
It seems an ok technique, if you understand that the person does not use those
languages, because maybe what you are testing is how well they approach
something they do not know anything about.

I had this happen to me in one interview
[https://news.ycombinator.com/item?id=13295212](https://news.ycombinator.com/item?id=13295212)
using Python which I didn't know very well. Despite it not working out I
thought it was one of the better interviews I've had.

------
StavrosK
I don't know, my main question these days when interviewing someone is "how
effectively can you turn money into work?". I don't care if you're having fun,
I don't care if you're motivated by the company's vision, I don't care if your
work is your hobby[0], I care about what kind of impact you'll have on the
business.

Telling me "I will come in for 8 hours make things you want made, the way you
want them, for money, and then go home" is fine by me.

[0] Some of these are bonuses or predictors of general suitability sometimes,
but none is a deal-breaker.

------
lapcatsoftware
"is (s)he actually having fun (when solving challenging problems)"

I don't know about anyone else, but for me personally, it's a bit difficult to
have fun when I'm unemployed and need a paycheck.

You might even say that interviews are testing for how financially secure you
are. You can only truly relax during a job interview if you don't actually
need the job.

~~~
bryanrasmussen
Too relaxed might make you not care if you get the job, and not willing to put
up with the typical hiring interview's little irritations - which was what
happened to me last week .

