
How I Interview - RKoutnik
http://rkoutnik.com/articles/How-I-Interview.html
======
koevet
I have decided that I will no longer take technical interviews.

I have 25 years of software development under my belt, I published a book,
spoke at various conferences in Europe, have a Github profile (admittedly not
very lively), worked for well-established enterprises and have great
references. Why shall I still prove myself?

If I was a senior lawyer or an architect joining a new studio, I strongly
doubt I would have to go through an interview to test if I can use the drawing
table or if I know the body of laws of my countries. It is just ridiculous.

As I work as a freelance, my approach will be to offer 2 weeks of work on site
for free. After the 2nd week, if they still think I'm good enough for the
company, I will charge the 2 weeks, otherwise goodbye and no questions asked.

~~~
deathanatos
> _Why shall I still prove myself?_

Because we see candidates claiming that level of experience that cannot
construct a simple for loop.

~~~
koevet
Well claiming is a very far galaxy from "demonstrating". What about
references? What about networking? What about published books and papers. This
stuff is very hard to make up, especially references.

~~~
jawilson2
It can be a chicken and the egg problem. None of those matter if the person
can code and solve problems, and is a good fit. We don't care if they are 15
or 60 years old.

------
ryandrake
What? "Implement as much of Minesweeper as you can in an hour?" If you're
going to build something--evens something as simple as Minesweeper, you're
still going to need time to plan it out, diagram it, decide which modules call
into which other ones, decide on the data structures, etc. Diving right into
writing code so you can get _something_ done in an hour is probably the worst
strategy if your goal is to do it right.

I'd rather work with the person who would approach that by taking 3 hours to
plan, 3 hours to code, and 2 hours to bug fix, rather than the "Ready, Fire,
Aim" person who took 1 hour to code, 4 hours to fix what he did, 8 more hours
to find his design was totally wrong and re-do major portions of it, 8 more
fixing the bugs in that version........

Unless you plan to filter out the people who just jumped into the code, in
which the exercise is just a trick question.

~~~
RKoutnik
I've had folks who just jump into the code without any planning. It usually
bites them about 20-30 minutes in. On the other hand, I remember one guy who
spent the first 20 minutes planning and only 40 coding and ended up doing
better than most.

The point here is not "Write as many lines of code as you can". I _want_ the
candidate to plan - it's a crucial part of the job. FizzBuzz, sorts and the
like don't require much planning. Minesweeper does.

~~~
infraruby
> I _want_ the candidate to plan

Then ask for that, and assess the plan, otherwise you're expecting Carnac the
Magnificent: [http://raganwald.com/2015/05/08/carnac-the-
magnificent.html](http://raganwald.com/2015/05/08/carnac-the-magnificent.html)

------
ronilan
So, like, my own personal experience...

A couple of years ago I applied for a certain company that this year turned
out to be a unicorn.

The automated reply said to build a Minesweeper. So I did. It took a several
hours to get into a shape that is playable. Then it took several days to
polish it into app store quality.

You can play here:
[http://www.ronilan.com/bugsweeper/](http://www.ronilan.com/bugsweeper/)

Download here:
[http://www.appstore.com/bugsweepergame](http://www.appstore.com/bugsweepergame)

And copy as much as you want from here:
[http://www.ronilan.com/bugsweeper/js/bugsweeper.js](http://www.ronilan.com/bugsweeper/js/bugsweeper.js)

If you are wondering how it went from there, they were "evasive". Then I got a
softball "center a div" interview with one of their front-ends. Then I got a
polite no thanks from the recruiter.

And that's all I have to say about it.

~~~
imh
Automated response questions are so disrespectful. "We won't take the time to
see if we're in any way interested, and won't unless you devote your own
time."

~~~
dvcrn
Even worse are automated responses from a no-reply emails like jobvite or
friends. If I already took the time to interview with you, invested hours of
my personal time into you, maybe even took a day off just so I can make your
weird schedule, give me at least a personal answer or a chance to ask for
questions.

I love to learn new things and actually really want to learn about the
mistakes I made. Giving me a "no thank you" from a noreply after all that time
is like a big middle finger in the face.

------
s3nnyy
I live in Switzerland and I used to code for a living. As an external, I hire
engineers for different startups in Zurich.

As I got deeper into IT-recruiting, I realised that candidate filtering at the
top of the funnel is fundamentally broken.

The market for software engineers is different from the market for - let's say
- actors. Especially for senior developers there is way more demand than there
is supply.

This has the very important implication that as a company you can not annoy
candidates too much. Asking for tedious homework, too many coding challenges
or references might be already overkill. Good people do not really need to
work for you; they can also work for Google Zürich (biggest engineering office
outside the US), or other cool tech-companies / ETH-spinoffs.

If you look for a tech-job in the most liveable city in the world, check out
my story "8 reasons why I moved to Switzerland to work in IT" on
[https://medium.com/@iwaninzurich/eight-reasons-why-i-
moved-t...](https://medium.com/@iwaninzurich/eight-reasons-why-i-moved-to-
switzerland-to-work-in-it-c7ac18af4f90) or send me a mail to the mail-address
in my HN-profile.

~~~
madez
Don’t get me wrong, but your comment reads like an ad.

~~~
rorykoehler
Native advertising ... in the comments.

~~~
s3nnyy
I sincerely believe that living and working in Switzerland is nicer than
anywhere else in Europe.

With my comments I raise awareness for my side-income but primarily I try
adding value to HN discussions.

~~~
rorykoehler
I was joking. You are entirely entitled to give your perspective and advertise
your services as long as you are transparent about it, which you were. No
apologies or explanations needed.

------
tokenadult
I wonder if the OP has ever read any actual research on effective hiring
practices. I have a FAQ for that.[1] The short answer that research gives is
to set up an actual work-sample test for the job in question. The longer
answer is to add in a VALIDATED test of the worker's general cognitive
ability. But if that kind of test isn't validated, the employer can be subject
to legal consequences in the United States if the test has "adverse impact" on
protected minority groups. Rather than just making up hiring procedures,
companies ought to do research on what works for finding better workers and
what is not legally risky for the company.

[1]
[https://news.ycombinator.com/item?id=4613543](https://news.ycombinator.com/item?id=4613543)

~~~
enraged_camel
I can confirm that this works incredibly well. At my previous job, my team was
responsible for technical training. So our interview process involved having
the interviewee give a 30-minute presentation and teach us (the interviewers)
a technical topic. Everyone we hired ended up having stellar job performance.

------
vdnkh
I had an interview like this recently. A "live coding" exercise after (in
their words) two excellent phone screens. The test was to implement a class
which would be run through a bunch of unit tests. Simple right? It turned out
to be a disaster.

First was the choice of language. They offered to take it in JS, Ruby, Python,
or Java. I'm a .NET developer whose competent with JS, but I really could be
better at it. I asked to take it in C# but they refused and said it's not
about specific language knowledge. So I did in in JS. I turned out to be
almost completely about JS specifics and quirks. Because I've been learning JS
recently, I've had the fortune of having to avoid the bad parts. When asked to
recite them I struggled. This part is obviously my fault but if I had been
allowed to perform in C#, I would have done a hell of a lot better.

Second was the environment. I have very limited exposure to programming on a
Macbook and I spent the first few minutes struggling to translate all of my
shortcuts. During a timed test it was pretty disheartening to not be able to
type as fast as I could. I haven't used Sublime before but the default theme
was near unreadable and I was allowed to switch it after a few minutes. The
third was the test framework. I really wasn't familiar with how Jasmine worked
in the browser, and it showed. Again, my fault. But taking 5 minutes to
familiarize me with their setup would have made things go much, much better
for me.

Before I get jumped on for blaming them for my poor performance, this was for
a test automation role. I explicitly said that my JS/Jasmine/etc. skills were
not that great and they still brought me on site.

Honestly, I would have preferred the whiteboard. Each test took up nearly the
entire period, leaving very short time for talks about what I really care
about - culture. I have a Github with a bunch of good projects. I've been
employed as a developer for a while now. I can obviously program well. Drop
the bullshit and lets talk.

~~~
bobbles
> "I asked to take it in C# but they refused and said it's not about specific
> language knowledge."

So.. "This isnt about a specific language, but you must use the ones we tell
you!"

------
acjohnson55
As a counterpoint, I'm fairly confident it's possible to hire engineers
without seeing the code anything at all. I'm not an expert, but I do know that
I've never felt like a homework/sample code/whiteboard exercise I've done has
borne any real resemblance to the work I do.

I'm generally a fan of getting a candidate to tell me about aspects of their
previous work that relate to the skills the job requires. I wrote this at my
last job on the topic: [http://www.huffingtonpost.com/alanjohnson/were-hiring-
engine...](http://www.huffingtonpost.com/alanjohnson/were-hiring-engineers-
all-wrong_b_7973484.html)

~~~
Consultant32452
I've never been required to provide a code sample for a job interview nor have
I ever asked for one. I've had pretty good luck sussing out who knows what
they're doing based on their ability to talk in detail about what work they've
been doing.

------
joshvm
"You wouldn't evaluate a chef's ability to cook by depriving them of
saucepans, why cut off Google?"

Depriving of recipe books is perhaps a better analogy? I think depriving of
saucepans would be like hiding the keyboard!

That actually works pretty well, even doctors are expected to look things up
if they get stuck. Why should programmers be any different? SO is extremely
useful for funny edge cases in software that someone else spent an afternoon
trying to figure out.

------
mixmastamyk
Uggh, been interviewing this month and it has been mostly awful. From "who was
your worst boss/what is your worst quality" to "solve this problem with us
watching, clock ticking, and a $150k on the line."

Also, the only profession (I know of) where twenty years experience is
considered a detriment. Perhaps fashion modeling is another? ;)

~~~
geebee
It's odd, isn't it? Twenty years of experience is considered good, but twenty
extra years of age is considered bad. This actually goes a long way to
explaining why interviews are such an odd experience - companies recruit for
experience (must have launched successfully with experience scaling), and then
testing for exam-ready knowledge of second year algorithms and data
structures. I suppose another way to put it is that employers would like
people with 20 years of experience who graduated from college last week.

------
autarch
Where I work we do something similar but it's a "homework" question we give to
people who pass our initial resume screen ([https://github.com/maxmind/dev-
hire-homework](https://github.com/maxmind/dev-hire-homework)). We tell them
not to spend more than 1-2 hours on it. We decide whether or not to interview
them based on the quality of the code they produce.

In the interview we ask things like:

* what is OO and how is it different from procedural programming? (high level conceptual) * why do you want to leave your current position? * what appeals to you about this job? what do you think you might like least? * what is the purpose of testing? * tell us about the programming languages you've used. what's your favorite? what do you like most about it? least?

I'd rather have a more conversational interview after already having
established their ability to code.

~~~
collyw
Homework exercises are a large burden on the candidate, so expect to half your
pool for that reason alone. I only do about half or less of these, as most are
crappy an unrelated to the job. I prefer to plan and do things thoroughly, not
rush a solution out in a couple of hours. And to be honest asking for more
than a couple of hours is more than you should be asking unless you are
willing to pay.

~~~
georgemcbay
"Homework exercises are a large burden on the candidate"

People keep saying that, but I'd MUCH, MUCH rather do a single couple of hour
"homework exercise" that I can submit than do a full day (or more!) of
"implement whatever pet algorithm/data structure I think is really swell" for
like 3-6 different people in series, which is how a horrifyingly large amount
of companies still tend to do things.

Give me a task, let me do it, have your tech people discuss my solution
amongst themselves. If they like my solution bring me in to discuss it (to
verify I didn't "cheat") and to determine culture fit. Seems like a lot less
wasted time for everyone with far few of the stressors (hard time pressure,
etc) that make most tech interviews so amazingly terrible.

~~~
sotojuan
> People keep saying that, but I'd MUCH, MUCH rather do a single couple of
> hour "homework exercise" that I can submit than do a full day (or more!) of
> "implement whatever pet algorithm/data structure I think is really swell"
> for like 3-6 different people in series, which is how a horrifyingly large
> amount of companies still tend to do things.

The best part is that a lot of companies make you do both : ) I've had that
happen to me.

------
padolsey
This methodology may correctly filter the candidates the author is seeking,
but if this made up the bulk of any interview I attended, it would probably
turn me off the role.

FWIW, when I attend an interview, as either party, I want to have a
discussion, a bit of back-and-forth, and crucially to determine if it's likely
we'd be able to get on, day to day. Coding competency is _not_ the only
important thing. And anyway, it can easily be established via a bit of white-
boarding, conversation, and preparatory reviews of any existing work they have
online. If you are in doubt, then maybe pair on a fun little algorithm,...
something that's not solved, and not dull. Something original would be best.

Being given a pre-packaged task to complete feels very procedural and bland...

~~~
i_s
> Being given a pre-packaged task to complete feels very procedural and
> bland...

This part is important:

> Having a consistent test also allows me to compare candidates easily and
> without bias.

Also, I think most people would care more about the content of the exercise,
rather than whether it is prepackaged or not.

~~~
padolsey
I get that. I just would rather not feel like a monkey being prodded whenever
I attend an interview. An interview being repeatable (for comparative
purposes) brings no value to the candidate.

~~~
RKoutnik
It does if the candidate is something that the interviewer might be biased
against (race, gender, opinions on Star Wars). Avoiding bias in interviews
helps everyone except those who rely on irrelevant qualities to get jobs.

~~~
padolsey
Maybe, but I feel that the answer to such biases is to introspect and
understand your potential prejudgements, and then not let them specifically
sway you. Anyway, the accepted alternative, an entirely meritocratic process,
is fraught with issues too, as the playing field is inegalitarian to begin
with -- so those candidates who might be the victims of unfair biases could
already be at a disadvantage since they might not have received the privileges
that preempt meritocratic success. It is assumed that relying totally on a
candidate's coding ability somehow avoids the issue of bias and works to mend
our diversity issues in this sector, but it actually merely plays into the
entrenched state of things. I don't have a solution, but this entire problem-
set is certainly deserving of more nuanced thought.

------
fillskills
Interesting points. Like the idea of the giving a developer actual development
tasks.

This is how I interview - We have a bitbucket set up with a project very
similar to our current site. We simply ask everyone who applies to get the
code from Bitbucket and install it locally. And then fix a simple bug. Most
developers who are well versed in the basics are able to install the code in
2-4 hours. People new to something specific are stuck for a day. It helps us
weed out people who are a) Not comfortable reading code b) Not hungry enough
to ask questions or google a little bit if they do not understand c) Not able
to debug and fix simple issues.

So far all developers who have lasted that test have been good technically.
Its another challenge to keep them motivated over long periods of time.

~~~
ilostmykeys
I love the bug fixing stuff especially if I'm allowed to re-architect your
stuff so that it's less prone to bugs to start with ;)

~~~
fillskills
Thats the trick to guarantee a job

------
lilcarlyung
Would be funny to come into an interview as the candidate and give the
employer pre-packaged tasks to complete to evaluate them on, to decide if I as
the candidate actually want to work there.

~~~
phamilton
I've been toying with the idea of asking for a reverse interview. I get to ask
about the challenges they've solved in great detail and how they dealt with
potential and actual issues. They get to answer and decide to I know what I'm
talking about.

~~~
maccard
Is this not the whole point of the interview for you now anyway? For me, if I
go in somewhere and get grilled for X hours and they deprive me of a chance to
ask about certain aspects of the company, you can guarantee u won't take the
job.

~~~
phamilton
That's what I'm counting on. Most startups are sufficiently desperate for
hiring that you can ask for things like "I'd like to grab coffee with the CTO"
and they will do it (that seems trivial at a 10 person company, but I've heard
it happen at 100+ person teams).

Where I am right now, I'm pretty happy just turning down the interview if I
don't oblige.

------
alexandercrohde
I was really liking this piece, but one inherent flaw of the example given is
that I've already implemented minesweeper in javascript once a couple years
ago for a programming challenge, so I'd have a major advantage over most
candidates.

For example, I immediately recalled I solved the problem of mine placement
with a 1 liner like:

var cells = ('*'.repeat(mineCount) + ' '.repeat(size -
mineCount)).split("").sort(function() { return math.rand() - .5; });

~~~
icecube
Correct me if I am wrong, but wont this result in the mines being placed in
the front more often than not? sort(function() { return math.rand() - .5; })
doesnt result in a truely random distribution.

~~~
deadbeef404
> doesnt result in a truely random distribution.

It evenly distributes over 0-1. Removing .5, just distributes it evenly
between -0.5 and +0.5. Sort basically says >0, the first option should come
first and if <0, the second option should come first.

I believe this still maintains a random distribution and is quite a tidy
solution. Thoughts?

~~~
re
It can be extremely biased, and the results can depend on the sort algorithm,
because what you're randomizing is the comparison results, not the order.
Consider insertion sort:
[https://en.wikipedia.org/wiki/Insertion_sort](https://en.wikipedia.org/wiki/Insertion_sort)

As the list is sorted, elements are inserted from the back by finding the
first element that the new element is smaller than. The last element to be
inserted is the one at the end of the unsorted array, and, with a random
comparator, it has a 50% chance of being "larger" than the biggest of the rest
of the elements, and thus remaining at the end of the list.

Microsoft used this technique to "randomize" a list of browsers back in 2010,
but, when viewing the page in IE, it ended up putting IE in the last position
(out of a set of five browsers) 50% of the time:
[http://www.robweir.com/blog/2010/02/microsoft-random-
browser...](http://www.robweir.com/blog/2010/02/microsoft-random-browser-
ballot.html)

~~~
deadbeef404
Ah, yes; that's a great point about the sort algorithm!

------
Yen
Am I the only one who, when being interviewed, doesn't mind whiteboard coding?

At interviews where I've later been given an offer, it's usually a relatively
small algorithmic design challenge, where the specifics don't matter, just the
pseudocode.

In interviews I've given involving whiteboard programming, I've always
emphasized that it doesn't have to be valid or even semi-valid code for any
language, just a semi-rigorous pseudocode expression of an idea.

I think, "if done correctly", whiteboard coding is a good filter for those who
can think algorithmically, who can catch the bugs that aren't typos, but
incorrect assumptions.

That said, that sort of mindset may not be what you need for your role. Need
to consider that.

\---

Tangentially, one of the better technical interview experiences I've had
involved chatting for a while, the interviewer describing an actual problem
they'd had (relevant to the role and the company's product), and discussing my
approach to the problem. (and passing or failing the interview wasn't
dependent on using the exact same approach...)

~~~
krisdol
> Am I the only one who, when being interviewed, doesn't mind whiteboard
> coding?

I'm sure you're not, but my experience is completely opposite of yours. I'm
still relatively early on in my career (I've had 3 software jobs, but have
grown up coding since I was 12), but every job I scored was one that didn't
use a whiteboard/paper problem during an interview.

I got a lot better at whiteboards with practice; but early on, every
whiteboard problem I received resulted in me blanking on even the most basic
concepts. I would have no idea how to solve problems on a whiteboard that I
explicitly solved in a codebase the week prior. Then I'd step out of the
interview and the solution would just hit me.

It's like state-dependent learning, in a way. As I got tested more on
whiteboard coding, I figured out that whole problem-solving process better,
and I do pretty well on them now. Still, I continue complain about those
problems. They feel like a completely foreign, perpendicular challenge
compared to having a discussion, answering questions, or writing code to solve
the same problem. It's not a skill I've ever used outside of interviews, nor
is it a situation that has ever been simulated at any workplace I've been at.

There's nothing wrong with evaluating a candidate's whiteboard presentation
skills. If the goal is specifically to evaluate technical or algorithmic
knowledge, it's worth taking into account that testing for that knowledge on a
whiteboard can introduce a side-effect that bottlenecks the candidate's
ability to present their answer.

~~~
thisone
Whiteboarding is a skill that the vast majority of people will have to work to
obtain. It's not the natural way that we work.

Personally, if you know you're going to be interviewing, start practicing for
whiteboarding. There are books and online resources available to help you get
at least comfortable with it. The resources also help drive home that
whiteboarding should be about process, not about perfect solutions.

Algorithms have generally taken years to perfect by PhDs, why should you be
expected to perfect an algorithm you haven't memorised in 30 minutes?

~~~
Namrog84
Do that many places ask you to perfect an algorithm or solution? Most places
me and my friends have done typically just want any brute force solution with
some discussion as potential ways one might improve or discussion on why this
might not be ideal without having better ideas. And this is from top places
and offers. And were from non top schools.

------
grecy
I'm a Software Engineer, have been passionate about computers my entire life,
and I've never once played Minesweeper.

I actually have no idea how.

------
freework
I still think the best way to interview a programmer is to just talk to them.
Ask them about their experiences. I've known a bunch of programmers in my
time, and I feel I can tell if someone is the real deal within a few minutes
of them speaking.

I'm happily employed at the moment (knock on wood) but when that day comes
where I have to go back out an interview, I don't plan on wasting any time
doing these kinds of interviews where they make you spend hours doing some
kind of programming challenge. To me it's an indicator that the company
doesn't have anybody knowledgeable to actually pick out the best programmers.

~~~
infraruby
> I still think the best way to interview a programmer is to just talk to
> them.

You're wrong: [http://www.ioatwork.com/selection-methods-almost-a-
century-o...](http://www.ioatwork.com/selection-methods-almost-a-century-of-
research/)

~~~
collyw
I can see this being misinterperted badly in the field of software engineering
(it doesn't seem specific to software) as it says work sample tests are best,
yet most software is large scale, and takes time to develop and ought to
involve planning, architecture, coding, technology selection, testing. So most
"sample work" for an interview will actually be nothing like that but a short
rushed version that is supposed to emulate it in some way.

~~~
infraruby
> I can see this being misinterperted badly in the field of software
> engineering (it doesn't seem specific to software)

Would you prefer Google's take on it? [http://www.wired.com/2015/04/hire-like-
google/](http://www.wired.com/2015/04/hire-like-google/)

> So most "sample work" for an interview will actually be nothing like that
> but a short rushed version that is supposed to emulate it in some way.

Yes, that's the idea! And it works.

~~~
collyw
From the article :

"but for many jobs there are too many variables involved day‑to‑day to allow
the construction of a representative work sample. All our technical hires,
whether in engineering or product management, go through a work sample test of
sorts, where they are asked to solve engineering problems during the
interview."

Plus a number of other things according to the article.

Sounds like they are agreeing with what I said (at least to some degree), but
still asking for something anyway.

~~~
infraruby
> Plus a number of other things according to the article.

Yes, combining methods works even better! It's far from saying that the best
way is "to just talk to them".

~~~
collyw
It won't work better if you give candidates so many tasks that they think,
"why bother?" and go for another easier job application process instead.
People have other commitments, and we are often told there is a shortage of
developers.

I have told potential employees as much after they asked for a sample of my
work (which I had made available for that purpose), and they after that, they
still wanted a three hour exercise done before I had even spoken to anyone.

In fact I am about to start a new job in the new year, I had a few interviews,
and a couple of jobs that interested me sufficiently. One involved a three
hour test, the other asked for a sample for my work. Guess which one I took?
Guess which one the interviewer said they were struggling to find candidates?

------
refuzed
I did the challenge and it was a fun endeavor. I'm mainly a C# dev. I dabble
in AngularJS at work but don't consider myself a pro. I'd never tried drawing
to the canvas so this seemed like a good challenge.

I managed to get something fairly workable, albeit ugly code-wise, banged out
in 1hr. If you reviewed my google searches, you would see that:

\- I didn't know how to init a 2d array in javascript

\- I didn't know that the things on the canvas couldn't be accessed directly
for click handlers

\- I cheated on the solution for finding neighbors because I was running out
of time

*edit formatting

------
jarjoura
I've been giving interviews for almost a decade now and I've both tried and
seen many different approaches. Yet, I think the MOST important part of the
45-60 minute time slot I get with a candidate (or future coworker), is the
conversation.

1) I want to see passion for solving problems in the space. There are endless
problems to solve in the industry, but I want to know they'll be excited to
work on my team's problems.

2) What are they doing here? Was this a numbers game (interview at a ton of
different places in hopes of getting one good offer)? Were they recruited or
did they actively seek this position out?

I've seen candidates where in one interview I have to throw multiple problems
at them, because they think about it for 30 seconds and then come up with a
correct solution and quickly write it out on the board. I'll usually run out
of questions for these candidates.

Ultimately, white-board coding works well for some, and is a complete disaster
for others. Yet I don't believe it means white-board interviews should be
thrown away in an effort to be "fair." I just think as engineers, if we really
want to land a position at a Google, Facebook, or Uber, etc, is it too much to
ask that we study up on our algorithms?

------
gkop
Do JavaScript experts consider JSBin a decent environment for this task?
JavaScript is a bit verbose and I would resent simply the aspect of having to
write a substantial amount of JavaScript without autocomplete.

I just played with JSBin and it doesn't have autocomplete out of the box.

Edit: whoa I just re-read the OP and found this

> Most [candidates] tend to use the laptop & JSBin provided

That's super hypocritical, OP (see your paragraph headed "Comfortable
situation")! If you "provide" them with an environment of course most are
going to use what you provide since that is what you are suggesting. So now
you're filtering for people for whom that laptop model and the JSBin tool are
familiar and comfortable.

Or in the case of those that reject your environment and choose their own
familiar and comfortable laptop and editor, you are filtering for those with
the self-confidence to reject the suggestion of the interviewer, which doesn't
really help with your stated goal.

It's a shame because I like some of your other points :/

------
mailshanx
My personal, preferred way to interview data scientists (besides administering
a work sample test) is to talk to them about the most challenging effort
they've been a part of. Start with understanding the overall business context
and the technical infrastructure they were working with, and gradually follow
through until you understand the key ideas that underpin the innovation.

The key is to get them to explain things until you understand the essence at a
foundational level - hopefully you understand what combination of the notions
of statistical independence / power / dimensionality / algorithmic complexity
has birthed novel system or algorithm they built.

The process selects for people who have a) already built something
substantial, and b) have the communication skills to explain it.

------
cmillard
Completely am on-board with the descriptions of false positive/negative

I agree that this seems like a good way to establish someone's technical
competence. I do wonder though from the interviewee's side what the optimal
time to spend on one person is. It's kind of like dating right? (Well what I
imagine dating would be like if I lived in a big city) You have concurrent
first impressions with maybe second and third follow ups before you seal the
deal. This may be a bit like asking for a relationship on the first date.

Demonstrating ability in this manner works for more junior people who maybe
don't have a github or other personal projects, but I'd consider discussing
and reviewing those more valuable.

------
maindrive
I somehow think that the interviewer should also be interviewed at the same
time. If you have that kind of experience under your belt, one might
definitely be interested in knowing if the person he/she would work under is
really capable or not ? Working with/under someone lesser than you n same
person is taking your interview, its kind of a insult to be honest.

------
Kurtz79
"Finally, I assumed that most everyone played Minesweeper at one point and I
wouldn't need to explain the rules."¨

I stopped making such assumptions since I started interviewing.

Warming up question: "How would you check that two strings are the anagram of
each other ?"

"What's an anagram ?"

------
bradlys
> "Candidates are also reviewing a company. They'll be dedicating several
> years of their lives to this workplace and will be looking at the interview
> filter to see what it takes to get in."

Really? I barely know anyone who works for several years at any place. I'm
looking at whether I can tolerate it for six months. That's only so I can take
a job search break for a few months before hitting the grind again. I'd love
to work at a place that's so great that I'd be there for several years but
that's hard to imagine. Most companies I've interviewed with don't exist in 3
years, let alone 'several' (7+).

~~~
greggyb
This is a very small niche that you live in. I can tell you that a candidate
with 7+ 6 month engagements would be unlikely to get a position at my current
company (mid-sized business intelligence consultancy), and simply wouldn't be
considered at my last company (old school enterprise environment).

The startup scene is not representative of the job market for the majority of
people.

~~~
krisdol
>The startup scene is not representative of the job market for the majority of
people.

On that note, I'm surprised that startups would hire frequent-short-stint
employees. The startup I work at has a great proportion of people who have
stuck around since the early days; yet I have worked (and interviewed) at
large companies where everyone bails within a couple of years max. I don't
know what the West Coast "scene" is like, so my company probably doesn't
resemble SV startups, but the pay is great, the people are smart and
passionate, and the businesses is hitting all of its goals, so I'm not
complaining.

------
crazylila
At the Beginning Be warm ask them how they are Listen Be considerate ssk if
it’s still a good time Don't Be Too Familiar Use Appropriate Language Explain
what is going to happen

