8 ms·

On Interviewing Software Engineers

114 points by brown9-2 11y ago

siegecraft 11y ago
"All existing interview techniques are bad because they're just about proving the interviewer is smarter than the interviewee. Now let me tell you why my interview technique is so much better and I am so much smarter than those people."
- pinewurst 11y ago
  Substitute kinder and more considerate for that second "smarter". I've had successful interviews where I felt like garbage and unsuccessful ones that left me feeling good about the experience. Both kindness and consideration override a waterboarding about the decisions behind variable names.
- JoergR 11y ago
  You have trouble with reading comprehension...
- kamac 11y ago
  I think it's your personal impression, because I didn't feel like the author was bragging about how great his method is.
  - siegecraft 11y ago
    Eh, maybe bragging is too strong of a word, but it did feel rather hypocritical that he propped up the straw man that interviewing was all about making the interviewer feel smarter than the interviewee. Then proceeded to tell an anecdote about how he was smarter/better than all the other people interviewing a particular candidate.
    - luckydude 11y ago
      I didn't get that from his writing. Yes, you can look at it that way but it's perhaps cynical. I thought he was genuinely trying to say here is a better way. You should read it again. He's talking about kindness and giving people space to come out their shell (amongst other things). That's not him bragging, that's him helping the interview go well (if it can). Shrug. I thought it was a good article.
matthewcanty 11y ago
When did grey text become so fashionable? I can hardly read it on my phone. On desktop found this app to adjust contrast per-website: https://chrome.google.com/webstore/detail/high-contrast/djcfdncoelnlbldjfhinnjlhdjlikmph/related?hl=en https://chrome.google.com/webstore/detail/high-contrast/djcf...
buckbova 11y ago
If every job seeker was 100% honest about their skills and experience we wouldn't have to go through this nonsense.
- Tenhundfeld 11y ago
  100% honest AND 100% correct. Many of the best developers I've worked with underestimated their abilities, and many of the worst overestimated. Experience can be similar too. Many of the best see themselves "merely" as an important contributor to a team effort and remember the mistakes they made, etc. Many of the worst honestly believe they did a great job, led the effort, etc.
  - rogerbinns 11y ago
    > Many of the best developers I've worked with underestimated their abilities, and many of the worst overestimated. That would be the Dunning-Kruger effect in action https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
brightball 11y ago
Interviewing programmers is easy. Get them to talk about something they've done that they were proud of and let them explain how they did it into the deep details. Good programmers really enjoy talking about the details of the technology and how they solved challenging problems. You'll be able to see them geek out a little bit and see that they really enjoyed getting to do it. Outside of baseline, core competence, that is the litmus test for hiring good programmers because it shows level of interest. Level of interest leads to continuous learning, which is essential to this field. Unless you have some ego-driven reason why you want to believe that YOUR stuff is too complicated for them to learn of course...but that's usually more of a reflection on you than them. I realized this about 5 years ago and I've not made a single bad hire with the approach since. 100% success rate at this time.
- forrestthewoods 11y ago
  A good resume is a trick. A trick designed to get an interviewer to ask about something on it. Because every item is something that you can talk about with passion and detail for as long as you want or need.
- krisdol 11y ago
  >Good programmers really enjoy talking about the details of the technology and how they solved challenging problems. You'll be able to see them geek out a little bit and see that they really enjoyed getting to do it. I've had this at several companies. I think I've always gotten past this litmus test in one of the interviews, be it on the phone, via Skype, or in person. The problem, for me personally, is the inevitable followup interview consisting of "go to the board and scribble out a function that does X", and then of course "after you're done, I'll add important details and I expect you to be able to modify the function to accommodate as if you were using a text editor". I admit it, I fail at the "get in front of the board" problems. I'm downright terrible at them. I have no problem with the conversational interviews. I'm not bad at presenting tech to my peers at meetings and book clubs, but in an interview environment I'll freeze up and, at best, come up with a very inefficient implementation. I hate it and it has probably cost me opportunities at places where the rest of the interview felt like it went great. Yes I know what the Big O is, I know what the Big O of the optimal implementation would be. I can talk all about hashes, final, static, or whatever you think you'll trip me up on. But when I'm up there writing code, every little mistake psyches me out more and more, especially I can't just hit "backspace" to fix it. At my previous job, after the phone interview they sent me a programming project to implement in a day or two. After submitting it, they had me go to an interview and talk about the solution with a group of engineers, followed by a short conversational interview. That project was my first time writing ruby and I got the position and have great recommendations since leaving the place. Makes me wish that recommendations held more sway, or that more companies would do more of this "here's a task, send us the solution when you're done with it" type of thing. Dishonest candidates would easily be exposed when they're forced to discuss the solution in depth. Of course, upon walking out of the building, all the answers magically pop into my head...
angersock 11y ago
I think the comic sums up pretty well how stupid and broken large parts of our industry are--99% of the time we're fighting dumb things like bad CSS or sudden design changes or something else. It really makes me wonder if our tools are broken, if we're all trying to solve the wrong problems, or if we simply are hiring too many people for whatever the project is.
edw519 11y ago
8. Have them code. For me, nothing else comes close to evaluating talent. I prefer making my candidate comfortable and writing something simple. 15 minutes, privacy, a drink, and pencil & paper. I hate white boards for this. I come back & see what they've done. It doesn't have to be perfect. It doesn't even have to be right. I am less concerned about their code than our discussion about their code... How did you approach the problem? Why did you name your variables like this? What is that supposed to be doing? What happens if...? What would you change if I added <x> to the problem? How else could you have done this part? Why did you choose your way? 15 minutes of coding followed by 15 minutes of Q & A about their code tells me alot. Not everything, but alot. And no programmer, no matter how nervous or introverted, should have a problem with this. As a matter of fact, most of the best programmers I've interviewed have embraced and enjoyed this. Fizzbuzz is a great problem for this. I'm still amazed by how many "experienced" programmers can't do this.
- prht 11y ago
  violated pen & paper, left the interview
- matthewmacleod 11y ago
  That's appealing. If you handed me a pen and paper and asked me to code, I'd leave. It bears essentially no relation to my work day-to-day.
  - edw519 11y ago
    Thanks for proving my point. If you won't code for me in an interview, why would I possibly be interested in you? Thanks for saving me so much time.
    - deleted 11y ago
      [deleted]
      - edw519 11y ago
        Everyone and their dog is trying to hire me. Good. Go work for them. My "prima donna" filter is working nicely.
victorhn 11y ago
> Or write a function that takes an integer and returns that integer's index on the Fibonacci sequence. That last example: they wanted me to do this with pen and paper over the phone. I fail to see what is the difficulty on that, looks like very straightforward and easy question to do, even over the phone.
- rilita 11y ago
  I think the focus was on the fact that it is arbitrary. The person you are interviewing may not even know nor want to care what a Fibonacci sequence is. He is saying the goal is to understand the candidate and the way they think, not to trivia them about random stuff ( since it will put them down if they don't know it )
rilita 11y ago
I've seen a lot of writeups about interviewing here on hacker news. Things I liked in this particular one: - Admission that arbitrary coding challenges that are unrealistic to the applied job are ridiculous - Recognition that you need to understand the engineer and approach things from their point of view, not from your own selfish view as the interviewer - Urging that being polite and humble is important. Even if you don't like the candidate, there is no need to attack or diminish them. One question I have: What is wrong with copying and pasting solutions to issues that have been solved before by others? I tend to do this all the time myself ( albeit I often end up rewriting the solutions to tailor them more to the problem ) Overall decent suggestions for interviewing.
jmcgough 11y ago
This is the biggest thing I struggle with - people confuse interview anxiety on my part with lack of knowledge or experience. You immediately look like a junior engineer if your mind keeps going blank on technical questions (that you know the answer to) or if you downplay your own accomplishments. Interviewing feels like a crap shoot at times, because it's entirely dependent on me being able to force myself to be extroverted and confident. However, I have a lot of respect for companies that do interviewing well (testing skill and experience in a less contrived and awkward manner), and the ones that have made the process as painless as possible tend to be well-run companies. You can learn a lot from the process with each company, especially at an on-site. Dick-swinging contests definitely happen, which to me means that the company values rock star coders over programmers who are skilled, pleasant to work with and good at communication (and moves to the "won't accept offer" pile).
- hasenj 11y ago
  > people confuse interview anxiety on my part with lack of knowledge or experience Sounds like a bad excuse to me. If you get nervous on simple coding questions, how will you perform on your daily work? Unless you're applying for a very junior position, chances are your work will involve plenty of technical discussions.
  - jogjayr 11y ago
    Because you don't have to write code on a whiteboard with someone staring at you in your daily work. You're free to sit alone, make a stupid off-by-one error, misspell a var without feeling like you'll be fired for it. Technical discussions at work aren't so high-stakes as ones in an interview. If you do badly in an interview, you've wasted an entire day for nothing. If you fail to speak in a technical discussion at work, best case no one notices, worst case they think "Hm. Looks like Brian didn't get much sleep last night". Just the knowledge of these stakes can affect your performance.
  - jmcgough 11y ago
    I have pretty bad social anxiety, which is never a problem in my day-to-day work, where I know and trust the (awesome) people I work with. I'm more stressed having to meet a dozen people over a very brief period of time than I am fixing a failing production server, but I do perfectly fine at the interview as long as my anxiety isn't bad that day (by the 2nd or 3rd company I've spoken with, I start to get more comfortable with it). I'm interviewing right now and all except one have lead to offers, so no, I'm actually good at my job. I'm just a better engineer than I am an interviewee.
klenwell 11y ago
I got excited when I saw the cover of Thinking Fast and Slow. But he failed to mention what I found to be one of the most insightful parts of that book: interviewing. He kinda touched on it at the end with #1: "Know what you're looking for". Kahneman is more explicit in Thinking Fast and Slow: come up with a simple rubric of 5 or 6 traits you're looking for in your new hire and ask questions that allow you to score each candidate on a scale of 1 to 5 for each. When you're done, choose the candidate with the highest score. Maybe the technical ability score gets double-weighted for developers. But it seems like a lot of the interview process (and discussion of it) fixates on this. Well this and, of course, vague impressions of the candidate's personality. In my experience, this misses other key things that make up a competent programmer and worthwhile employee. In the spirit of Thinking Fast and Slow, here's a question. As an interviewer, what are the 5 most important traits or qualities you look for in a candidate?
- zdfs 11y ago
  I'm still working my way through the book, but glad to know he touches on this.
panamafrank 11y ago
So if interviewing is about finding the good hires, what's a bad hire?
deleted 11y ago
[deleted]
sombremesa 11y ago
I work at what can only be defined as a megacorporation. The interview process is a machine, and more often than not interviewers are not personally invested in the process as much as they could be - the candidate is destined to be on someone else's team. This is of course a double edged sword - on the one hand you only have a generic sense of what you are looking for and on the other you have no vendetta for hiring someone who is sub-par to fill your urgent needs.
dmansen 11y ago
In every challenging software development job, you'll be solving problems you've never encountered before. That's the nature of software. Once you understand the problem, you move on to something else. So, why is it such a stretch to ask people to solve Fibonacci? I don't understand this mentality. Reminds me of "why should I learn calculus? I'll never use it in real life!" from college. You're supposed to be a professional software developer, and should be able to handle an unfamiliar problem. If you're a professional musician auditioning to play Mozart, you wouldn't complain that your audition piece is Beethoven.
- vonmoltke 11y ago
  > In every challenging software development job, you'll be solving problems you've never encountered before. The problem is, the vast majority of software development jobs are not this. That was the point of the comic in the post. There is a whole lot of maintenance, API gluing, and spec work that needs doing. Even at the "elite" companies like Google. The current trend in hiring seems to be at least partially born of Google's ill-advised[1] strategy of hiring generic software engineers that could theoretically be slotted into any role at the company. Hire for a position. If that position involves challenging, novel problems then throw things like that at the candidates in the interview. If it doesn't, don't. [1] After they reached a certain point as a company
iblaine 11y ago
Interesting post. This author lives in Santa Barbara. Hiring in SB is vastly different than it is in SF. Due to the small pool of companies and talent, everyone knows everyone. So there's not much mystery to it.
zdfs 11y ago
Thank you to everyone for reading (whether you agree or not).
krschultz 11y ago
The single best thing I've done when interviewing is ask people to bring a laptop with some of their code on it. I don't care the language o the framework. I don't care if it was school, side project, or even their current job. It puts people on their home turf, where they are most confident and comfortable. They can show me what they are proud of. I can ask lots of questions about it and see their thinking without having to be a total dick asking for an esoteric algorithm on a white board. There's also a lot to be said for how well someone know show to use their tools. Are they navigating proficiently, or are they poking around the IDE like they just started out. This sounds like a softball interview, but you would be amazed the number of people it weeds out. You probably need something more rigorous beyond that, but don't start with the hard problems when an easy filter can really give you a lot of insight. (Note that generally you can't share your current job's code, but people are fairly comfortable opening their own laptop and poking around in the code. I never ask for people to send me that kind of code).
kzhahou 11y ago
Let's talk about BRAIN FREEZE. And I mean the total, complete, 300-baud mush when some question --for whatever reason-- kills your ability to think. I've had it happen twice, and man it ain't fun. The second was like an out-of-body experience. I forgot the question, I forgot my train of thought, I knew I wasn't responding, I knew that I knew that the interview knew that I was just sitting there, saying "ummmmmmmmmm" for about 147 seconds now. Yikes! Yet in day to day, these would have been easy questions. And TBH I didn't even want to job at that point. It's critical that you as an interviewee learn to monitor and CONTROL your physiological response to stress. And I've learned that as an interviewer, I try to pay close attention to physical stress responses from the candidate -- flushed cheeks, signs of sweat, sudden lock-up -- when I see these signs, I back off and let them come back to normal first.
xamuel 11y ago
I find these whiteboard problems a breath of fresh air. Coming from an academic background, I've seen the downsides with the alternatives. * Talking about something you've done? You're selecting for marketing, not programming. * Letters of recommendation? You're selecting for ability to network, not programming. * Academic qualifications? You're selecting for persistence, not programming. * Offline tests? OK right now because they're a minority, but I guarantee if they became the standard, you'd get an astounding amount of cheating. I'm not a marketer and I really resent how in academia to have any chance you have to "sell sell sell". I appreciate anyone who gives me a chance to just objectively demonstrate my abilities, whether I do well or whether I do poorly.
- brightball 11y ago
  "Talking about something you've done?" EXPLAINING something you've done.
  - xamuel 11y ago
    It's still marketing. "Something you've done" could be the 'is-negative' repo that was briefly on the frontpage today [1], and the candidate could launch into a heart-rending speech on the virtues of modular programming. It doesn't say anything about whether they can actually program. Or "something you've done" could be an incredibly sophisticated engine and the candidate isn't good at marketing and comes off worse than the first guy, despite being a top-rate programmer. [1] https://github.com/kevva/is-negative https://github.com/kevva/is-negative
    - brightball 11y ago
      You're looking for an edge case to break a hard rule. In an actual interview, when they are talking about something they've done and explaining it, the interviewer will be able to ask more questions and hopefully (as an interviewer) have enough of a technical background to separate the BS from the skills. If two chemists are talking to each other about chemistry, one's not going to be able to easily just make stuff up that the other blindly accepts.
luckydude 11y ago
Old fart here. My favorite interview question is this: Tell me about a project, any project large or small, that was 100% you. You thought of it, you coded it, you wrote the tests, you documented it. The only other requirement is that the project has to have at least 10 users who installed, used, and continue to use the project without any help from you. Lots of people don't have an answer. Some you need to coax a little, because a small project is fine. For example one that I did close to 30 years ago was move/copy utilities that used regexp. You could do move =.fortran =.f and it did what you wanted (first = is .* and second is $1 and they could repeat). Anyone with basic C skills could have done this (or perl, I think someone else did a perl version and that won). So people would think a project like that doesn't count, but it does. Small is fine, you just had to do the whole thing and people needed to be able to use it without asking for help. This covers a lot of ground and my experience is if you get lucky enough to find someone who has done projects like this, and there is at least some overlap with what we are doing, yeah, we got lucky.
- collyw 11y ago
  So would a web app I put on Heroku count? No one else is likely to install it. I could probably show it to ten of my friends and get them to try it.
drincruz 11y ago
I've noticed that there is a great number of interviewers that do not take the initiative to just be nice. I suppose they just forget that the interview process is a two-way street.
UncleChis 11y ago
One thing I find annoying is that interviewers expect you to think out loud "continuously". If I stop talking for 30s or 1 minute, I am in trouble. That is not applicable to everyone. I myself feel more confident to think in silent (may be 5-10 minutes at least) before I can tell interviewers my whole train of thought. Speak out loud what I'm thinking could easily interrupt it!!! Everyone is different!
- kelukelugames 11y ago
  You have to 1) think out loud and 2) finish as fast as you can. Those are often in conflict.
kelukelugames 11y ago
I feel like Notch because I know I will never create something as popular as my first comic. I put so much more creativity and effort into writing this post but only a few hundred people read it. http://kelukelu.me/interview/powerpose.html http://kelukelu.me/interview/powerpose.html Also, I'm embarrassed by how bad my art is. I was learning to use a brand new tablet.
edoceo 11y ago
Interviewing is actually very easy. Every job I post gets 100s of applicants - so finding them is not a problem. I've got a piece of software that lets me A/B these candidates resumes & profiles side-by-side so I rank-sort them quickly. And all "interviews" are small-boxed projects that I ACTUALLY PAY FOR THE WORK. See, most interviews are along the lines of: Q: Are you smart and good looking? A: Yes! This is why I don't really intervew all. When I take the "best" ranked applicants I give them actual work; small slices from our actual code base. I provide them a complete, functional dev environment with one restrciton: cannot commit to git. I can see their work directly, I work with them directly and get real-time data on what it's like to work with them, how they handle a project, how they communicate blockages, how they figure out our existing systems. In four to eight hours of work I know who is the right fit for our team. My cost to find and filter is very very low and rather than waste 2-4 hours per interview for 10 candidates I pay for 16-24 hours of work for 2 or 3 candidates. The hard costs are the same, it consumes less of my (or my engineers) time and the candidate fit is very good.
- madcaptenor 11y ago
  See, most interviews are along the lines of: Q: Are you smart and good looking? A: Yes! In my current company we hire a lot of developers through contracting companies. These people often have very difficult-to-read resumes - mostly because they are trying to get through filters that work based on searching for keywords, but they're rarely well-written documents even within this constraint. Fine, we're not looking to hire a writer. But a lot of these have "Communication Skills: 9/10" on them. Whether this is added by the candidate or the contracting company, I don't know.
geebee 11y ago
I really liked the cartoon. Clever, and insightful - we go through very difficult and interesting problems that are often unrelated to the job. I disagree a bit with the center pane, though (with the dog typing loops and the caption "I have no idea what I'm doing"). It is, in my opinion, very impressive to be able to find the largest sum of all square matrices in an NxN matrix at a whiteboard in 45 minutes. It's impressive enough (especially not knowing the exact question in advance) to be a positive indicator of the ability to do what is in pane 3, especially considering how many variables and logical basket weaving is often involved in moving some text a few pixels to the right. As long as you are willing to tolerate a very high false negative rate, this could be a good way to go. Unfortunately, it does mean that most developers looking for jobs will need to intensely study data structures and algorithms, and walk around with them loaded in "exam ready" memory" in a way that few people would need to simply to do their jobs. Personally, I'd say most people would retain this mental state anywhere from 1-3 weeks after a college algorithms course, provided they were a good student who understood the material. And it also means that lots of developers who could absolutely do this if they were willing to drop everything to study 50 or so hours and train at a white board will not be hired because they were more interested in just doing their jobs (which, ironically, is what they'd be doing at the new job). So we are going through a very inefficient re-taking of exams every time we interview. So I'm not surprised that some people have decided to stop interviewing, or just give up on finding a job that requires this sort of interview. It's up to a company to decide if they want to give up on hiring these developers, or to tolerate this kind of false negative rate. However I have close to zero interest in hearing about how hard it is to hire good developers if this is their approach, since it suggests to me that the aren't going to make any effort to find a way to avoid these false negatives.

114 points by brown9-2 11y ago

"All existing interview techniques are bad because they're just about proving the interviewer is smarter than the interviewee. Now let me tell you why my interview technique is so much better and I am so much smarter than those people."

pinewurst 11y ago
Substitute kinder and more considerate for that second "smarter". I've had successful interviews where I felt like garbage and unsuccessful ones that left me feeling good about the experience. Both kindness and consideration override a waterboarding about the decisions behind variable names.
JoergR 11y ago
You have trouble with reading comprehension...
kamac 11y ago
I think it's your personal impression, because I didn't feel like the author was bragging about how great his method is.
- siegecraft 11y ago
  Eh, maybe bragging is too strong of a word, but it did feel rather hypocritical that he propped up the straw man that interviewing was all about making the interviewer feel smarter than the interviewee. Then proceeded to tell an anecdote about how he was smarter/better than all the other people interviewing a particular candidate.
  - luckydude 11y ago
    I didn't get that from his writing. Yes, you can look at it that way but it's perhaps cynical. I thought he was genuinely trying to say here is a better way. You should read it again. He's talking about kindness and giving people space to come out their shell (amongst other things). That's not him bragging, that's him helping the interview go well (if it can). Shrug. I thought it was a good article.

matthewcanty 11y ago

When did grey text become so fashionable? I can hardly read it on my phone. On desktop found this app to adjust contrast per-website: https://chrome.google.com/webstore/detail/high-contrast/djcfdncoelnlbldjfhinnjlhdjlikmph/related?hl=en https://chrome.google.com/webstore/detail/high-contrast/djcf...

buckbova 11y ago

If every job seeker was 100% honest about their skills and experience we wouldn't have to go through this nonsense.

Tenhundfeld 11y ago
100% honest AND 100% correct. Many of the best developers I've worked with underestimated their abilities, and many of the worst overestimated. Experience can be similar too. Many of the best see themselves "merely" as an important contributor to a team effort and remember the mistakes they made, etc. Many of the worst honestly believe they did a great job, led the effort, etc.
- rogerbinns 11y ago
  > Many of the best developers I've worked with underestimated their abilities, and many of the worst overestimated. That would be the Dunning-Kruger effect in action https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

brightball 11y ago

Interviewing programmers is easy. Get them to talk about something they've done that they were proud of and let them explain how they did it into the deep details. Good programmers really enjoy talking about the details of the technology and how they solved challenging problems. You'll be able to see them geek out a little bit and see that they really enjoyed getting to do it. Outside of baseline, core competence, that is the litmus test for hiring good programmers because it shows level of interest. Level of interest leads to continuous learning, which is essential to this field. Unless you have some ego-driven reason why you want to believe that YOUR stuff is too complicated for them to learn of course...but that's usually more of a reflection on you than them. I realized this about 5 years ago and I've not made a single bad hire with the approach since. 100% success rate at this time.

forrestthewoods 11y ago
A good resume is a trick. A trick designed to get an interviewer to ask about something on it. Because every item is something that you can talk about with passion and detail for as long as you want or need.
krisdol 11y ago
>Good programmers really enjoy talking about the details of the technology and how they solved challenging problems. You'll be able to see them geek out a little bit and see that they really enjoyed getting to do it. I've had this at several companies. I think I've always gotten past this litmus test in one of the interviews, be it on the phone, via Skype, or in person. The problem, for me personally, is the inevitable followup interview consisting of "go to the board and scribble out a function that does X", and then of course "after you're done, I'll add important details and I expect you to be able to modify the function to accommodate as if you were using a text editor". I admit it, I fail at the "get in front of the board" problems. I'm downright terrible at them. I have no problem with the conversational interviews. I'm not bad at presenting tech to my peers at meetings and book clubs, but in an interview environment I'll freeze up and, at best, come up with a very inefficient implementation. I hate it and it has probably cost me opportunities at places where the rest of the interview felt like it went great. Yes I know what the Big O is, I know what the Big O of the optimal implementation would be. I can talk all about hashes, final, static, or whatever you think you'll trip me up on. But when I'm up there writing code, every little mistake psyches me out more and more, especially I can't just hit "backspace" to fix it. At my previous job, after the phone interview they sent me a programming project to implement in a day or two. After submitting it, they had me go to an interview and talk about the solution with a group of engineers, followed by a short conversational interview. That project was my first time writing ruby and I got the position and have great recommendations since leaving the place. Makes me wish that recommendations held more sway, or that more companies would do more of this "here's a task, send us the solution when you're done with it" type of thing. Dishonest candidates would easily be exposed when they're forced to discuss the solution in depth. Of course, upon walking out of the building, all the answers magically pop into my head...

angersock 11y ago

I think the comic sums up pretty well how stupid and broken large parts of our industry are--99% of the time we're fighting dumb things like bad CSS or sudden design changes or something else. It really makes me wonder if our tools are broken, if we're all trying to solve the wrong problems, or if we simply are hiring too many people for whatever the project is.

edw519 11y ago

8. Have them code. For me, nothing else comes close to evaluating talent. I prefer making my candidate comfortable and writing something simple. 15 minutes, privacy, a drink, and pencil & paper. I hate white boards for this. I come back & see what they've done. It doesn't have to be perfect. It doesn't even have to be right. I am less concerned about their code than our discussion about their code... How did you approach the problem? Why did you name your variables like this? What is that supposed to be doing? What happens if...? What would you change if I added <x> to the problem? How else could you have done this part? Why did you choose your way? 15 minutes of coding followed by 15 minutes of Q & A about their code tells me alot. Not everything, but alot. And no programmer, no matter how nervous or introverted, should have a problem with this. As a matter of fact, most of the best programmers I've interviewed have embraced and enjoyed this. Fizzbuzz is a great problem for this. I'm still amazed by how many "experienced" programmers can't do this.

prht 11y ago
violated pen & paper, left the interview
matthewmacleod 11y ago
That's appealing. If you handed me a pen and paper and asked me to code, I'd leave. It bears essentially no relation to my work day-to-day.
- edw519 11y ago
  Thanks for proving my point. If you won't code for me in an interview, why would I possibly be interested in you? Thanks for saving me so much time.
  - deleted 11y ago
    [deleted]
    - edw519 11y ago
      Everyone and their dog is trying to hire me. Good. Go work for them. My "prima donna" filter is working nicely.

victorhn 11y ago

> Or write a function that takes an integer and returns that integer's index on the Fibonacci sequence. That last example: they wanted me to do this with pen and paper over the phone. I fail to see what is the difficulty on that, looks like very straightforward and easy question to do, even over the phone.

rilita 11y ago
I think the focus was on the fact that it is arbitrary. The person you are interviewing may not even know nor want to care what a Fibonacci sequence is. He is saying the goal is to understand the candidate and the way they think, not to trivia them about random stuff ( since it will put them down if they don't know it )

rilita 11y ago

I've seen a lot of writeups about interviewing here on hacker news. Things I liked in this particular one: - Admission that arbitrary coding challenges that are unrealistic to the applied job are ridiculous - Recognition that you need to understand the engineer and approach things from their point of view, not from your own selfish view as the interviewer - Urging that being polite and humble is important. Even if you don't like the candidate, there is no need to attack or diminish them. One question I have: What is wrong with copying and pasting solutions to issues that have been solved before by others? I tend to do this all the time myself ( albeit I often end up rewriting the solutions to tailor them more to the problem ) Overall decent suggestions for interviewing.

jmcgough 11y ago

This is the biggest thing I struggle with - people confuse interview anxiety on my part with lack of knowledge or experience. You immediately look like a junior engineer if your mind keeps going blank on technical questions (that you know the answer to) or if you downplay your own accomplishments. Interviewing feels like a crap shoot at times, because it's entirely dependent on me being able to force myself to be extroverted and confident. However, I have a lot of respect for companies that do interviewing well (testing skill and experience in a less contrived and awkward manner), and the ones that have made the process as painless as possible tend to be well-run companies. You can learn a lot from the process with each company, especially at an on-site. Dick-swinging contests definitely happen, which to me means that the company values rock star coders over programmers who are skilled, pleasant to work with and good at communication (and moves to the "won't accept offer" pile).

hasenj 11y ago
> people confuse interview anxiety on my part with lack of knowledge or experience Sounds like a bad excuse to me. If you get nervous on simple coding questions, how will you perform on your daily work? Unless you're applying for a very junior position, chances are your work will involve plenty of technical discussions.
- jogjayr 11y ago
  Because you don't have to write code on a whiteboard with someone staring at you in your daily work. You're free to sit alone, make a stupid off-by-one error, misspell a var without feeling like you'll be fired for it. Technical discussions at work aren't so high-stakes as ones in an interview. If you do badly in an interview, you've wasted an entire day for nothing. If you fail to speak in a technical discussion at work, best case no one notices, worst case they think "Hm. Looks like Brian didn't get much sleep last night". Just the knowledge of these stakes can affect your performance.
- jmcgough 11y ago
  I have pretty bad social anxiety, which is never a problem in my day-to-day work, where I know and trust the (awesome) people I work with. I'm more stressed having to meet a dozen people over a very brief period of time than I am fixing a failing production server, but I do perfectly fine at the interview as long as my anxiety isn't bad that day (by the 2nd or 3rd company I've spoken with, I start to get more comfortable with it). I'm interviewing right now and all except one have lead to offers, so no, I'm actually good at my job. I'm just a better engineer than I am an interviewee.

klenwell 11y ago

I got excited when I saw the cover of Thinking Fast and Slow. But he failed to mention what I found to be one of the most insightful parts of that book: interviewing. He kinda touched on it at the end with #1: "Know what you're looking for". Kahneman is more explicit in Thinking Fast and Slow: come up with a simple rubric of 5 or 6 traits you're looking for in your new hire and ask questions that allow you to score each candidate on a scale of 1 to 5 for each. When you're done, choose the candidate with the highest score. Maybe the technical ability score gets double-weighted for developers. But it seems like a lot of the interview process (and discussion of it) fixates on this. Well this and, of course, vague impressions of the candidate's personality. In my experience, this misses other key things that make up a competent programmer and worthwhile employee. In the spirit of Thinking Fast and Slow, here's a question. As an interviewer, what are the 5 most important traits or qualities you look for in a candidate?

zdfs 11y ago
I'm still working my way through the book, but glad to know he touches on this.

panamafrank 11y ago

So if interviewing is about finding the good hires, what's a bad hire?

deleted 11y ago

[deleted]

sombremesa 11y ago

I work at what can only be defined as a megacorporation. The interview process is a machine, and more often than not interviewers are not personally invested in the process as much as they could be - the candidate is destined to be on someone else's team. This is of course a double edged sword - on the one hand you only have a generic sense of what you are looking for and on the other you have no vendetta for hiring someone who is sub-par to fill your urgent needs.

dmansen 11y ago

In every challenging software development job, you'll be solving problems you've never encountered before. That's the nature of software. Once you understand the problem, you move on to something else. So, why is it such a stretch to ask people to solve Fibonacci? I don't understand this mentality. Reminds me of "why should I learn calculus? I'll never use it in real life!" from college. You're supposed to be a professional software developer, and should be able to handle an unfamiliar problem. If you're a professional musician auditioning to play Mozart, you wouldn't complain that your audition piece is Beethoven.

vonmoltke 11y ago
> In every challenging software development job, you'll be solving problems you've never encountered before. The problem is, the vast majority of software development jobs are not this. That was the point of the comic in the post. There is a whole lot of maintenance, API gluing, and spec work that needs doing. Even at the "elite" companies like Google. The current trend in hiring seems to be at least partially born of Google's ill-advised[1] strategy of hiring generic software engineers that could theoretically be slotted into any role at the company. Hire for a position. If that position involves challenging, novel problems then throw things like that at the candidates in the interview. If it doesn't, don't. [1] After they reached a certain point as a company

iblaine 11y ago

Interesting post. This author lives in Santa Barbara. Hiring in SB is vastly different than it is in SF. Due to the small pool of companies and talent, everyone knows everyone. So there's not much mystery to it.

zdfs 11y ago

Thank you to everyone for reading (whether you agree or not).

krschultz 11y ago

The single best thing I've done when interviewing is ask people to bring a laptop with some of their code on it. I don't care the language o the framework. I don't care if it was school, side project, or even their current job. It puts people on their home turf, where they are most confident and comfortable. They can show me what they are proud of. I can ask lots of questions about it and see their thinking without having to be a total dick asking for an esoteric algorithm on a white board. There's also a lot to be said for how well someone know show to use their tools. Are they navigating proficiently, or are they poking around the IDE like they just started out. This sounds like a softball interview, but you would be amazed the number of people it weeds out. You probably need something more rigorous beyond that, but don't start with the hard problems when an easy filter can really give you a lot of insight. (Note that generally you can't share your current job's code, but people are fairly comfortable opening their own laptop and poking around in the code. I never ask for people to send me that kind of code).

kzhahou 11y ago

Let's talk about BRAIN FREEZE. And I mean the total, complete, 300-baud mush when some question --for whatever reason-- kills your ability to think. I've had it happen twice, and man it ain't fun. The second was like an out-of-body experience. I forgot the question, I forgot my train of thought, I knew I wasn't responding, I knew that I knew that the interview knew that I was just sitting there, saying "ummmmmmmmmm" for about 147 seconds now. Yikes! Yet in day to day, these would have been easy questions. And TBH I didn't even want to job at that point. It's critical that you as an interviewee learn to monitor and CONTROL your physiological response to stress. And I've learned that as an interviewer, I try to pay close attention to physical stress responses from the candidate -- flushed cheeks, signs of sweat, sudden lock-up -- when I see these signs, I back off and let them come back to normal first.

xamuel 11y ago

I find these whiteboard problems a breath of fresh air. Coming from an academic background, I've seen the downsides with the alternatives. * Talking about something you've done? You're selecting for marketing, not programming. * Letters of recommendation? You're selecting for ability to network, not programming. * Academic qualifications? You're selecting for persistence, not programming. * Offline tests? OK right now because they're a minority, but I guarantee if they became the standard, you'd get an astounding amount of cheating. I'm not a marketer and I really resent how in academia to have any chance you have to "sell sell sell". I appreciate anyone who gives me a chance to just objectively demonstrate my abilities, whether I do well or whether I do poorly.

brightball 11y ago
"Talking about something you've done?" EXPLAINING something you've done.
- xamuel 11y ago
  It's still marketing. "Something you've done" could be the 'is-negative' repo that was briefly on the frontpage today [1], and the candidate could launch into a heart-rending speech on the virtues of modular programming. It doesn't say anything about whether they can actually program. Or "something you've done" could be an incredibly sophisticated engine and the candidate isn't good at marketing and comes off worse than the first guy, despite being a top-rate programmer. [1] https://github.com/kevva/is-negative https://github.com/kevva/is-negative
  - brightball 11y ago
    You're looking for an edge case to break a hard rule. In an actual interview, when they are talking about something they've done and explaining it, the interviewer will be able to ask more questions and hopefully (as an interviewer) have enough of a technical background to separate the BS from the skills. If two chemists are talking to each other about chemistry, one's not going to be able to easily just make stuff up that the other blindly accepts.

luckydude 11y ago

Old fart here. My favorite interview question is this: Tell me about a project, any project large or small, that was 100% you. You thought of it, you coded it, you wrote the tests, you documented it. The only other requirement is that the project has to have at least 10 users who installed, used, and continue to use the project without any help from you. Lots of people don't have an answer. Some you need to coax a little, because a small project is fine. For example one that I did close to 30 years ago was move/copy utilities that used regexp. You could do move =.fortran =.f and it did what you wanted (first = is .* and second is $1 and they could repeat). Anyone with basic C skills could have done this (or perl, I think someone else did a perl version and that won). So people would think a project like that doesn't count, but it does. Small is fine, you just had to do the whole thing and people needed to be able to use it without asking for help. This covers a lot of ground and my experience is if you get lucky enough to find someone who has done projects like this, and there is at least some overlap with what we are doing, yeah, we got lucky.

collyw 11y ago
So would a web app I put on Heroku count? No one else is likely to install it. I could probably show it to ten of my friends and get them to try it.

drincruz 11y ago

I've noticed that there is a great number of interviewers that do not take the initiative to just be nice. I suppose they just forget that the interview process is a two-way street.

UncleChis 11y ago

One thing I find annoying is that interviewers expect you to think out loud "continuously". If I stop talking for 30s or 1 minute, I am in trouble. That is not applicable to everyone. I myself feel more confident to think in silent (may be 5-10 minutes at least) before I can tell interviewers my whole train of thought. Speak out loud what I'm thinking could easily interrupt it!!! Everyone is different!

kelukelugames 11y ago
You have to 1) think out loud and 2) finish as fast as you can. Those are often in conflict.

kelukelugames 11y ago

I feel like Notch because I know I will never create something as popular as my first comic. I put so much more creativity and effort into writing this post but only a few hundred people read it. http://kelukelu.me/interview/powerpose.html http://kelukelu.me/interview/powerpose.html Also, I'm embarrassed by how bad my art is. I was learning to use a brand new tablet.

edoceo 11y ago

Interviewing is actually very easy. Every job I post gets 100s of applicants - so finding them is not a problem. I've got a piece of software that lets me A/B these candidates resumes & profiles side-by-side so I rank-sort them quickly. And all "interviews" are small-boxed projects that I ACTUALLY PAY FOR THE WORK. See, most interviews are along the lines of: Q: Are you smart and good looking? A: Yes! This is why I don't really intervew all. When I take the "best" ranked applicants I give them actual work; small slices from our actual code base. I provide them a complete, functional dev environment with one restrciton: cannot commit to git. I can see their work directly, I work with them directly and get real-time data on what it's like to work with them, how they handle a project, how they communicate blockages, how they figure out our existing systems. In four to eight hours of work I know who is the right fit for our team. My cost to find and filter is very very low and rather than waste 2-4 hours per interview for 10 candidates I pay for 16-24 hours of work for 2 or 3 candidates. The hard costs are the same, it consumes less of my (or my engineers) time and the candidate fit is very good.

madcaptenor 11y ago
See, most interviews are along the lines of: Q: Are you smart and good looking? A: Yes! In my current company we hire a lot of developers through contracting companies. These people often have very difficult-to-read resumes - mostly because they are trying to get through filters that work based on searching for keywords, but they're rarely well-written documents even within this constraint. Fine, we're not looking to hire a writer. But a lot of these have "Communication Skills: 9/10" on them. Whether this is added by the candidate or the contracting company, I don't know.

geebee 11y ago

I really liked the cartoon. Clever, and insightful - we go through very difficult and interesting problems that are often unrelated to the job. I disagree a bit with the center pane, though (with the dog typing loops and the caption "I have no idea what I'm doing"). It is, in my opinion, very impressive to be able to find the largest sum of all square matrices in an NxN matrix at a whiteboard in 45 minutes. It's impressive enough (especially not knowing the exact question in advance) to be a positive indicator of the ability to do what is in pane 3, especially considering how many variables and logical basket weaving is often involved in moving some text a few pixels to the right. As long as you are willing to tolerate a very high false negative rate, this could be a good way to go. Unfortunately, it does mean that most developers looking for jobs will need to intensely study data structures and algorithms, and walk around with them loaded in "exam ready" memory" in a way that few people would need to simply to do their jobs. Personally, I'd say most people would retain this mental state anywhere from 1-3 weeks after a college algorithms course, provided they were a good student who understood the material. And it also means that lots of developers who could absolutely do this if they were willing to drop everything to study 50 or so hours and train at a white board will not be hired because they were more interested in just doing their jobs (which, ironically, is what they'd be doing at the new job). So we are going through a very inefficient re-taking of exams every time we interview. So I'm not surprised that some people have decided to stop interviewing, or just give up on finding a job that requires this sort of interview. It's up to a company to decide if they want to give up on hiring these developers, or to tolerate this kind of false negative rate. However I have close to zero interest in hearing about how hard it is to hire good developers if this is their approach, since it suggests to me that the aren't going to make any effort to find a way to avoid these false negatives.