Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to talk about yourself in a developer interview

stackoverflow.blog

Post reply on HN
Print view View original

51–60 of 194 posts

Re: How to talk about yourself in a developer interview

#51

Post by ma2rten »

inanutshellus wrote: post #41
dahart wrote: post #25

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 mor…

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.

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.

Re: How to talk about yourself in a developer interview

#52

Post by dahart »

wallflower wrote: post #11

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

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.

Re: How to talk about yourself in a developer interview

#53

Post by pvinis »

lettersdigits wrote: post #22

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

The way I think about that question, and in fact that's the question I have gotten many times, is "what's a technical problem that you solved and you are the most proud of?". In this question, 100% of developers have an answer. Everyone has done something that needed a bit of thinking or planning, and then they were proud of the execution. It can be the hello world in a new language or it could be building Facebook, or whatever else in between and beyond. If you think you don't have any of those, think again. Many times this answer changed during your time as a developer, but there is always at least one answer, no matter your level, experience, etc.

Personally, many times I answer with a time where I decided to re-engineer and rewrite a "snapping engine". It helped with snapping boxes together when they are close to each other in a 2d design application. Unexpectedly difficult to write with some features we wanted, but after a couple of iterations, I finished, and since then, new features and plugins worked perfectly and nicely together, and were easy to add and implement.

Re: How to talk about yourself in a developer interview

#55

Post by dahart »

inanutshellus wrote: post #41
dahart wrote: post #25

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 mor…

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.

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.

Re: How to talk about yourself in a developer interview

#56

Post by dnackoul »

lettersdigits wrote: post #22

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

I like to think about this question in three parts: scope, depth, and originality.

The scope of the project is the size and ambiguity level. Ideally as you get more experience your scope grows. Whenever you're coming out of school, your answer to this question might be a tricky bug fix but after a few years it might be something like "we needed to build a system to flag and filter fraudulent users based on their site activity."

Depth is about how much detail you can talk about the project in. If you choose a project with a big scope, can you drill down and talk about the implementation details of each component? If you chose a bug fix, can you describe exactly what triggered the bug as opposed to just knowing what fixed it?

For originality, what about the problem made it non-trivial to solve with out of the box tools? For the fraud case above, maybe the data was stored in a format that was hard to analyze. Or maybe for people at the bigger companies there were scaling issues that requipped unique solutions. For bug fixing, maybe it was a bug that was really hard to reproduce and you had to do a lot of memory dumps and code analysis to pinpoint it.

When I finish something I like to think about it along those three axes for a little bit in case I need to recall details later.

Re: How to talk about yourself in a developer interview

#57

Post by cs02rm0 »

lettersdigits wrote: post #22

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

I lie.

When I was a young, wet behind the ears, Java developer I answered telling them about making a modification to a Linux kernel driver for hardware support. It was a telephone interview but the silence was deafening. Still the only interview I ever had where I wasn't offered the job.

Some things haven't changed in that it is when I step outside my comfort zone I find the technical problems harder. But now I'd just talk about a more comfortable problem that went through multiple rounds of better fit solutions on a system actually in Java so they can relate and see I can actually talk about the target language. Then I'd probably make the point that as a more senior developer it's usually the non-technical problems that require my most focus.

Still makes me cringe thinking about it.

Re: How to talk about yourself in a developer interview

#58

Post by eropple »

TheCowboy wrote: post #26
existencebox wrote: post #10

Earlier quoted context omitted.

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 fl…

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 u…

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.

Re: How to talk about yourself in a developer interview

#59

Post by eropple »

ryandrake wrote: post #47
beamatronic wrote: post #21

Earlier quoted context omitted.

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.

I've never thought that was a fair question, because it's actually pretty rare to be able to work on something you enjoy and end up proud of. The way I see it, one of the reasons I'm interviewing with you is that I hope that the best of my career is ahead of me, and that the project I'm most proud of is the one I'll be working on next.

I ask a variant of this question when I interview, and if you said this? I mean, people vary, but I think this is a totally valid and good answer. Because I have a lot of shitty gigs in my past, too--the signal that "I'm moving on because I want to work on things I'm proud of" is a pretty powerful one. (It's gotten me gigs before, too.)

Re: How to talk about yourself in a developer interview

#60

Post by dom0 »

dhd415 wrote: post #39
lettersdigits wrote: post #22

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

In >15 years of professional development, I've probably worked on only one project in which there were any significant technical challenges. I should probably consider myself fortunate that I've had even that one technically challenging project. It was a lot of fun, but it has been rather demoralizing looking for equally challenging work since then and largely failing to find it. I think much of the reason for that i…

"Complexity is like a bug lamp for smart people. We're just attracted to it."
Post reply on HN