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

171–180 of 194 posts

Re: How to talk about yourself in a developer interview

#171

Post by Manchit »

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…

Yes, it's kind of difficult to define the 'hardest' problem. Some issue I considered 'hard' is more because of my missing relevant knowledge in this field rather than the nature of the issue. And of course, I don't want to say "I spent a few hours to learn something to get things done, which is just changing a property value".

Re: How to talk about yourself in a developer interview

#172

Post by cbanek »

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…

One way I play this is to be like, "well I've blocked out the hardest problems, probably due to trauma, but here's a problem that I worked on that might apply to what you guys are doing here."

I find this easier because usually hearing the interviewer talking about things will trigger my memory as to when I was working on similar problems. It's probably better for them to know a relevant example anyway.

Re: How to talk about yourself in a developer interview

#173

Post by Tharkun »

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.

Re: How to talk about yourself in a developer interview

#174

Post by cthalupa »

dahart wrote: post #167
cthalupa wrote: post #137

Earlier quoted context omitted.

> 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. This is awful and just co…

Interesting opinion. I find the quote somewhat true, and the article's broader point mostly true and rather valuable. The broader point of that quote is that a dynamic conversation usually does reveal more truth and paint a more accurate picture than a practiced story. I find that to be very true. I feel like you might have misunderstood the article and decided it was wrong before taking the time to understand. That…

The quote is quite explicit - 'If you tell a story chronologically, you're more likely to be fabricating it'

I'd argue that my response isn't hyperbolic, and is justified considering how ludicrous that statement is.

How do STAR and SOARA not dictate chronology? You specifically discuss the initial situation first, and the results you achieved last (or the analysis of the results).

Re: How to talk about yourself in a developer interview

#175

Post by dahart »

cthalupa wrote: post #174
dahart wrote: post #167

Earlier quoted context omitted.

Interesting opinion. I find the quote somewhat true, and the article's broader point mostly true and rather valuable. The broader point of that quote is that a dynamic conversation usually does reveal more truth and paint a more accurate picture than a practiced story. I find that to be very true. I feel like you might have misunderstood the article and decided it was wrong before taking the time to understand. That…

The quote is quite explicit - 'If you tell a story chronologically, you're more likely to be fabricating it' I'd argue that my response isn't hyperbolic, and is justified considering how ludicrous that statement is. How do STAR and SOARA not dictate chronology? You specifically discuss the initial situation first, and the results you achieved last (or the analysis of the results).

The quote didn't say "fabricating", it said "not entirely true." The way you're interpreting the quote, it would be ludicrous, I can agree. The way it was actually written, along with what I interpret to be the broader point, I think the article is somewhat true, and has a valuable message.

STAR and SOARA are a way for the interviewer to drive the requests for information, force a conversation, try to frame the question so that candidates can be more easily compared, and prevent the candidate from rambling and offering irrelevant information. The article's suggestion has the same goal, aside from the truth detection part, which I'm downplaying here.

Don't focus on a single quote and ignore the article's larger context. The author also said "If you get too far into a story without making sure they are still with you, it comes off to the interviewer that you cannot explain things well." and "If it’s not obvious yet, force the interview to be a conversation." All of the sections lead to "force conversation", if you can get past the part about speaking backwards being more truthful.

Conversations almost always run backwards, in portions. Anytime you answer a "why?" question for example, you're telling the first part last. I suspect that's what the author was trying to say, less that narratives should always be presented backwards, and more that conversations are desirable and conversations often run backward.

Re: How to talk about yourself in a developer interview

#176

Post by miranda_rights »

cs02rm0 wrote: post #57
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 ju…

I'm currently a wet behind the years (hopeful) Java developer -- what's cringey about a modification to a kernel driver being hard? That sounds pretty intimidating to me.

Re: How to talk about yourself in a developer interview

#177

Post by mythrwy »

alok-g wrote: post #156
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…

>> What is the hardest technical problem YOU have run into? I have solved about ten "hard" problems in my career, most of which has been in R&D. Each one of these had multiple prior failed attempts, and in some cases took me months of thinking before I could find a solution. 1. Qualcomm wanted me to devise a computer vision solution that was more than two orders of magnitude power-efficient than what they had then. T…

''''' Hmm, so, great. That's interesting.

So, um, how would you say your skills deploying to NodeJS are. Would you rate them as strong? Tell you what, lets go ahead and break for lunch now and Sam is going to show you around the campus a bit and then we'll continue with a follow up and some coding challenges. """""

Re: How to talk about yourself in a developer interview

#180

Post by wernercd »

cookiecaper wrote: post #139
wernercd wrote: post #123

Earlier quoted context omitted.

"This is not impressive" That's because I've given you a mile high description. We have an outside consultant who does one thing: Fix businesses. When he says this is the worst situation he's ever seen? I take it with a little more weight than I'd take someone else saying it. While I understand and don't disagree with what you say - a full rewrite is normally not the answer - you haven't seen this codebase. Or the co…

>When he says this is the worst situation he's ever seen? I take it with a little more weight than I'd take someone else saying it. I take it as a consultant emphasizing biases that favor his presence. Anyway, the point of my comment was not to nitpick your specific situation, which I have no information about and obviously cannot speak about intelligently. Perhaps it is as extreme as you indicate. If so, my only sug…

I agree on all points - the consultant has his own objectives just like the owners and my manager.

Is it the worst situation EVER!...? Undoubtedly not... but its definitely twisted like a pretzel with problem layers on top of problem. But we also aren't "rewriting from scratch" - that would be too difficult. We are replacing pieces one at a time and breaking/fixing as we go.

I'm compensated enough for the stress and like the people and environment enough to offset the "overall situation".

But yeah... my main point was to say that moving a company from "old broken" to "new shiney fixed" while keeping everything working, adding new features, etc is, at the heart, the largest technical challenge I've faced.

Devil is in the details - and "spinning" it correctly without bad mouthing the company (Which I do like, otherwise I'd not still be there) and while keeping to that main point (upgrading a company) is... interesting.

Finangaling the finer words isn't my top skill :)

Post reply on HN