14 ms·

How to talk about yourself in a developer interview

441 points by NickLarsen 9y ago

ganley 9y ago
Good advice. My first (sometimes only) question when I interview people is: Tell me about your favorite project.
- TheCowboy 9y ago
  This is a good question if your goal is to hire people who can talk a good talk about an unverified favorite project. It also assumes that someone has a clear favorite project ready to discuss. People who do not are put at a disadvantage. (Though I do understand this question is well-intentioned.) The article doesn't really justify the process people go through as a good one. People who think they have a good approach to interviewing, but their sample size is too small to back it up or worse, present an opportunity to people who are good at telling stories but may not have the skills to go along with the story in the end. People who hire based on the story-telling experience will eventually get burned. I think someone should read this and feel a little worried. This is story-telling. People who might argue that telling a story is being able to communicate---it's merely one form of communication of many that are needed depending on the work environment, and results in a blind spot for your team's hiring process.
  - existencebox 9y ago
    Having done many interviews, mentored interns and full employees, I'd argue storytelling is a _key aspect_ of performing our job in a larger team. Perhaps I'm being too liberal in my definitions, but I see substantial overlap between "talk about your last project" (and then digging into pitfalls, hacks, workarounds, conflicts; and mind you, I don't mean just PASSION projects, literally any work prior one can speak fluently on) and "tell me how you want to spec this architecture; why". Much of how we discuss what we do can't be empirically precise, unambiguous, and scientific. Certainly the more social and abstract aspects of our jobs begin to sound, as you put it, like storytelling. (To be clear, it's far from the only thing I look for, and can be taught/learned to a degree, but I consider it as a key skill in the broader bucket of "communication"; alongside problem solving and base competencies. And like programming itself, having some experience helps.)
    - 0xcde4c3db 9y ago
      > I see substantial overlap between "talk about your last project" [...] and "tell me how you want to spec this architecture; why". A major difference is that some people have deficiencies in autobiographical memory. This can make telling the story of a past project vastly more difficult than talking about a subject of current focus. An extreme case was recently described in Wired [1], but the ability is generally more of a spectrum. [1] https://www.wired.com/2016/04/susie-mckinnon-autobiographical-memory-sdam/ https://www.wired.com/2016/04/susie-mckinnon-autobiographica...
    - TheCowboy 9y ago
      As I mentioned, this is playing into the fallacy that telling a story during the interview is equivalent to the communication skills required for performing the job. It confuses story-telling performance during an interview, and the stresses of a success/fail situation, with the type required to perform real work. Mistaking "overlap" for all-encompassing. Sure, there's overlap. There's overlap in being able to type up a coherent response to a post on Hacker News, but it doesn't make me more qualified for your position. It fails because it assumes that the candidate has a single defined favorite project. If you try to make the question more broad, then it becomes so open-ended that it is hard to equally compare candidates on it. It becomes random chance that a candidate discusses a project in a way conducive to doing the job. Where if more precise or structured, it might weed out people who can talk passionately about a personal project from those who can constructively explain to a manager the challenges of a project. It also starts stretching it into saying that everything is story-telling so as to make the term meaningless. I agree it is to some degree, but it's important to try to stick with meaningful mental models that can make predictive assessments about candidates. The huge problem is there are people without the skills who can tell a good story. This process let's these people through, while ignoring good candidates who may not perform well on this interview question.
      - eropple 9y ago
        I'm sympathetic to most of what you're saying, but: > It fails because it assumes that the candidate has a single defined favorite project. I...kinda don't want to work with somebody who can't read between the lines and pick one of their favorite projects when a question like this comes up. Social signaling and parsing are important to a comfortable and pleasant work environment.
  - beamatronic 9y ago
    I ask a slight variation, tell me about a project that you worked on that you enjoyed or are proud of. If they can't answer this it makes me wonder if they don't enjoy anything or are not proud of anything.
    - TheCowboy 9y ago
      "Makes me more wonder" is a euphemism for "makes me doubt their qualifications and abilities". Some people are humble about their work and abilities. They will never exhibit open pride. Or they don't want to bullshit people and blow smoke up someone's rear. Some may want to switch jobs because they are forced to do poor work and know they shouldn't feel proud about that. This is probably a 'flaw' I have, but I'm aware of it that I know what I'm expected to sound like when asked this question. Now I'm put in a position where I am being dishonest. You're now testing my ability to BS you to get what I want, and by my nature I am already uncomfortable with BS'ing people. Now compare this to the person who is too incompetent to not feel pride in the shoddy work they do. Now the enjoyment part. I can talk about this extensively, but enjoyment is subjective. I could enjoy working on something because of the challenge of the problem, or because I was part of a great team, but it still doesn't speak to my ability to perform the job you have.
      - scient 9y ago
        I don't see this as being humble, I see this as a lack of confidence in their skills and abilities and achievements. These same people, for the same reasons, are adverse to avoid making decisions and second guess their work, which causes delays and communication problems. Instead of trying to make this into an excuse of being humble, it should be acknowledged as a lack of a certain important trait.
        gknoy 9y ago
        > I see this as a lack of confidence in their skills and abilities and achievements Given that imposter syndrome is well-documented in our industry, it's quite possible that I've done cool things, or impressive things, but not realize that they are cool or impressive because I am in awe of the awesome developers I work with. Combine that with most of my work being something like "I added new features in our Ember app, and fixed bugs in the UI and backend", and it often is easy to feel like the day-to-day work I do isn't awesome, even if what I am building is (IMO) pretty cool.
  - dahart 9y ago
    My anecdata with hundreds of interviews over the years is that getting people to talk about their projects is the single best/fastest way to verify their involvement and knowledge of the projects they list on their resume. When someone can't elaborate on what they did and why, or what problems motivated their work and what they learned, it's a strong indicator that they are puffing up the projects/keywords on their resume (which is super common) but didn't actually learn much. Moreover, getting people talking is a great way, in my experience, of identifying strong thinkers, strong coders, and strong experience. It helps you see someone's personality, it helps you literally get to know them. I can't think of any reasons why I would worry about that before hiring someone. I would worry about not doing it. I would like to know what you would offer as a better alternative approach? Do you prefer the idea of coding questions to stories?
    - TheCowboy 9y ago
      What percentage of bad hires result from your approach vs. other approaches you've tried that have failed? If you even did know that, how is this not randomness in a small sample? This ignores the problem that if someone can elaborate, it's not necessarily an indicator. It can just mean that someone can BS well. Relaying too many specific details can actually be an indicator that someone is not telling the truth. "Getting people talking" is really the only way you can identify these things during an interview. And this is not the same as telling a good story. And now you have to demonstrate that this results in job performance. On here, tptacek has exhaustively described an alternative approach: https://news.ycombinator.com/item?id=9159557 https://news.ycombinator.com/item?id=9159557
      - dahart 9y ago
        I've never hired someone who's been fired, and I've had to fire other people's hires, so I think my process works okay on some empirical level. I do not defend my approach as scientific or perfect; it's not, and I never claimed it was. But I have verified my approach by asking follow up questions with people who seem to signal they're inflating the importance of items on their resume, and found that my detector was working. > Relaying too many specific details can actually be an indicator that someone is not telling the truth. This is actually not true and has been scientifically demonstrated. I listened to a podcast about this, and lies come out with a measurably, detectably reduced vocabulary versus true stories. Let me see if I can find a link to it... But I also don't care whether it's true because your base assumption is that you shouldn't trust anything anyone says. My experience is the polar opposite: most people interviewing for jobs aren't primarily bullshitting, they are by and large telling the truth, and all I need to do is determine which candidates are better than other candidates, not which ones are lying. Most of the resume inflation I've seen isn't a case of intentional BSing, it's a case of inexperienced people not knowing how little they know, and assuming that a month of JS or SQL during a summer internship puts them in roughly the same camp as someone who's done it for 5-10 years. Talking that out with people has and continues to give me a pretty good idea of what they know and don't know. BTW, I don't see anywhere that @tptacek is countering what I've said. If you read what he said, he mentions using conversation to filter people multiples times. Here, for example: https://news.ycombinator.com/item?id=9159959 https://news.ycombinator.com/item?id=9159959 No interview process is scientific and perfect, and you shouldn't expect them to be, that is unrealistic. There's nothing wrong with realizing it's a social activity and not an algorithm, that it's an art and not a science. Learning how to be good in interviews by understanding what interviewers are looking for is part of your job, not a way to gamify the system and trick people into hiring you. Another part is being a good coder. Both are important.
- maxxxxx 9y ago
  I do that too and look if the person has a project he/she is excited about and can talk about decisions that have been made and other details with some clarity.
- MatthewMcDonald 9y ago
  My favorite question is to ask them about their failures, and what they would do differently now
samlittlewood 9y ago
Also, As well as words, I would recommend practising the key diagrams that represent the projects(s) - so you leave enough space for the important elements, and don't fall of edge of page/board.
midgetjones 9y ago
I was updating my CV recently. I don't have the longest employment history (switched careers, then stayed at a job for 5 years), so I padded it out with a few short paragraphs of projects I'd worked on. It actually worked really well - it brought some projects I'd forgotten about back into my mind making it easier to talk about them, and gave the interviewers specifics to latch on to.
- JoshTriplett 9y ago
  I did this in my resume for my first job out of college, and I still do: "Open Source Software Project Experience". List of projects, with details on impact and relevance.
- bphogan 9y ago
  More importantly, it shows accomplishments, not job duties. And that's what everyone wants to see - how your wins there will translate into wins here.
a3n 9y ago
> If you’ve been through interviews at some companies that are not as good at interviewing, then you probably had some questions on your list such as > Where do you see yourself in 5 years? Dead. > Why do you want to work here? You have money. > How do you handle disagreements with coworkers? Attempt constructive engagement, and if that doesn't work then shun them.
- pawadu 9y ago
  Sorry, but you are too honest to work in our industry. Have you thought about going into politics or drugs instead?
  - lighthazard 9y ago
    Sorry, no culture fit.
- foo101 9y ago
  What are your strengths and weaknesses?
  - a3n 9y ago
    Honesty and honesty.
    - nercht12 9y ago
      You forgot "humor".
    - nercht12 9y ago
      and "humor".
  - kinkrtyavimoodh 9y ago
    Brevity.
- kangdolit 9y ago
  > > Where do you see yourself in 5 years? > Dead. Did you say you have a three-year vesting schedule? I'll be at another company probably, since you'll have me doing two jobs for my original compensation and title after the second year.
wallflower 9y ago
If you don't agree with this slightly-contrived (I'm talking about the 'start with punchline', specifically) storytelling technique endorsed here, at the very least, please be aware of the STAR technique commonly used in behavioral interviews. One benefit of using the STAR technique is that you are not going to ramble. It should not take you more than 1 minute to fully lay out the Situation, Task, Action, Result. After that "executive summary", if they want you to go more in depth, the interviewer(s) can ask you. https://en.wikipedia.org/wiki/Situation,_Task,_Action,_Result https://en.wikipedia.org/wiki/Situation,_Task,_Action,_Resul...
- digoM 9y ago
  +1
- fecak 9y ago
  Resume writer here to add that the STAR technique applies to resume writing as well. For any accomplishment on a resume, it's ideal to have these four items covered in at least some detail.
- graphitezepp 9y ago
  Yeah trying to create a model of 'how you should talk' is probably often counterproductive as everyone responds differently. Your suggestion of STAR is better as it is far more generalized while still giving you a guideline to focus on so you don't get lost or off track.
- ryandrake 9y ago
  Yup, I've always known STAR as the "gold standard" for these kinds of questions. Also the presentation technique of: "Tell the audience what you're going to say, say it; then tell them what you've said."
- dahart 9y ago
  You could use the RATS technique. ;) I feel like STAR is important in the same way and for the same reason as 'start with the punchline'. Both are good ideas, and both are aiming for 'keep it short and relevant.' Which, having interviewed and hired many people over the years, I'd have to say is reasonably good advice. There are plenty of exceptions to both of these ideas though. I probably have more trouble getting engineers to elaborate on something than I have with them going on for too long. I quite enjoy a candidate who will help me carry a conversation, who will ask questions of me, who will offer and inject relevant or interesting side-details into their story. Going on a tangent isn't a bad thing unless it's negative or irrelevant.
digoM 9y ago
Google has published some of their data on this and behavioral questions about teamwork (e.g. handling disagreements) are reasonable and can be valuable. Software development is usually a team activity. The rest of this post is a useful, if anecdotally sourced, guide to answering the more technical class of behavioral questions. It should include a block on follow up questions. Good behavioral interviewers, like you might find at Google or Amazon, will ask specific follow ups for each question. See: http://www.businessinsider.com/google-laszlo-bock-interview-questions-2015-4 http://www.businessinsider.com/google-laszlo-bock-interview-...
- NickLarsen 9y ago
  Thanks for posting this. One thing I didn't write about is the objectiveness of interviews (felt like a different topic). Just about any question can be okay as long as it follows a few simple rules. 1) if you ask a question, you should have an expectation of what you're looking for as a result in some quantifiable way and 2) how does that result affect your decision to hire or not. The worst interviewers usually don't have an answer for #1 there and they probably decided to hire you or not very soon after you opened your mouth for the first time. This article fails to state why each of these questions is valuable and what you should be looking for as a result of asking any of them. With the addition of that, it would be a much better article.
mwcampbell 9y ago
Interesting. I naively assumed that the most important part of preparing for a developer job interview was to prepare for the coding exercises -- the stereotypical algorithm stuff.
sweezyjeezy 9y ago
> If you give them a resume, expect questions about stuff you worked on at your past jobs. If you gave them a link to your Github profile, expect questions about your projects. If you gave them a link to your Stack Overflow account, expect questions about some of your answers. On my Linkedin (and also resume etc.) I give a link to my blog / github. Every time I've been asked about it in an interview setting, it was actually when I was the one conducting the interview, and the interviewee was trying to impress. Much as it pains me to say, I don't think side projects are a good way to bolster your CV, at least in my field.
- pmiller2 9y ago
  What is your field?
- wccrawford 9y ago
  I've only asked questions about Github projects when they have something on there wasn't obviously from schooling or just garbage they threw on there to keep for later. I'm pretty certain we're in a different industry, but I'm still surprised nobody has asked about your Github stuff, assuming you've put decent things on there.
- cookiecaper 9y ago
  Doesn't surprise me, but if you're handing it out, you should still be prepared to answer questions about the stuff that's on there.
lettersdigits 9y ago
> What is the hardest technical problem you have run into? I never seem to find a quick good answer for this. Maybe I just almost never work on REAL hard things. So my question to you, HNers, is : What is the hardest technical problem YOU have run into? I am really interested to know what you would consider 'hardest'.. It's probably not going to be something like 'I changed the css property value from "display: block" to "display: inline-block"..'
- smnplk 9y ago
  There was this variable name I misspelled once ;)
  - dom0 9y ago
    rm -rf $BUILROOT/∗
  - AnimalMuppet 9y ago
    Heh. While still a student, I was working in Fortran (all upper case). I was trying to type COS (the cosine function), and I overshot the Oh character, and typed a zero: C0S. Not very visually different! It took me two days to figure out why Fortran suddenly didn't know what cosine was...
- sedky 9y ago
  I felt the same way. But it can be anything. "I sped up the page load on the site", "I redesigned the front-end to work on mobile", etc.
- NickLarsen 9y ago
  The localization project I use as an example here was definitely one of my top 3 hardest projects of all time (and that was years ago). It was not a particularly difficult technical challenge, it was difficult because it touched every single aspect of the codebase. The project took me and a coworker 3 months to build out the infrastructure for, then another 3 months of actually rewriting everything to use it, and explaining to every single other developer about why we made the decisions we made in order to teach them the different ways they were going to have to write code from now on. Social challenges of the workplace are hard; we're not always looking for technical difficulty.
dahart 9y ago
I see some criticism on this point, but for me this passage is a gem. > In general, real stories are told chronologically backwards. This is why we start off with a punchline. In contrast, practiced stories are told chronologically forwards. It’s a solid indication as the interviewer that the person is reciting something they have committed to memory if they tell the story forwards, and in turn it’s significantly more likely that the story isn’t entirely true. I have a friend who - bless his heart, I adore him, but can't get a quick story out to save his life. Every point he makes he reserves the punchline for last, and he starts by going on a back-story tangent first which usually forks into multiple back-stories. I've been trying to nudge him to turn it around and give away the punchline first, but he's deeply convinced that good stories are like movies and need to have a backstory followed by a narrative arc that doesn't make it's final point until most of the way through act 3.
- inanutshellus 9y ago
  Oh man, that's me for sure. I always backstory my tales to death. It does successfully take a minor conversation and turn it into an elaborate and interesting discourse but yes, as you say, it's not focused on the original punch line.
  - ma2rten 9y ago
    I never realized it until now, but I think I might be doing that as well. I will try to be mindful of that. Thanks.
  - dahart 9y ago
    There's a time and place for a good long meandering and elaborate backstory! Interesting conversation and discourse is something you should cherish and continue to develop. So, don't get me wrong, punchline first is not a rule, not always the goal. Just be aware of it, and you can start to decide which one to use. For job interviews, punchline first is good advice. For talking to your friends, it depends. For giving a talk or telling a story, backstory might be critical. Start playing with it and see how people react, find out when & how starting with the punchline is better. I think the point of the article is that punchline first is a tactic to get the other person talking and asking questions, rather than you talking for 5 minutes.
codingdave 9y ago
>In all likelihood, the interviewer doesn’t know what they are looking for with these questions, and they are just being used to fill time. Wait a sec -- just because the author of the article doesn't know how to get value from those questions doesn't mean that those questions hold no value. It is true that they won't give you information to help you in a tech screen, or to gauge the value of where to initially place a candidate on a team. But if you are trying to decide between a few candidates of equal skill, and trying to figure out which one will work better in a team environment, which will fit more smoothly into the personal dynamics between team members, who will grow better as the company grows, who might be a better leader or follower, and what their trajectory might be as the company and team evolves, these questions can lead you down those paths. Dismissing those questions as useless makes me think the author doesn't care about the people as individuals, but just as machines to be plugged in to produce code. And that doesn't sound like someone I would want to work for.
- jakewins 9y ago
  It's ironic actually. The author touts told stories of prior work as key, and degrades attempts at measuring candidate conscientiousness. Meanwhile, strongest known measures of job performance are an actual work sample (r=.26), rather than ability to describe a prior project, and measures of conscientiousness (r=.15). On conscientiousness: Barrick, Murray R., and Michael K. Mount. "The big five personality dimensions and job performance: a meta‐analysis." Personnel psychology 44.1 (1991): 1-26. On work samples: Roth, Philip L., Philip Bobko, and L. Y. N. N. McFARLAND. "A meta‐analysis of work sample test validity: Updating and integrating some classic literature." Personnel Psychology 58.4 (2005): 1009-1037.
- cookiecaper 9y ago
  It's the rote, cliche questions that show an interviewer doesn't really know what he's talking about. Questions about personality and culture are very important, but if someone asked "Where do you see yourself in 5 years?", it would point toward their not being a skilled interviewer. It's better to phrase the same question in any other way that's not associated with corporate ineptitude, like "What are your long-term career goals?"
deleted 9y ago
[deleted]
andy_ppp 9y ago
Never talk about yourself; steer the interview to being about a problem they are solving with work and help them run through how you would solve the problem as if it's a meeting and you are working with them. Rarely fails.
- erikb 9y ago
  I'd say it's not either or. Do both. Give a short summary of who you are with related projects you worked on. Explain shortly how these experiences made you an authority on their problem. Then explain how you would handle that problem of theirs.
cletus 9y ago
Let's translate shall we? > What is the hardest technical problem you have run into? "Tell me an unverifiable story in which you're the hero." I really hate this question: > Where do you see yourself in 5 years? Any post on HN about interviews draws a ton of comments, and they're usually the same comments as every other post on the subject. Honestly at this point having gone through a reasonably large number of interviews I think it comes down to brushing up on basic CS knowledge and, more importantly, whether or not they like you. As much as we like to make interviews dispassionate assessments of proficiency it really does seem like basic chemistry is the key issue. And honestly that makes a certain amount of sense: most people don't want to work with someone they dislike.
- GoToRO 9y ago
  Also, how bad they need to fill that position. You will get waaay less bullshit if they are in hurry.
bitwize 9y ago
I find I'm more willing to talk about myself if engaged in meaningful dialogue. For example, I get this a lot as an opening question, mainly from crooters (actual hiring managers almost never do this): "What are your skills?" You mean like numchuck skills, bow-hunting skills? If you don't know what kind of skills I have that could possibly be germane to the positions I'm looking for, you obviously didn't even read my résumé, which means you don't have a clue, which means I am hanging up on you because obviously you can't help me. If you say "Can you tell me about your role at company X, what sort of challenges you had, etc." I'm more willing to open up.
kafkaesq 9y ago
What is the hardest technical problem you have run into? Almost always asked from companies that don't have problems to offer even remotely comparable to the "war stories" they're expecting to you rattle off -- at least not for the position you're applying for, anyways.
tejtm 9y ago
> What is the hardest technical problem you have run into? well technically, the hardest problems I have encountered are not technical
ruleabidinguser 9y ago
Is this actually useful to people? Please don't give me non-answers like "well it got upvoted.."
tn135 9y ago
This is one of the best blogs on the topic and as someone who has easily cracked all big tech company interviews I can say this is a good piece of advice. I will make following broad points: 1. Never walk into that room without practicing. Practice before a mirror, practice before a friend, practice in a car. Have a written script and optimise it to remove redundancy, highlight achievements etc. It is not about repeating what you have practiced but having a free flowing conversation where you don't have to struggle for words, sentences all while maintaining a confident posture. 2. Converse not interview A lot of people fail to keep the conversation going. It is not like a FBI investigation. It is more like a friendly banter. Think of a scenario where you are talking to a potential roomie. It is okay to walk out of that interview without an offer but then you should feel good about having conversed with another geek just like you. --- Maintain the mindset outside of interview preparation. Most people fail at this. Good interview preparation begins months ahead. You need to look at your co-worker's code, give them feedback, learn to make needless improvements in your existing code, solve algorithms and discuss technical problems on stack overflow and else where. Built a mindset where you are able to talk about technical work to other people. Speak more, listen more and advice more at least 3 months ahead.
- hueving 9y ago
  If that's what it takes to get a job as an engineer at the big companies, it's not particularly surprising that the quality of their engineers has declined as they've grown. The skills of a con artist are not related to the ability to build good systems.
  - alpha_squared 9y ago
    Conversely, the skills to build good systems are not related to working effectively with others. There's probably a balance that needs to be struck, though they're also not mutually exclusive.
    - dasil003 9y ago
      > the skills to build good systems are not related to working effectively with others Yes they are if you're talking about the types of systems that large companies have. It is in fact so difficult that I believe it's a considerable advantage to have scopes small enough to be manageable by a single engineer, but inherent complexity is often well beyond that, especially for very profitable business engines.
southphillyman 9y ago
I think behavioral and "tell me a time when" questions can easily be gamed, so I question the effectiveness of asking them. Sometimes I forget specific domain knowledge around a project I worked on 1+ companies ago. But I still have to list it on my resume and thus be able to speak to it...... so I just approximate the details. I imagine you could just full on lie as long as you can detail a technical problem and provide a solution to it.
freshflowers 9y ago
All that matters is having a good conversation and not appearing completely incompetent. After an enjoyable conversation, the hiring person will rationalize wanting you all by themselves, even if they have to make up / project qualities you've never demonstrated. 95% of the time, there's nothing rational about hiring.
bob1122 9y ago
This is incredible, thanks for sharing!
Tharkun 9y ago
Being prepared to talk is important. Knowing when to shut up is equally important. Recently interviewed a candidate who seemed promising, until they started to rant. I didn't want to interrupt them because I was hoping there was a point to be made at the end of the rant ... but in the end it was just 5+ minutes worth of "my current job isn't fair and everything sucks and everyone who is better than me really sucks too". Didn't hire.
nercht12 9y ago
For younger candidates, how about questions like: "Do you have a passion for this industry? Why?" and "What have you done in the past that demonstrates your commitment to completing anything you set your mind to?" For older candidates, how about questions like: "What do you consider your driving factor?" (with possible answers like "good benefits" or "complex challenges" or "teamwork") and "What sort of challenges do you see in this field/industry and how would you go about solving them?" (with acceptable answers from technical development solutions to "let's outsource" or something creative - something that demonstrates their wisdom, even if the field isn't their expertise).
martimoose 9y ago
When I read articles about job interviews, I always wonder what is the correlation coefficient between "being good at interviews" and "being good at doing your actual job".

441 points by NickLarsen 9y ago

ganley 9y ago

Good advice. My first (sometimes only) question when I interview people is: Tell me about your favorite project.

TheCowboy 9y ago
This is a good question if your goal is to hire people who can talk a good talk about an unverified favorite project. It also assumes that someone has a clear favorite project ready to discuss. People who do not are put at a disadvantage. (Though I do understand this question is well-intentioned.) The article doesn't really justify the process people go through as a good one. People who think they have a good approach to interviewing, but their sample size is too small to back it up or worse, present an opportunity to people who are good at telling stories but may not have the skills to go along with the story in the end. People who hire based on the story-telling experience will eventually get burned. I think someone should read this and feel a little worried. This is story-telling. People who might argue that telling a story is being able to communicate---it's merely one form of communication of many that are needed depending on the work environment, and results in a blind spot for your team's hiring process.
- existencebox 9y ago
  Having done many interviews, mentored interns and full employees, I'd argue storytelling is a _key aspect_ of performing our job in a larger team. Perhaps I'm being too liberal in my definitions, but I see substantial overlap between "talk about your last project" (and then digging into pitfalls, hacks, workarounds, conflicts; and mind you, I don't mean just PASSION projects, literally any work prior one can speak fluently on) and "tell me how you want to spec this architecture; why". Much of how we discuss what we do can't be empirically precise, unambiguous, and scientific. Certainly the more social and abstract aspects of our jobs begin to sound, as you put it, like storytelling. (To be clear, it's far from the only thing I look for, and can be taught/learned to a degree, but I consider it as a key skill in the broader bucket of "communication"; alongside problem solving and base competencies. And like programming itself, having some experience helps.)
  - 0xcde4c3db 9y ago
    > I see substantial overlap between "talk about your last project" [...] and "tell me how you want to spec this architecture; why". A major difference is that some people have deficiencies in autobiographical memory. This can make telling the story of a past project vastly more difficult than talking about a subject of current focus. An extreme case was recently described in Wired [1], but the ability is generally more of a spectrum. [1] https://www.wired.com/2016/04/susie-mckinnon-autobiographical-memory-sdam/ https://www.wired.com/2016/04/susie-mckinnon-autobiographica...
  - TheCowboy 9y ago
    As I mentioned, this is playing into the fallacy that telling a story during the interview is equivalent to the communication skills required for performing the job. It confuses story-telling performance during an interview, and the stresses of a success/fail situation, with the type required to perform real work. Mistaking "overlap" for all-encompassing. Sure, there's overlap. There's overlap in being able to type up a coherent response to a post on Hacker News, but it doesn't make me more qualified for your position. It fails because it assumes that the candidate has a single defined favorite project. If you try to make the question more broad, then it becomes so open-ended that it is hard to equally compare candidates on it. It becomes random chance that a candidate discusses a project in a way conducive to doing the job. Where if more precise or structured, it might weed out people who can talk passionately about a personal project from those who can constructively explain to a manager the challenges of a project. It also starts stretching it into saying that everything is story-telling so as to make the term meaningless. I agree it is to some degree, but it's important to try to stick with meaningful mental models that can make predictive assessments about candidates. The huge problem is there are people without the skills who can tell a good story. This process let's these people through, while ignoring good candidates who may not perform well on this interview question.
    - eropple 9y ago
      I'm sympathetic to most of what you're saying, but: > It fails because it assumes that the candidate has a single defined favorite project. I...kinda don't want to work with somebody who can't read between the lines and pick one of their favorite projects when a question like this comes up. Social signaling and parsing are important to a comfortable and pleasant work environment.
- beamatronic 9y ago
  I ask a slight variation, tell me about a project that you worked on that you enjoyed or are proud of. If they can't answer this it makes me wonder if they don't enjoy anything or are not proud of anything.
  - TheCowboy 9y ago
    "Makes me more wonder" is a euphemism for "makes me doubt their qualifications and abilities". Some people are humble about their work and abilities. They will never exhibit open pride. Or they don't want to bullshit people and blow smoke up someone's rear. Some may want to switch jobs because they are forced to do poor work and know they shouldn't feel proud about that. This is probably a 'flaw' I have, but I'm aware of it that I know what I'm expected to sound like when asked this question. Now I'm put in a position where I am being dishonest. You're now testing my ability to BS you to get what I want, and by my nature I am already uncomfortable with BS'ing people. Now compare this to the person who is too incompetent to not feel pride in the shoddy work they do. Now the enjoyment part. I can talk about this extensively, but enjoyment is subjective. I could enjoy working on something because of the challenge of the problem, or because I was part of a great team, but it still doesn't speak to my ability to perform the job you have.
    - scient 9y ago
      I don't see this as being humble, I see this as a lack of confidence in their skills and abilities and achievements. These same people, for the same reasons, are adverse to avoid making decisions and second guess their work, which causes delays and communication problems. Instead of trying to make this into an excuse of being humble, it should be acknowledged as a lack of a certain important trait.
      - gknoy 9y ago
        > I see this as a lack of confidence in their skills and abilities and achievements Given that imposter syndrome is well-documented in our industry, it's quite possible that I've done cool things, or impressive things, but not realize that they are cool or impressive because I am in awe of the awesome developers I work with. Combine that with most of my work being something like "I added new features in our Ember app, and fixed bugs in the UI and backend", and it often is easy to feel like the day-to-day work I do isn't awesome, even if what I am building is (IMO) pretty cool.
- dahart 9y ago
  My anecdata with hundreds of interviews over the years is that getting people to talk about their projects is the single best/fastest way to verify their involvement and knowledge of the projects they list on their resume. When someone can't elaborate on what they did and why, or what problems motivated their work and what they learned, it's a strong indicator that they are puffing up the projects/keywords on their resume (which is super common) but didn't actually learn much. Moreover, getting people talking is a great way, in my experience, of identifying strong thinkers, strong coders, and strong experience. It helps you see someone's personality, it helps you literally get to know them. I can't think of any reasons why I would worry about that before hiring someone. I would worry about not doing it. I would like to know what you would offer as a better alternative approach? Do you prefer the idea of coding questions to stories?
  - TheCowboy 9y ago
    What percentage of bad hires result from your approach vs. other approaches you've tried that have failed? If you even did know that, how is this not randomness in a small sample? This ignores the problem that if someone can elaborate, it's not necessarily an indicator. It can just mean that someone can BS well. Relaying too many specific details can actually be an indicator that someone is not telling the truth. "Getting people talking" is really the only way you can identify these things during an interview. And this is not the same as telling a good story. And now you have to demonstrate that this results in job performance. On here, tptacek has exhaustively described an alternative approach: https://news.ycombinator.com/item?id=9159557 https://news.ycombinator.com/item?id=9159557
    - dahart 9y ago
      I've never hired someone who's been fired, and I've had to fire other people's hires, so I think my process works okay on some empirical level. I do not defend my approach as scientific or perfect; it's not, and I never claimed it was. But I have verified my approach by asking follow up questions with people who seem to signal they're inflating the importance of items on their resume, and found that my detector was working. > Relaying too many specific details can actually be an indicator that someone is not telling the truth. This is actually not true and has been scientifically demonstrated. I listened to a podcast about this, and lies come out with a measurably, detectably reduced vocabulary versus true stories. Let me see if I can find a link to it... But I also don't care whether it's true because your base assumption is that you shouldn't trust anything anyone says. My experience is the polar opposite: most people interviewing for jobs aren't primarily bullshitting, they are by and large telling the truth, and all I need to do is determine which candidates are better than other candidates, not which ones are lying. Most of the resume inflation I've seen isn't a case of intentional BSing, it's a case of inexperienced people not knowing how little they know, and assuming that a month of JS or SQL during a summer internship puts them in roughly the same camp as someone who's done it for 5-10 years. Talking that out with people has and continues to give me a pretty good idea of what they know and don't know. BTW, I don't see anywhere that @tptacek is countering what I've said. If you read what he said, he mentions using conversation to filter people multiples times. Here, for example: https://news.ycombinator.com/item?id=9159959 https://news.ycombinator.com/item?id=9159959 No interview process is scientific and perfect, and you shouldn't expect them to be, that is unrealistic. There's nothing wrong with realizing it's a social activity and not an algorithm, that it's an art and not a science. Learning how to be good in interviews by understanding what interviewers are looking for is part of your job, not a way to gamify the system and trick people into hiring you. Another part is being a good coder. Both are important.
maxxxxx 9y ago
I do that too and look if the person has a project he/she is excited about and can talk about decisions that have been made and other details with some clarity.
MatthewMcDonald 9y ago
My favorite question is to ask them about their failures, and what they would do differently now

samlittlewood 9y ago

Also, As well as words, I would recommend practising the key diagrams that represent the projects(s) - so you leave enough space for the important elements, and don't fall of edge of page/board.

midgetjones 9y ago

I was updating my CV recently. I don't have the longest employment history (switched careers, then stayed at a job for 5 years), so I padded it out with a few short paragraphs of projects I'd worked on. It actually worked really well - it brought some projects I'd forgotten about back into my mind making it easier to talk about them, and gave the interviewers specifics to latch on to.

JoshTriplett 9y ago
I did this in my resume for my first job out of college, and I still do: "Open Source Software Project Experience". List of projects, with details on impact and relevance.
bphogan 9y ago
More importantly, it shows accomplishments, not job duties. And that's what everyone wants to see - how your wins there will translate into wins here.

a3n 9y ago

> If you’ve been through interviews at some companies that are not as good at interviewing, then you probably had some questions on your list such as > Where do you see yourself in 5 years? Dead. > Why do you want to work here? You have money. > How do you handle disagreements with coworkers? Attempt constructive engagement, and if that doesn't work then shun them.

pawadu 9y ago
Sorry, but you are too honest to work in our industry. Have you thought about going into politics or drugs instead?
- lighthazard 9y ago
  Sorry, no culture fit.
foo101 9y ago
What are your strengths and weaknesses?
- a3n 9y ago
  Honesty and honesty.
  - nercht12 9y ago
    You forgot "humor".
  - nercht12 9y ago
    and "humor".
- kinkrtyavimoodh 9y ago
  Brevity.
kangdolit 9y ago
> > Where do you see yourself in 5 years? > Dead. Did you say you have a three-year vesting schedule? I'll be at another company probably, since you'll have me doing two jobs for my original compensation and title after the second year.

wallflower 9y ago

If you don't agree with this slightly-contrived (I'm talking about the 'start with punchline', specifically) storytelling technique endorsed here, at the very least, please be aware of the STAR technique commonly used in behavioral interviews. One benefit of using the STAR technique is that you are not going to ramble. It should not take you more than 1 minute to fully lay out the Situation, Task, Action, Result. After that "executive summary", if they want you to go more in depth, the interviewer(s) can ask you. https://en.wikipedia.org/wiki/Situation,_Task,_Action,_Result https://en.wikipedia.org/wiki/Situation,_Task,_Action,_Resul...

digoM 9y ago
+1
fecak 9y ago
Resume writer here to add that the STAR technique applies to resume writing as well. For any accomplishment on a resume, it's ideal to have these four items covered in at least some detail.
graphitezepp 9y ago
Yeah trying to create a model of 'how you should talk' is probably often counterproductive as everyone responds differently. Your suggestion of STAR is better as it is far more generalized while still giving you a guideline to focus on so you don't get lost or off track.
ryandrake 9y ago
Yup, I've always known STAR as the "gold standard" for these kinds of questions. Also the presentation technique of: "Tell the audience what you're going to say, say it; then tell them what you've said."
dahart 9y ago
You could use the RATS technique. ;) I feel like STAR is important in the same way and for the same reason as 'start with the punchline'. Both are good ideas, and both are aiming for 'keep it short and relevant.' Which, having interviewed and hired many people over the years, I'd have to say is reasonably good advice. There are plenty of exceptions to both of these ideas though. I probably have more trouble getting engineers to elaborate on something than I have with them going on for too long. I quite enjoy a candidate who will help me carry a conversation, who will ask questions of me, who will offer and inject relevant or interesting side-details into their story. Going on a tangent isn't a bad thing unless it's negative or irrelevant.

digoM 9y ago

Google has published some of their data on this and behavioral questions about teamwork (e.g. handling disagreements) are reasonable and can be valuable. Software development is usually a team activity. The rest of this post is a useful, if anecdotally sourced, guide to answering the more technical class of behavioral questions. It should include a block on follow up questions. Good behavioral interviewers, like you might find at Google or Amazon, will ask specific follow ups for each question. See: http://www.businessinsider.com/google-laszlo-bock-interview-questions-2015-4 http://www.businessinsider.com/google-laszlo-bock-interview-...

NickLarsen 9y ago
Thanks for posting this. One thing I didn't write about is the objectiveness of interviews (felt like a different topic). Just about any question can be okay as long as it follows a few simple rules. 1) if you ask a question, you should have an expectation of what you're looking for as a result in some quantifiable way and 2) how does that result affect your decision to hire or not. The worst interviewers usually don't have an answer for #1 there and they probably decided to hire you or not very soon after you opened your mouth for the first time. This article fails to state why each of these questions is valuable and what you should be looking for as a result of asking any of them. With the addition of that, it would be a much better article.

mwcampbell 9y ago

Interesting. I naively assumed that the most important part of preparing for a developer job interview was to prepare for the coding exercises -- the stereotypical algorithm stuff.

sweezyjeezy 9y ago

> If you give them a resume, expect questions about stuff you worked on at your past jobs. If you gave them a link to your Github profile, expect questions about your projects. If you gave them a link to your Stack Overflow account, expect questions about some of your answers. On my Linkedin (and also resume etc.) I give a link to my blog / github. Every time I've been asked about it in an interview setting, it was actually when I was the one conducting the interview, and the interviewee was trying to impress. Much as it pains me to say, I don't think side projects are a good way to bolster your CV, at least in my field.

pmiller2 9y ago
What is your field?
wccrawford 9y ago
I've only asked questions about Github projects when they have something on there wasn't obviously from schooling or just garbage they threw on there to keep for later. I'm pretty certain we're in a different industry, but I'm still surprised nobody has asked about your Github stuff, assuming you've put decent things on there.
cookiecaper 9y ago
Doesn't surprise me, but if you're handing it out, you should still be prepared to answer questions about the stuff that's on there.

lettersdigits 9y ago

> What is the hardest technical problem you have run into? I never seem to find a quick good answer for this. Maybe I just almost never work on REAL hard things. So my question to you, HNers, is : What is the hardest technical problem YOU have run into? I am really interested to know what you would consider 'hardest'.. It's probably not going to be something like 'I changed the css property value from "display: block" to "display: inline-block"..'

smnplk 9y ago
There was this variable name I misspelled once ;)
- dom0 9y ago
  rm -rf $BUILROOT/∗
- AnimalMuppet 9y ago
  Heh. While still a student, I was working in Fortran (all upper case). I was trying to type COS (the cosine function), and I overshot the Oh character, and typed a zero: C0S. Not very visually different! It took me two days to figure out why Fortran suddenly didn't know what cosine was...
sedky 9y ago
I felt the same way. But it can be anything. "I sped up the page load on the site", "I redesigned the front-end to work on mobile", etc.
NickLarsen 9y ago
The localization project I use as an example here was definitely one of my top 3 hardest projects of all time (and that was years ago). It was not a particularly difficult technical challenge, it was difficult because it touched every single aspect of the codebase. The project took me and a coworker 3 months to build out the infrastructure for, then another 3 months of actually rewriting everything to use it, and explaining to every single other developer about why we made the decisions we made in order to teach them the different ways they were going to have to write code from now on. Social challenges of the workplace are hard; we're not always looking for technical difficulty.

dahart 9y ago

I see some criticism on this point, but for me this passage is a gem. > In general, real stories are told chronologically backwards. This is why we start off with a punchline. In contrast, practiced stories are told chronologically forwards. It’s a solid indication as the interviewer that the person is reciting something they have committed to memory if they tell the story forwards, and in turn it’s significantly more likely that the story isn’t entirely true. I have a friend who - bless his heart, I adore him, but can't get a quick story out to save his life. Every point he makes he reserves the punchline for last, and he starts by going on a back-story tangent first which usually forks into multiple back-stories. I've been trying to nudge him to turn it around and give away the punchline first, but he's deeply convinced that good stories are like movies and need to have a backstory followed by a narrative arc that doesn't make it's final point until most of the way through act 3.

inanutshellus 9y ago
Oh man, that's me for sure. I always backstory my tales to death. It does successfully take a minor conversation and turn it into an elaborate and interesting discourse but yes, as you say, it's not focused on the original punch line.
- ma2rten 9y ago
  I never realized it until now, but I think I might be doing that as well. I will try to be mindful of that. Thanks.
- dahart 9y ago
  There's a time and place for a good long meandering and elaborate backstory! Interesting conversation and discourse is something you should cherish and continue to develop. So, don't get me wrong, punchline first is not a rule, not always the goal. Just be aware of it, and you can start to decide which one to use. For job interviews, punchline first is good advice. For talking to your friends, it depends. For giving a talk or telling a story, backstory might be critical. Start playing with it and see how people react, find out when & how starting with the punchline is better. I think the point of the article is that punchline first is a tactic to get the other person talking and asking questions, rather than you talking for 5 minutes.

codingdave 9y ago

>In all likelihood, the interviewer doesn’t know what they are looking for with these questions, and they are just being used to fill time. Wait a sec -- just because the author of the article doesn't know how to get value from those questions doesn't mean that those questions hold no value. It is true that they won't give you information to help you in a tech screen, or to gauge the value of where to initially place a candidate on a team. But if you are trying to decide between a few candidates of equal skill, and trying to figure out which one will work better in a team environment, which will fit more smoothly into the personal dynamics between team members, who will grow better as the company grows, who might be a better leader or follower, and what their trajectory might be as the company and team evolves, these questions can lead you down those paths. Dismissing those questions as useless makes me think the author doesn't care about the people as individuals, but just as machines to be plugged in to produce code. And that doesn't sound like someone I would want to work for.

jakewins 9y ago
It's ironic actually. The author touts told stories of prior work as key, and degrades attempts at measuring candidate conscientiousness. Meanwhile, strongest known measures of job performance are an actual work sample (r=.26), rather than ability to describe a prior project, and measures of conscientiousness (r=.15). On conscientiousness: Barrick, Murray R., and Michael K. Mount. "The big five personality dimensions and job performance: a meta‐analysis." Personnel psychology 44.1 (1991): 1-26. On work samples: Roth, Philip L., Philip Bobko, and L. Y. N. N. McFARLAND. "A meta‐analysis of work sample test validity: Updating and integrating some classic literature." Personnel Psychology 58.4 (2005): 1009-1037.
cookiecaper 9y ago
It's the rote, cliche questions that show an interviewer doesn't really know what he's talking about. Questions about personality and culture are very important, but if someone asked "Where do you see yourself in 5 years?", it would point toward their not being a skilled interviewer. It's better to phrase the same question in any other way that's not associated with corporate ineptitude, like "What are your long-term career goals?"

deleted 9y ago

[deleted]

andy_ppp 9y ago

Never talk about yourself; steer the interview to being about a problem they are solving with work and help them run through how you would solve the problem as if it's a meeting and you are working with them. Rarely fails.

erikb 9y ago
I'd say it's not either or. Do both. Give a short summary of who you are with related projects you worked on. Explain shortly how these experiences made you an authority on their problem. Then explain how you would handle that problem of theirs.

cletus 9y ago

Let's translate shall we? > What is the hardest technical problem you have run into? "Tell me an unverifiable story in which you're the hero." I really hate this question: > Where do you see yourself in 5 years? Any post on HN about interviews draws a ton of comments, and they're usually the same comments as every other post on the subject. Honestly at this point having gone through a reasonably large number of interviews I think it comes down to brushing up on basic CS knowledge and, more importantly, whether or not they like you. As much as we like to make interviews dispassionate assessments of proficiency it really does seem like basic chemistry is the key issue. And honestly that makes a certain amount of sense: most people don't want to work with someone they dislike.

GoToRO 9y ago
Also, how bad they need to fill that position. You will get waaay less bullshit if they are in hurry.

bitwize 9y ago

I find I'm more willing to talk about myself if engaged in meaningful dialogue. For example, I get this a lot as an opening question, mainly from crooters (actual hiring managers almost never do this): "What are your skills?" You mean like numchuck skills, bow-hunting skills? If you don't know what kind of skills I have that could possibly be germane to the positions I'm looking for, you obviously didn't even read my résumé, which means you don't have a clue, which means I am hanging up on you because obviously you can't help me. If you say "Can you tell me about your role at company X, what sort of challenges you had, etc." I'm more willing to open up.

kafkaesq 9y ago

What is the hardest technical problem you have run into? Almost always asked from companies that don't have problems to offer even remotely comparable to the "war stories" they're expecting to you rattle off -- at least not for the position you're applying for, anyways.

tejtm 9y ago

> What is the hardest technical problem you have run into? well technically, the hardest problems I have encountered are not technical

ruleabidinguser 9y ago

Is this actually useful to people? Please don't give me non-answers like "well it got upvoted.."

tn135 9y ago

This is one of the best blogs on the topic and as someone who has easily cracked all big tech company interviews I can say this is a good piece of advice. I will make following broad points: 1. Never walk into that room without practicing. Practice before a mirror, practice before a friend, practice in a car. Have a written script and optimise it to remove redundancy, highlight achievements etc. It is not about repeating what you have practiced but having a free flowing conversation where you don't have to struggle for words, sentences all while maintaining a confident posture. 2. Converse not interview A lot of people fail to keep the conversation going. It is not like a FBI investigation. It is more like a friendly banter. Think of a scenario where you are talking to a potential roomie. It is okay to walk out of that interview without an offer but then you should feel good about having conversed with another geek just like you. --- Maintain the mindset outside of interview preparation. Most people fail at this. Good interview preparation begins months ahead. You need to look at your co-worker's code, give them feedback, learn to make needless improvements in your existing code, solve algorithms and discuss technical problems on stack overflow and else where. Built a mindset where you are able to talk about technical work to other people. Speak more, listen more and advice more at least 3 months ahead.

hueving 9y ago
If that's what it takes to get a job as an engineer at the big companies, it's not particularly surprising that the quality of their engineers has declined as they've grown. The skills of a con artist are not related to the ability to build good systems.
- alpha_squared 9y ago
  Conversely, the skills to build good systems are not related to working effectively with others. There's probably a balance that needs to be struck, though they're also not mutually exclusive.
  - dasil003 9y ago
    > the skills to build good systems are not related to working effectively with others Yes they are if you're talking about the types of systems that large companies have. It is in fact so difficult that I believe it's a considerable advantage to have scopes small enough to be manageable by a single engineer, but inherent complexity is often well beyond that, especially for very profitable business engines.

southphillyman 9y ago

I think behavioral and "tell me a time when" questions can easily be gamed, so I question the effectiveness of asking them. Sometimes I forget specific domain knowledge around a project I worked on 1+ companies ago. But I still have to list it on my resume and thus be able to speak to it...... so I just approximate the details. I imagine you could just full on lie as long as you can detail a technical problem and provide a solution to it.

freshflowers 9y ago

All that matters is having a good conversation and not appearing completely incompetent. After an enjoyable conversation, the hiring person will rationalize wanting you all by themselves, even if they have to make up / project qualities you've never demonstrated. 95% of the time, there's nothing rational about hiring.

bob1122 9y ago

This is incredible, thanks for sharing!

Tharkun 9y ago

Being prepared to talk is important. Knowing when to shut up is equally important. Recently interviewed a candidate who seemed promising, until they started to rant. I didn't want to interrupt them because I was hoping there was a point to be made at the end of the rant ... but in the end it was just 5+ minutes worth of "my current job isn't fair and everything sucks and everyone who is better than me really sucks too". Didn't hire.

nercht12 9y ago

For younger candidates, how about questions like: "Do you have a passion for this industry? Why?" and "What have you done in the past that demonstrates your commitment to completing anything you set your mind to?" For older candidates, how about questions like: "What do you consider your driving factor?" (with possible answers like "good benefits" or "complex challenges" or "teamwork") and "What sort of challenges do you see in this field/industry and how would you go about solving them?" (with acceptable answers from technical development solutions to "let's outsource" or something creative - something that demonstrates their wisdom, even if the field isn't their expertise).

martimoose 9y ago

When I read articles about job interviews, I always wonder what is the correlation coefficient between "being good at interviews" and "being good at doing your actual job".