
What not to ask technical people in interviews - joeyespo
http://www.fusioncube.net/index.php/what-not-to-ask-technical-people-in-interviews
======
blindhippo
"The dirty little secret that I don’t mind saying is that software development
isn’t hard. There’s lots of handbooks, manuals, blog entries and Stack
Overflow Q&A pages out there that very clearly describe how to work with any
development language or tool. Follow it step by step and you are a software
developer."

Great, yet another article continuing the tradition of thinking software
development is an easy discipline, but it's our mindset that makes us special.

Good luck developing anything mission critical with a team of low paid
googlers.

One day even people in our profession might come to actually have some self-
respect for what we do. Software development is a hard and challenging
discipline - to trivialize it by pointing at guide-books and Q&A forums just
demonstrates a total lack of understanding for what we do.

~~~
paganel
> Good luck developing anything mission critical with a team of low paid
> googlers.

IMHO, that's another dark-secret of this trade, most of us don't develop
"mission critical" services. By "mission critical" I understand something like
"if this code breaks then someone dies or huge sums of money are lost etc.".

> One day even people in our profession might come to actually have some self-
> respect for what we do

I totally agree with you that "software development is hard", but not because
someone happens not to know what methods a standard library class implements
(every few days I give almost god-like thanks to the developer that decided to
implement the dir() function in Python), but because ~35 years after "The
Mythical Man-Month" was first published we repeat at least half of the
mistakes presented in there.

~~~
AznHisoka
Yup, I agree.

Software engineering also requires a lot of mental pain, and struggling and
debugging, but the end result? it's equal to what other occupations produce
with less struggle.

------
aero142
Wow, that is quite an article. I think it manages the rare feat of being
completely wrong. Usually people write enough words that they stumble into
saying something useful.

Personally, I love asking esoteric questions in interviews, but not because I
care about that particular question. I am trying to figure out if you are the
kind of programmer who looks beneath the covers to figure out what is really
going on. Do I expect every programming to know how b-trees relate to database
indexes, and what their lookup times are, no. But if you have written a lot of
SQL and never bothered to figure that out, you are probably a slave to the SQL
interface and aren't the type of person who will ever really understand how to
optimize queries. The point is to figure out they type of person they are.

Secondarily, I like working with nice people. It's important. But I have
worked with nice and smart people who wrote horrible unmaintainable code, and
I ended up loathing working with them. Plus, the better the programmers, the
less of them you need. Turns out this is terribly important in software.

~~~
jff
I think, though, that it's wrong to decide "this person is not intellectually
curious" merely because he has never investigated the particular esoteric bit
you picked to test "intellectual curiosity".

I could ask you if you know the x86 calling conventions--what, you don't know?
But you use x86 machines every day, and write code to run on x86! You're
obviously a slave to Ruby/C++/<insert-language-here> and just aren't the type
of guy to go learn things.

~~~
aero142
Like I said, I'm not trying to find out if you know a particular thing, I'm
trying to figure out if you ever learn things that are deeper than the
surface. So, if you don't know x86 calling conventions, fine. But if I ask
several more questions in that domain, and you don't know any of them, then I
check your resume and you having been writing C level code for years, I'm
concerned.

------
eligottlieb
Actually, I'd say the #1 thing not to ask me in an interview is "What is your
passion?".

Did you really want to hear about my time between the sheets with my wife? No.

Did you really want to hear about my love of outdoor Humans vs Zombies games,
or the different kinds of Munchkin games? No.

You probably wanted to hear about my work as a hobbyist Computer Science
researcher, but I don't want to tell you about that. You would understand half
of it and then decide that I'm a grad-school egghead who doesn't belong at
your company.

Luckily, I applied to graduate school this year.

~~~
blindhippo
The people who ask what your passion is and are looking to hear that you
program for the heck of it are simply trying to cash in. Likely you'll be
willing to work longer hours and get paid less then your knowledge is worth
because you'll get to work on "exciting and challenging stuff!".

I've met several people who think this is the only way to hire "real"
programmers. They never get it when I point out that no other profession
operates in this manner.

~~~
tweak2live
What these same people also fail to realize is that just because you enjoy
working on "exciting and challenging stuff!" doesn't mean you will find
debugging their firm's spaghetti code exciting.

Yes, there are projects on which I would work 10-15 hours a day with minimal
pay but, odds are - yours isn't one of them.

------
ShabbyDoo
tl;dr; I only ask detailed questions about technologies of which a candidate
claims recent and deep knowledge. Wrong answers suggest stupidity or
dishonesty.

Let's say I'm interviewing someone who claims to have been a professional
software for a decade and that most of his work was in Java. I know Java quite
well, and I know what sorts of things one HAS to know about Java if he doesn't
fundamentally suck as a software developer and isn't lying on his resume. If
you claim to have written Java code for the past five years but can't explain
the difference between a Set and a List, you are either stupid or dishonest.
One of my favorite questions for a supposedly experienced Java developer is to
show them a code snippet with a try/catch block and ask them to trace through
the code's execution in both the case where an exception was thrown and the
"happy path". Roughly 40% of the people I've interviewed who have claimed
years of recent Java experience (like they were coding in Java the day before)
think that a method's execution terminates when a catch block is entered and
that block's code finishes executing! How could one possibly write correct
code without understand this? How much evidence to the contrary must they have
ignored? One developer complained to me that my question was hard because he
was "mostly used to dealing with SqlException and not other exception types."
He then complained that he was an experienced Java developer and didn't see
how my question was relevant to the job for which he was interviewing. Want
him on your team?

~~~
kamaal
Aha,

Here is the problem. The days of deep reading and understand and learning are
behind us. IDE's really know what is good for what situation and just
autocomplete whatever is appropriate. The days when you had to read the manual
at every unknown point and besides text based autocompletion in Emacs/Vi no
other help from IDE's are long behind us.

Most programmers todays are all about such things. In other words and putting
it very directly. Productivity has become an order of an magnitude more
important than knowledge and intelligence.

That is partly also because a lot of work needs to be done today than it was a
decade back. And when the ecosystem grows at such a rate tools to enable the
common folks program get invented.

These days its all about productivity.

EDIT : Downvote this as much as you like, but more the frameworks and more the
intelligent IDE's get. Lesser and lesser significant our jobs become.

In fact to an extent they already have.

~~~
Drbble
The more my IDE does, the more I am expected to do above and beyond what the
IDE does.

~~~
kamaal
The areas above and higher your IDE are/will be little to do with math and bit
shifting.

They will be more and more of domain knowledge and understanding the problem
on hand and little and little to do with worrying and learning arcane facts
behind the scenes.

Some applications may need it but most won't.

~~~
jroll
How do you figure that knowing the execution path for a basic language feature
is an "arcane fact behind the scene?" This is equivalent to not knowing how an
if or for statement works. You can't write ANY code without this knowledge.

~~~
kamaal
How were we able to understand try/catch while all we had known is return
statements from functions and error checking through flags?

How were we able to understand if/else statements now, while all we were able
to understand jmp and goto statements earlier.

How can people work with Microsoft excel without actually knowing they are
into databases and functional programming?

First you learn how to use a logical block of programming, then you learn many
other blocks. Then you learn how to use them together. Then many interacting
blocks come as a pre packaged solution to a lot of problems. Assembling those
blocks comes in the forms of of IDE's. That is how we have managed to move
from bits, to assembly language programming, to languages lisp, C and till now
where IDE's do most of what we do.

If you had asked anybody 50 years back if we could have come this far. Their
answer would be no. Same as many people today can't believe that programming
can be done without actually writing code syntactically.

You can do a lot of network programming today or IO programming today without
knowing anything about OS or deeper networking aspects. You could not have
told the same thing 15-20 years back. The average skill required to achieve
these tasks is only decreasing.

On an average scale the skills, knowledge and work required to be a good
programmer over 50 years has only decreased.

In the future, the solution to a problem doesn't necessarily has to be a code.

Haven't we seen Yahoo Pipes and things like that?

I can understand this attitude that most people are showing, because it
effects their bread and butter. But this is the natural progression in any
discipline.

I doesn't take an army of farmers and cows to do farming today. Farming is far
more productive today than it was 100 years back.

The same case will be with software. Like it or not, it is going to happen.

------
code_pockets
I've developed a simple set of questions to avoid these types of pointless
interviews.

It was last tested about two weeks ago when I was casually talking with the
founder of a local startup who wanted me to join his team. I politely declined
the offer.

Here are the questions:

1\. What is your product?

If the answer to this is marketing talk, they fail the test.

2\. Who is your customer?

Same with #1, but add "everybody!".

3\. What is your development setup/rules/guidelines?

No source control? Bye.

Testing on production servers? Bye (this startup did that, and wondered why
their app failed to work).

No workstations? You mean that I will use my personal computer at your office?
Bye, Bye!

What language/framework/technology do you use? If the answer is PHP/in house
MVC then I'm out. I dont mind PHP/MVC, but most are hacked up pieces of crap
that can't compare to symfony or even code igniter/cakephp.

This allows me to consider working with people who know what they are doing,
instead of wasting time with people who want to test me on what they think I
know.

This simple test was developed after an interview with a local startup. The
interviewer was the "software engineer", and he had pulled questions from
project euler to test me. After realizing this, I ended the interview quickly.
Their product? A web app for realtors to showcase their listings. Yeah, that
required developers that were able to solve advanced project euler exercises.

~~~
hn_reader
It's hard for me to believe there exist companies that have the resources to
hire software developers and that don't use source control.

~~~
Bootvis
You better start believing it, I've seen it... If you doubt my anecdata, check
TheDailyWTF.

It seems to me that the problem is too many people see software development as
linear and quality as monotonically increasing, i.e. just save your work and
back it up.

------
masterponomo
I was being tag-team interviewed for a programming job. The first guy asked me
what I disliked about my current workplace. I said, "Nothing," because money
was my only reason for leaving. He didn't believe I couldn't find one negative
thing to say, and made bold marks (probably a big "X") on a paper. In the next
interview, a lady manager asked me the same question. Not wanting to make the
same mistake twice, I said, "Office politics," and sat back smiling, ready for
the next question. She frowned and said, "Define office politics." I said,
"Umm..habbadababbadah...gah..er," until she decided to move on to another
question. I got the job!

------
kenrikm
Start asking me about B-tree algorithms and my eyes will glaze over. However
you can go and look inside my MySQL database tables and you will see a
beautiful relational database. I enjoy computers/programming because going
back as far as I can remember I have never run across a problem that I could
not figure out with enough gray matter time. I really enjoy making stuff and
solving problems, I used to do all of my math homework in my head and then
have to go back and write out the solutions (for the teacher to check) just
because I enjoyed solving the problem step by step.

TLDR: I build stuff, it works and I smile.

~~~
tonyarkles
Not that I don't believe you, but I'm genuinely curious.

When you're designing a "beautiful relational database" without thinking about
the algorithms behind it, how are you taking the performance effects of those
algorithms into account? How do you know which relationships and queries are
likely to be efficient and which are not?

~~~
Drbble
Parent is talking about beautiful schema, not a beautiful query planner. If
you are capable of understanding the concept of abstraction and encapsulation,
you can design a good system knowing the performance characteristics of your
components but not their internals.

The geniuses who wrote postgres don't know how to write responsive web sites.
The geniuses who make gorgeous fast websites don't know how a Btree is
implemented. It's OK. That's how the global economy works.

~~~
xsmasher
But the fast-website people still need to know what makes a query slow and how
to improve it. They don't (and shouldn't) write their own database engine, but
they need to know how their equipment works.

------
gruseom
The deeper problem is that job interviews are irremediably broken. They are
artificial to the point of stupidity. At least for the kind of work we do in
software, there is no fixing them. They need to be thrown out and replaced
with something else.

Working together is a kind of relationship. You don't interview for a
relationship.

~~~
zwischenzug
Sure you do - it's called a date.

After an interview/date, you then have (in the UK at least) a probationary
period (going steady), and then a wait before a statutory period (engagement)
before you are fully "employed" in law and can't be removed easily (marriage).

~~~
gruseom
Your analogy confirms my point, because the things that make job interviews so
awful are not things people do on dates - not without being crushingly
inappropriate. What you're talking about, it seems to me, is contactful
conversation. That's precisely what job interviews are not, and that's the
problem.

In fact, the dating analogy points toward a saner way for small organizations
(as most software teams ought to be) to find people. Get to know one another
in a relaxed way. See if there are common interests and values. Do things
together. Eat and drink. This is how humans behave.

There are other analogies to look at too - auditions might be one.

~~~
mason55
The problem is that it's much more costly to make a bad pre-hire, if that's
what you want to call it, than it is to go on a bad date.

You can't just bring someone in and let them be their self in the office. You
have to have someone onboarding their HR stuff, someone onboarding them on to
the technical stuff, someone getting them a laptop and access to source
control, someone answering their questions, someone tasking them with things.
All this takes time away from people who could be making the company money.

You can start reducing these things (don't give them access to source control,
give everyone the same initial tasks) but now you're just reducing it back to
a job interview.

~~~
gruseom
Maybe, but the status quo is a reductio.

What's the biggest problem for software companies right now? Attracting good
programmers. That's true of startups, anyway, and as startups go so goes the
industry. What that tells me is that those who get ahead of the curve and
figure out how to grow teams better are going to have an edge. This is a big
deal, and job interviews suck so badly that there is room for innovation.

------
rimantas

      > “I’m an egomaniac who has spent vast amounts of time
      > Googling this nearly useless knowledge, but will ask
      > you to regurgitate it to me without the aid of a search
      > engine, and then judge you on how much it makes you
      > sweat.
    

He chose the example wrong. That list is really good — and the knowledge is
far far away from being _useless_. Unless you want your "experienced"
developer to spend hours trying to figure out, why layout is broken, just
because he knows nothing about quirks mode and how doctype influences that. Or
maybe you prefer your web app really slow, because your developer does not
know about event bubbling and created and event handler for every single cell
in your table, instead of having a single one? There are some questions over
the top in the list, but most of it is pretty solid.

------
scriby
Developers hire other developers that think like themselves.

Technically oriented developers hire other technically oriented developers.

A mediocre developer won't be able to distinguish who knows their stuff or
not. But at least getting team fit / communication / personality right is half
the battle.

------
mattmiller
This spirit of the article is good, but two of the three example questions are
bad. I ask candidates about projects on their resume. I ask them deeper
questions about those projects. Many people get excited about cool things they
have built and will tell me about all the details.

If you cannot clearly explain the interesting details of a project you should
be familiar you are either not that smart, are taking credit for an entire
project that you were only a small part of (this happens pretty often) or I am
too dumb to understand the concepts (I like to think I am pretty smart and
this never happens).

I also ask why they want to work here. Many people don't really know and that
is OK. Many want to move into management, although they will never say it
directly, and that is usually a red flag.

------
revelation
Apparently, the one core qualification for software development is to write
radical, but philosophical articles to no end about it.

------
ricardobeat
> _All these questions do is scream, “I’m an egomaniac who has spent vast
> amounts of time Googling this nearly useless knowledge_

Quite the opposite. The original list of questions _is_ absurdly long, but it
is an amazingly precise synthesis of what a good front-end developer should
know. The three questions proposed are not nearly enough for hiring someone
technical. You _need_ to probe for knowledge, that will make passion and
interest surface.

------
maeon3
When interviewers start lobbing questions that have no relevance to what it
means to be a programmer, just smile sympathetically and relax, act like you
have just been informed you will be required to work with passionless
programmers.

What will blow your mind is that you can ace these interviews without being
able to write a line of code to save your own life. Just do what Ken Jennings
does when he practices for jeopardy: memorize every esoteric fact you can
find. This is not a small task, I built a Web app to store and randomly quiz
myself on all potential questions in a domain. I have about 9000 factoids in
there, I wow the pants off these non programmers, and made the mistake of
picking a place that refucture the codebase and I have to scurry around to fix
it or they will use their political connections to blame the problems on me.

After they are done playing jeopardy with you give them the Joel test, they
will get a 3 or 5 of 12.

~~~
Drbble
You cleverly designed a system to con your way into a job you knew you would
hate? Congratulations....?

~~~
maeon3
You just conned a comment into HN. How do you feel about that? And what is
your view on loaded questions?

