
Ask HN: As an Engineer, how would you like to be interviewed? - aalhour
Hello HN,<p>Most people, if not everyone, in our field think that hiring engineers is a broken process. How do you think you should be interviewed as an engineer for the company to see your skills and strengths? How do you think a company should judge whether you are suitable for the job or not?<p>Cheers!
======
ericpauley
To give an opposing data point, I think that the conventional interview style
is working well in some places. I'll discuss Microsoft, where I interviewed
last fall for an internship.

There were a total of 4 interviews from various people on a perspective team,
all back to back in the morning, 30 minutes each. Each interview was pillared
by an algorithmic problem of varying difficulty, but there was clearly no
expectation that you'd write a working program in the time. Most of the time
was spent discussing the problem, comparing it to other ones you've approached
before and searching for solutions. If you felt comfortable after this you
could write code given time.

4 algorithmic interviews may sound like a lot, but I credit Microsoft for
using this to the candidate's advantage. Each interview is an opportunity to
succeed and show your best self, and I found that the one question that played
to my strengths had the most impact on my hiring decision, whereas questions I
did poorly on did not ruin my chances.

The rest of the interview was spent discussing past experiences, with an
emphasis on the challenges of collaboration. This part was a discussion, with
extensive back and forth and no expectation to be a certain way or exude some
quality. Some of my discussions ended with us at unsolvable questions, and in
others I got valuable feedback that I brought back to my personal projects.
All in all my interviews at Microsoft helped me grow as a programmer.

Further, Microsoft makes their on-site interviews an enjoyable process, giving
candidates time to learn about the company, tour the campus, and spend time in
the Seattle area to get a taste of it. Their interviews are as much an
enjoyable vacation as an opportunity to show your stuff. For me Microsoft's
hiring process (At least the on-site part, stages before this have some
issues) was an enjoyable opportunity for growth.

~~~
chrisbennet
Not sure why someone(s) downvoted you. Maybe because you mentioned Microsoft?

------
mchannon
There needs to be written (and if given the time I'll write) a yelp
specifically for engineering interviews. Only interviewees can give reviews,
and reviews will be restricted to binary yes-or-no questions (did they inform
you of a decision in 24 hours? Did they try to sell you on the job? Did you
still want to work there after you interviewed there? Did it seem probable to
you that you had absolutely no chance of getting that job?, etc.). Think of it
in terms of a Joel test, only strictly dealing with the hiring process, and
publicly (freely) shared. Call it a Matt test.

These reviews would be aggregated and allow a new prospective candidate to
decide whether it's worth the gamble to take the time to interview with that
company (a bet amounting to hundreds of dollars of lost time if they're
already employed elsewhere). The goal is to encourage hiring managers to step
up their game, cut out the baloney, and quit putting their own staff through
breakneck quotas of pointless and feckless interviews.

It's also to draw a huge scarlet spotlight on the companies out there that do
nothing but interview and never hire. These tirekicker companies are a scourge
on the industry and it's a necessary public service that they be identified.

If your company is so choosey that it has to go through 100 onsite interviews
to pick one candidate, fine, but candidates have a right to know that before
they commit to your process.

------
debacle
I'm going to reference coding tests specifically, because I'm not against them
but I'm against them implemented poorly:

\- If I have an extensive github, and my github is on my resume, and you don't
have the time to look at it, I don't have time for your coding test.

\- If your coding test asks thinly veiled lateral thinking questions, I will
not be accepting a job with your company.

\- If you spend more than 60 seconds of the interview asking me what I think
of your coding test, I will not be accepting a job with your company.

\- If I'm interviewing for a position where I'm going to be mostly developing
CRUD apps, don't ask me to implement a bubblesort. Interview for the job
you're actually hiring for.

\- Ideally, let someone else design your coding test. There's plenty of
companies that do these now, and they'll be better at it than you are.

~~~
duxup
>If you spend more than 60 seconds of the interview asking me what I think of
your coding test, I will not be accepting a job with your company.

Is that a big enough deal to rule out a whole company?

~~~
debacle
From what I have seen, companies that fetishize their coding tests have toxic
social dynamics, and they always interview poorly in other ways (e.g.
haughtily dismissing industry accepted best practices).

------
zerr
Start from this: candidates should NOT need to prepare in advance. So your
process should test them AS IS.

Many BigCo's assume that candidates should be dedicated enough to allocate
weeks/months for preps.

Another critical point - if you have take home tests/assignments and it might
take more than 10-15 minutes, always offer to pay the premium hourly rate
regardless of outcome.

------
cimmanom
If you’re interested in hiring people who are already employed, don’t design
your hiring process to require me to take a week off work just to interview
with you.

~~~
aalhour
Ok, let's say the company proposes an on-site interview that would last 0.5-1
day, how would you like to be interviewed on that day?

~~~
cimmanom
A full day interview is excessive, unreasonable, and almost certainly
unnecessary (you're also wasting your own people's time). Again, your
candidate has another job and - if they're any good - is probably interviewing
other places. Especially if they're not desperate to make a move, they're not
going to take multiple days off in a week to attend interviews.

(And that's not even counting the awful take-home coding challenges that take
multiple evenings or an entire weekend to complete.)

For a half day, allow it to be scheduled at least partly before/after standard
work hours so that the candidate can just come in a bit late to their current
job or leave a bit early - claiming a dentist appointment or similar.

If you don't respect my time, I'll assume that's a harbinger of how you'll
treat me after hiring, and I'll walk away.

~~~
aalhour
Fair enough. Let's say that the interview was scheduled for 3 hours in a time-
window that suites you, how do you think the interviewing process and contents
should be? What is a good way to showcase your strengths as an engineer?

~~~
cimmanom
No algorithms. Talk through the design and architecture of a real life or
hypothetical system.

And at least half of the interview should not be about technical skills; at
least half should be me finding out about the company rather than vice-versa.
Talk about process. Talk about stack. Talk about interactions with non-
engineers. Talk to non-engineers.

------
amorphous
This works better for freelancers: check the engineer's online presence, his
blog, GitHub etc, then have an informal interview to see if you two are able
to help each other, and then start working together on a _small actual task
for a reduced price_.

Both benefit. The engineer does not need to work on silly online tests, gets
paid and gains an impression about how the company works; the company gets to
see how the engineer solves a real problem, gets (most likely) a usable result
in return and has provided the engineer with a headstart into the company's
work culture should they decide to continue the cooperation.

Everyone wins, resumes become mostly useless and no artificial interviews

------
mlthoughts2018
I want to be interviewed in a manner similar to how almost all other
professional job types experience interviews.

\- The vast majority should be technically probing conversation that digs into
the specifics of my expertise and work project history. No whiteboards, no
live coding, no take-home tests. Just technical conversation.

\- The interview should weight my ability to speak clearly about my technical
expertise and work history highest by far. This should be weighted drastically
more highly than performance on coding tests.

\- Code tests should offer the candidate whatever combination of tools they
feel most comfortable with, in terms of editor, mouse/trackball, language of
choice, access to basic documentation.

\- Code tests should mostly be about talking with the interviewer. They should
involve no “gotcha” trickery to see a shortcut. Getting the naive, slow time
complexity, memory-hungry solution with a clean writeup should count as a
fully complete solution, not scored any lower than a solution from someone who
happened to memorize a dynamic programming trick, etc. The basic fact of being
observed in an interview means that if you observe someone only able to
complete the naive solution, it does not tell you anything at all. In a non-
interview setting, they might easily work out an advanced solution. Or, if
someone overfitted their knowledge to memorize these types of interview
solutions, in a real work setting they might not generalize to ambiguous,
unsolved problems. Observing anything other than the basic solution truly
cannot tell you anything useful. It’s sheer hubris to believe otherwise.

\- The entire interview process, expectations, and precise timeline should be
explained to the candidate at the start. Each interviewer should clearly
explain who they are and how to contact them later if needed. And each
interviewer should have knowledge about the candidate, their work history,
etc., and place a higher value on learning more about those items than
hurrying up to ask their favorite trivia questions.

\- Rejections should always be sent out in a very timely manner after the
interview. It should include meaningful feedback about all relevant factors
that went into the decision, and should offer the candidate a genuinely
sincere option to provide feedback. Even if the candidate feels hurt, bitter
or angry at the decision, you should thank them sincerely for taking time to
help you by pointing out ways your process might have been unfair or
suboptimal.

One way to sum all this up is to say interviews should be humane. Use common
sense about being humane to this person. Additionally, if you believe detailed
code trivia or tests gives you better quality info about a candidate than
technically probing their experience and skills in conversation, you are
wrong, and this mistake will totally corrupt your hiring process.

~~~
aalhour
Thanks you! This is a really good outline. What is your take on system design
questions that follow the "How would you design a Twitter-clone" vein? Do you
think an open-ended question like that would show the interviewer your
communication skills and good software design skills?

~~~
mlthoughts2018
As long as these questions are focused on projects the candidate already
worked on before, then yes, they can be good.

When they are canned questions, there is at least one small issue and one big
issue.

The small issue is that people will research and memorize solutions for common
questions like “how to make Twitter” or “how to rank a newsfeed” or “how to
ensure fault-tolerance in a distributed file system” (yes, the memorization
even covers how to respond to questions in a ~45 minute open-ended
conversation). If someone looks good on a design question about e.g. a Twitter
clone, it doesn’t tell you much. If someone does bad on it, it probably also
doesn’t tell you much unless they totally can’t parse the basic concepts
(which should have been weeded out way earlier).

The bigger problem is “Guessing the Teacher’s Password”[0] and applies even
when you ask non-standard questions that someone couldn’t have memorized ahead
of time.

As the interviewer, especially if you were prepped in some interview training
or team meeting, you will have preconceived expectations about what the
“right” answers are and what the right progression of concepts, features, and
details would be like.

As a result, you’ll favor candidates who happen to “guess” your preferred way
of looking at the discussion, even though there could be many perfectly valid
alternative ways to think about or discuss the problem that approach it
differently, with a different sequence of questions or iterative enhancements.

At best this introduces some unnecessary arbitrariness into the pool of
qualified candidates. At worst, you are unwittingly self-selecting for people
who approach problem solving the same way you do, and are therefore reducing
diversity of thought. If the big design question is also unrelated to the day
to day job, then this arbitrariness is even worse: rejecting or self-selecting
entirely based on your preferences about a toy exercise.

[0]: <
[https://www.lesswrong.com/posts/NMoLJuDJEms7Ku9XS/guessing-t...](https://www.lesswrong.com/posts/NMoLJuDJEms7Ku9XS/guessing-
the-teacher-s-password) >

------
xchip
Before the interview:

    
    
      - Do read my CV
      - Look at my GitHub repo.
    

During the interview:

    
    
      - Ask what were the technical difficulties of whatever project calls your attention/looks relevant, both on my CV or GitHub.

------
michaelgv
Instead of asking me to complete some boring challenge, bring me into your
office, and let me help solve a real issue you’re facing, then at least we
both don’t waste our time on challenges that only prove you have free time on
your hands.

~~~
NonEUCitizen
BUT also pay me for my time at market consulting rates.

~~~
marssaxman
So, in other words, "don't interview me at all, just hire me"?

~~~
NonEUCitizen
No -- pay candidates for the day they spend interviewing with you.

------
auslegung
Have the team meet me for a meal and/or drinks to get a feel for each other.
If my resume looks good enough (make sure to set the bar realistic or even a
little low), and I seem to be a culture fit, bring me on, but make it clear
that the first 30 days is the second half of the interview process. Maybe make
the first 30 days only 30-hour weeks so the company doesn't have as much cost
to hire me and so I can continue to look for other jobs. Or 'contract' with me
for 30 days 30 hours/week if that's easier for the company. As soon as the
team knows it wants to keep me, make it official, no need to wait the full 30
days.

In theory this sounds good to me, but it might be terrible if I needed a full
paycheck right away, idk.

~~~
zimpenfish
> Have the team meet me for a meal and/or drinks to get a feel for each other.

The circumstances of a (forced) meal/drinks outing are almost certainly quite
different from those you'll experience on a day to day working basis.

(Or if they aren't, run, that's a toxic environment right there.)

------
tboyd47
I don't think hiring is "broken." I think that it's a hard problem where you
would require unlimited resources and time to achieve perfection.

A short onsite interview where we discuss my previous work experience and your
current needs is the best way. Programming skill should have already been
proven beforehand, but FizzBuzz never hurts. It should be no more than an hour
long.

~~~
aalhour
Let's say you are interviewing for a managerial position, how would you like
to be interviewed in a way that shows you can lead people?

~~~
tboyd47
My resume will already have the relevant experience listed on it. The purpose
of the interview is not really to gain new information about me, but to verify
the experience I claim to have. It is very difficult to tell if someone is
being dishonest or even just exaggerating their experience just from looking
at their resume, but easy in an interview. I expect they would just ask me
questions that no one would know except someone who actually did what I
claimed to do, until they are satisfied.

~~~
aalhour
Aha, that's if you assume that you're applying for a position that you worked
in before, but say you applied for a entry engineering management position and
all you did before was develop software without leading anyone else. How
should the interview go about from your perspective?

------
billconan
like a hackathon, implement an app within a day with a provided topic, such as
a chat app, a forum.

~~~
zimpenfish
But only if you get paid for your time - it's daft to think anyone can afford
to give up a day's wage for a test.

