by NickLarsen on 4/28/17, 11:34 AM with 191 comments
by lettersdigits on 4/28/17, 2:38 PM
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"..'
by wallflower on 4/28/17, 2:04 PM
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,_Resul...
by tn135 on 4/28/17, 7:33 PM
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.
by a3n on 4/28/17, 1:55 PM
> 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.
by dahart on 4/28/17, 2:42 PM
> 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.
by sweezyjeezy on 4/28/17, 2:34 PM
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.
by digoM on 4/28/17, 2:08 PM
by cletus on 4/28/17, 5:06 PM
> 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.
by ganley on 4/28/17, 1:22 PM
by andy_ppp on 4/28/17, 5:04 PM
by codingdave on 4/28/17, 3:26 PM
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.
by midgetjones on 4/28/17, 1:41 PM
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.
by bitwize on 4/28/17, 6:33 PM
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.
by Tharkun on 4/28/17, 9:58 PM
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.
by freshflowers on 4/28/17, 8:27 PM
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.
by nercht12 on 4/29/17, 2:53 AM
by kafkaesq on 4/28/17, 7:04 PM
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.
by samlittlewood on 4/28/17, 1:37 PM
by southphillyman on 4/28/17, 7:36 PM
by tejtm on 4/28/17, 7:11 PM
well technically, the hardest problems I have encountered are not technical
by ruleabidinguser on 4/28/17, 7:27 PM
by martimoose on 4/29/17, 1:23 PM
by mwcampbell on 4/28/17, 2:18 PM
by bob1122 on 4/28/17, 8:38 PM