> What is the hardest technical problem you have run into?<p>I never seem to find a quick good answer for this.<p>Maybe I just almost never work on REAL hard things.<p>So my question to you, HNers, is :<p>What is the hardest technical problem YOU have run into?<p>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"..'
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.<p>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.<p><a href="https://en.wikipedia.org/wiki/Situation,_Task,_Action,_Result" rel="nofollow">https://en.wikipedia.org/wiki/Situation,_Task,_Action,_Resul...</a>
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.<p>I will make following broad points:<p>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.<p>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.<p>2. Converse not interview<p>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.<p>---<p>Maintain the mindset outside of interview preparation. Most people fail at this.<p>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.
> 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<p>> Where do you see yourself in 5 years?<p><i>Dead</i>.<p>> Why do you want to work here?<p><i>You have money.</i><p>> How do you handle disagreements with coworkers?<p><i>Attempt constructive engagement, and if that doesn't work then shun them.</i>
I see some criticism on this point, but for me this passage is a gem.<p>> 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.<p>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.
> 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.<p>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>I</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.
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: <a href="http://www.businessinsider.com/google-laszlo-bock-interview-questions-2015-4" rel="nofollow">http://www.businessinsider.com/google-laszlo-bock-interview-...</a>
Let's translate shall we?<p>> What is the hardest technical problem you have run into?<p>"Tell me an unverifiable story in which you're the hero."<p>I really hate this question:<p>> Where do you see yourself in 5 years?<p>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.<p>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.
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.
>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.<p>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.<p>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.
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.<p>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.
I find I'm more willing to talk about myself if engaged in meaningful dialogue.<p>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?"<p>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.<p>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.
Being prepared to talk is important. Knowing when to shut up is equally important.<p>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".<p>Didn't hire.
All that matters is having a good conversation and not appearing completely incompetent.<p>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.<p>95% of the time, there's nothing rational about hiring.
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).
<i>What is the hardest technical problem you have run into?</i><p>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 <i>you're</i> applying for, anyways.
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.
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.
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".
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.