10 ms·

What not to ask technical people in interviews

93 points by joeyespo 15y ago

maeon3 15y 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.
- Drbble 15y ago
  You cleverly designed a system to con your way into a job you knew you would hate? Congratulations....?
  - maeon3 15y ago
    You just conned a comment into HN. How do you feel about that? And what is your view on loaded questions?
blindhippo 15y 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.
- angersock 15y 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.
  - WalterBright 15y 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.
    - angersock 15y ago
      The problem here is that in things like chemical or structural engineering, you generally don't just bodge together things by first principles. In fact, there is a great deal of liability on the line--so much so, for example, that the guild (for what else is something like the ASME, really?) has decided "Here are the equations by which we design pressure vessels. Plug in your material--from this table of guaranteed grades and empirical data--and your dimensions, and lo, here's what you should spec." As wonderful as it is to derive these things from equations and first principles, and as satisfying as it is to do so, do you really want to stake your career on your own from-scratch solution to a CFD problem? Or on the exact solver that you used to solve those PDEs? Or on your "hunch" as for which forces were truly at play? Or do you want to follow the guidelines in Shigley's, Roark's, ASME codebooks, NACA airfoil reference, etc., and be able to more easily pass through a forensic engineering post-mortem? Electrical engineering and computer science may not have had the same checkered history as some of the more established disciplines, but that doesn't mean you can't learn something from their rigor.
kenrikm 15y 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.
- tonyarkles 15y 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?
  - kenrikm 15y 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.
  - Drbble 15y 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.
    - xsmasher 15y ago
eligottlieb 15y 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 15y 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.
  - eligottlieb 15y 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.
- blindhippo 15y 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.
masterponomo 15y 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 15y ago
Apparently, the one core qualification for software development is to write radical, but philosophical articles to no end about it.
gruseom 15y 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.
- zwischenzug 15y 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).
  - gruseom 15y 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.
    - mason55 15y ago
      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.
ricardobeat 15y 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.
aero142 15y 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.
- jff 15y 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.
  - aero142 15y 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.
- wbienek 15y ago
  A lot of people don't like people who do the bll sht tech questions because like me they don't have a college degree and it rubs em (me) wrong when you bounce them out of an interview when they're able to make 2-3-5x more money than the interviewer!... Not that I ever applied anywhere but once... I tried, but didn't get hired for a crap 26k a year job at a college about 6 yrs ago. They didn't hire me. Now I make almost 400k a year and absolutely lothe the "college" educated who weren't smart enough to hire me in the first place. I wasn't smart enough/worth a stupid 26k yr IT job at a small private university as an admin but 2 yrs later I was making 129k a yr and now I make almost 400k w/ no employees. College ilk can die on the street homeless as they would have left me all those years ago if they would have had it their way. No pity for them and their loans. No pity at all. They would have left me to die if they had it their way. They can suck a big one.. If your not part of their club, too bad. Well let them for in their loan debt.
scriby 15y 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.
ShabbyDoo 15y 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?
- kamaal 15y 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.
mattmiller 15y 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 15y 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 15y 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 15y 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 15y 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.

93 points by joeyespo 15y 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.

Drbble 15y ago
You cleverly designed a system to con your way into a job you knew you would hate? Congratulations....?
- maeon3 15y ago
  You just conned a comment into HN. How do you feel about that? And what is your view on loaded questions?

blindhippo 15y 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.

angersock 15y 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.
- WalterBright 15y 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.
  - angersock 15y ago
    The problem here is that in things like chemical or structural engineering, you generally don't just bodge together things by first principles. In fact, there is a great deal of liability on the line--so much so, for example, that the guild (for what else is something like the ASME, really?) has decided "Here are the equations by which we design pressure vessels. Plug in your material--from this table of guaranteed grades and empirical data--and your dimensions, and lo, here's what you should spec." As wonderful as it is to derive these things from equations and first principles, and as satisfying as it is to do so, do you really want to stake your career on your own from-scratch solution to a CFD problem? Or on the exact solver that you used to solve those PDEs? Or on your "hunch" as for which forces were truly at play? Or do you want to follow the guidelines in Shigley's, Roark's, ASME codebooks, NACA airfoil reference, etc., and be able to more easily pass through a forensic engineering post-mortem? Electrical engineering and computer science may not have had the same checkered history as some of the more established disciplines, but that doesn't mean you can't learn something from their rigor.

kenrikm 15y 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.

tonyarkles 15y 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?
- kenrikm 15y 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.
- Drbble 15y 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.
  - xsmasher 15y ago

eligottlieb 15y 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 15y 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.
- eligottlieb 15y 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.
blindhippo 15y 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.

masterponomo 15y 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 15y ago

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

gruseom 15y 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.

zwischenzug 15y 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).
- gruseom 15y 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.
  - mason55 15y ago
    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.

ricardobeat 15y 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.

aero142 15y 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.

jff 15y 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.
- aero142 15y 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.
wbienek 15y ago
A lot of people don't like people who do the bll sht tech questions because like me they don't have a college degree and it rubs em (me) wrong when you bounce them out of an interview when they're able to make 2-3-5x more money than the interviewer!... Not that I ever applied anywhere but once... I tried, but didn't get hired for a crap 26k a year job at a college about 6 yrs ago. They didn't hire me. Now I make almost 400k a year and absolutely lothe the "college" educated who weren't smart enough to hire me in the first place. I wasn't smart enough/worth a stupid 26k yr IT job at a small private university as an admin but 2 yrs later I was making 129k a yr and now I make almost 400k w/ no employees. College ilk can die on the street homeless as they would have left me all those years ago if they would have had it their way. No pity for them and their loans. No pity at all. They would have left me to die if they had it their way. They can suck a big one.. If your not part of their club, too bad. Well let them for in their loan debt.

scriby 15y 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.

ShabbyDoo 15y 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?

kamaal 15y 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.

mattmiller 15y 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 15y 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 15y 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 15y 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 15y 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.