What not to ask technical people in interviews

http://www.fusioncube.net/index.php/what-not-to-ask-technical-people-in-interviews

by joeyespo • 14 years ago

93 68 14 years ago

maeon32• 14 years ago

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.

Drbble6• 14 years ago

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

maeon32• 14 years ago

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

blindhippo3• 14 years ago

"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.

angersock4• 14 years ago

Here, let's grep and replace:

"The dirty little secret that I don’t mind saying is that mechanical engineering 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 stress equation or tool. Follow it step by step and you are a mechanical engineer."

This is pretty common in professional engineering--most bridge/pressure vessel/structural engineering is done by effectively filling in the blanks on worksheets and following thick handbooks of best practices. Are they too worth your contempt?

Self-respect doesn't enter into it--computer science might be hard, mathematics might be hard, clever low-level or very abstract programming might be hard...but software development? Especially as practiced nowadays with the toolsets and parts we are encouraged (nay, expected!) to use?

No, software development need not be any harder than any other form of white-collar engineering.

WalterBright3• 14 years ago

It isn't that much different from other forms of engineering. And in all of those forms, there are the "formula plugger" engineers, and there are the real engineers.

The difference was exemplified by a question another "engineer" asked me once - "what book did you get that formula from?" I replied that I derived it from the boundary conditions, etc. He just looked at me in utter bafflement.

On a related note, it's easy to discover the "formula pluggers" in electrical engineering. They are the ones that carry around a little card with:

   V=IR
   I=V/R
   R=V/I

helpfully written on it.

felipemnoa• 14 years ago

So what is going to happen when you are asked to design (or dare I say "engineer") a system of some sort from scratch? Say, an engine or a component of an engine or a complete new machine? That is engineering. What you described sounds like the duties of a technician or a mechanic. That is not engineering.

paganel• 14 years ago

> 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.

angersock4• 14 years ago

And it's never the same half of the mistakes, is it? :(

That's the thing that annoys me about software engineering--it's impressive that it works at all, and that isn't a good sort of impressed.

AznHisoka• 14 years ago

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.

jff3• 14 years ago

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

This is the dirty secret of outsourcing.

blindhippo3• 14 years ago

And the dirty secret of outsourcing is that it very rarely goes the way people want it to go and the low paid googlers end up being replaced by very expensive experienced software developers.

Drbble6• 14 years ago

"low paid googlers" is an interesting phrase. Took me a moment to get it, and disambiguate from "high-paid Googlers"

kamaal7• 14 years ago

We, with our very hands destroyed this when we started inventing IDE's that had intelligence to do nearly everything that had to be learn't to be done other wise.

We invented frameworks to cover large number of solutions to problems.

Its something like this. There was a point of time among mechanical engineers when knowing how to assemble and sweating it making things in the workshop was glorious. Today most of those jobs are inevitably automated. And apart from design and actual engineering. Most mechanical engineers can be clearly separated from foremen and workshop guys.

The same is happening with software, IDE's and frameworks are making it damn easy for any idiot with vague ideas to program things into existence. Soon coding in itself will not be a very task in itself.

At this rate its scary to imagine how future generation of programmers will even program. They may just deal with visual interfaces which generate programs in the backend.

This is sad but inevitable in every discipline of engineering.

xsmasher2• 14 years ago

If any average Joe can make something that works, then the true and valuable skill is to make something that is simple, understandable, and maintainable.

I don't think modern tools help you with any of the constant decisions needed to hit those marks.

kenrikm2• 14 years ago

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.

tonyarkles4• 14 years ago

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?

kenrikm2• 14 years ago

What I was trying to get across is that knowing the correct term for something and actually knowing how to do it are two different things. I run across stuff all the time in CS where I'm like huh? what's that? then I google it and find out "oh so that's what you call the way that I did "X" in "Y" application.

Drbble6• 14 years ago

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.

eligottlieb2• 14 years ago

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.

rickmb• 14 years ago

In other words, you will do what 99% of all applicants will do, even the ones that didn't really want the job in the first place: you'll tell the interviewer what you think they want to hear.

The lesson here is: "asking questions" does not equal "having a conversation". No amount of lists, short or long, will result in a good job interview.

eligottlieb2• 14 years ago

>In other words, you will do what 99% of all applicants will do, even the ones that didn't really want the job in the first place: you'll tell the interviewer what you think they want to hear.

Well no, I tend to do the Luciferian thing: tell the complete truth and let them hear what they please.

This has, in its time, lost me a couple of opportunities because they didn't want someone who was aiming for research rather than aiming for their position. Of course, those opportunities were in entry-level software engineering positions.

blindhippo3• 14 years ago

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• 14 years ago

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.

Drbble6• 14 years ago

Bitterness is extremely easy to detect and is one of thered flag culture-fit no-hire reasons at my office.

Passion is passion. Bad pay is bad pay. They are orthogonal.

anonymoushn• 14 years ago

The questions proposed in the article seem to be optimized to produce the most bullshit responses.

Drbble6• 14 years ago

Some of us are looking for grad school eggheads, and pay a lot for it.

gaius• 14 years ago

Did you really want to hear about my love of outdoor Humans vs Zombies games

My personal experience as an interviewer: there is a very high correlation between people who are really into something and people who are good hires. Ideally something that requires some suffering to do well (e.g. sports) but what I'm looking for is that whatever it is, they feel strongly enough about it to pursue it doggedly for years at a time.

masterponomo• 14 years ago

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!

revelation• 14 years ago

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

gruseom3• 14 years ago

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.

zwischenzug2• 14 years ago

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).

gruseom3• 14 years ago

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.

ricardobeat• 14 years ago

> 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.

aero1422• 14 years ago

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.

jff3• 14 years ago

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.

aero1422• 14 years ago

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.

scriby• 14 years ago

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.

ShabbyDoo2• 14 years ago

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?

kamaal7• 14 years ago

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.

Drbble6• 14 years ago

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

ShabbyDoo2• 14 years ago

>IDE's really know what is good for what situation >and just autocomplete whatever is appropriate.

If people claim to be doing something everyday which requires detailed knowledge of X, they ought to be able to tell me about X. An IDE can't know if a List or Set is more appropriate. To know this, it would have to know my intent. I agree that higher-level abstractions (declarative statements implying the need for one over the other, etc.) might be in our future, but the people I'm interviewing claim to be writing Java. I don't expect a Java developer to know any particular processor's instruction set, but I sure would expect, say, a person who recently wrote an x86 assembler to have detailed knowledge in this area.

mattmiller• 14 years ago

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.

code_pockets• 14 years ago

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• 14 years ago

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• 14 years ago

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.

rimantas• 14 years ago

  > “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.

What not to ask technical people in interviews

Related Stories