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

How to Interview Engineers

blog.triplebyte.com

Post reply on HN
Print view View original

401–410 of 489 posts

Re: How to Interview Engineers

#401

Post by sqeaky »

dexterdog wrote: post #62
padobson wrote: post #9

Spending a week working beside an engineer (or seeing how they complete a substantial project) almost certainly provides a better measure of their abilities than watching them solve interview problems for 1 hour Trial employment is expensive for the company. [...] Trial employment (and large take-home projects) are expensive for the candidate. I can't help but think there's way to mitigate that expense among several…

So I pay for 1.6 hours of this candidate, but then if I want him I have to hope either nobody else wants him or that I am paying more than the others.

Is that so different from normal interviews? At least this way you can't forget you are competing.

Re: How to Interview Engineers

#402

Post by pklausler »

silverpikezero wrote: post #391
dsacco wrote: post #299

Earlier quoted context omitted.

I used to disbelieve hiring managers regularly encountered candidates who actually couldn't code, or whatever other basic technical thing was reported on their resumes. Such a possibility - even the audacity of it on a conceptual level - simply seemed beyond the pale for me. I had interviewed before and not done well, and that I could absolutely understand. But I had no way of relating to the idea of someone entering…

I experienced the exact same feelings as you. Until I started interviewing candidates in quantity, I had no clue how many candidates cannot complete FizzBuzz. The reported failure rates of this simple test are completely legitimate. In my own interviewing, it comes out at about 50/50. The 50% who do pass often make some significant conceptual mistake, for which I'm generally pretty forgiving since interviews can be a…

Do you actually use the real well-known FizzBuzz problem, or some other exercise that you think is comparably trivial?

Re: How to Interview Engineers

#403

Post by sqeaky »

fnord123 wrote: post #246
mychael wrote: post #239

> background-blind interviews, looking at coding skills, not credentials or resumes. Subtext: "Did you create a famous open source tool, write a book, have patents in your name or architect some amazing system at a big company? Doesn't matter! Our hiring process prefers code monkeys who can solve our puzzles instead of system thinkers." > An interview can result in a bad engineer being hired and later fired (a false…

>Subtext: "A hire can either be good or bad. It's never management's fault if it doesn't work out." I agree that the article gets this wrong. It reminds me of Diego Forlan's time at Manchester United. Diego Forlan is/was an Uruguayan striker at Independiente (Arg) where he scored 36 goals in 77 games (a very good rate). He then moved to Manchester United (Eng) in January of 2002 and was anticipated to take off. He ma…

Did they really get it wrong? Very few candidates are Diego Forlan, very few wrote books, verfy few created a foundational open source project, etc...

I suspect candidates that wrote the Linux kernel, Rails, Modern Effective C++ etc... don't need a recruiters services. If whatever candidate wrote is not so big as to land them jobs almost automatically then was it really that big as to demand consideration separate from college degrees and other ignored history?

I think we dislike the idea of our history being ignored because we all feel that we are special, but in reality very few of us are.

Re: How to Interview Engineers

#404

Post by collyw »

vaishaksuresh wrote: post #30
ammon wrote: post #2

An interesting point my co-worker made is that, almost by definition, if an interviewee does not know how to answer a question, they don't know why that question is important or where that type of problem is applied. So from the point of view of an interviewee who's can't do well on all the questions (that's most of us in most interviews) some of the question will always seem like minutiae / lacking application. (Of…

>if an interviewee does not know how to answer a question, they don't know why that question is important or where that type of problem is applied I would argue that not knowing answer and not knowing question are two different things. I may not know answer to a questions, but know that the question exists. I personally am comfortable not remembering things that I can easily look up.

I don't know the answer but I know how to get it.

Re: How to Interview Engineers

#405

Post by kafkaesq »

kafkaesq wrote: post #158
weaksauce wrote: post #138

Earlier quoted context omitted.

I think the best part of this is how many people are getting it wrong in the comments here or not fully thinking it through. Perhaps it's not as easy a question as you think it is in the heat of the moment during a stressful interview?

Perhaps it's not as easy a question as you think it is in the heat of the moment during a stressful interview? This point cannot be underemphasized. "Thinking aloud", not just in front of another person but under a very stressful situation (for most people) that also basically almost never occurs otherwise in daily life -- is a specific metacognitive skill that for many people can only be (even adequately) learned by…

This point cannot be underemphasized.

Edit: that should be 'overemphasized', of course.

Re: How to Interview Engineers

#406

Post by cr0sh »

nsxwolf wrote: post #347
kudokatz wrote: post #340

Earlier quoted context omitted.

> 30 year old programmer with a 2 year old child at home ... nix him on the "merits" of ageism A choice, conscious or not, to dedicate time to raising a child at the opportunity cost of myriad other ways to spend time is not related to ageism at all.

Most programming jobs do not actually demand one make this form of Sophie's Choice. Perhaps the Valley is so diseased, but it's not the only game in town.

> Perhaps the Valley is so diseased, but it's not the only game in town.

Hear! Hear!

One of the things that bothers me a lot about HN is the near assumption that if you're a software engineer and not in SV (or have never been in an SE job in SV) - you don't count as much.

I'm biased, I will admit: I've never held a software engineering job in the Valley. That opportunity has never occurred, nor have I tried to pursue it. I live and work in Phoenix, Arizona; at my age and position in life, even if the opportunity did present itself, I'd have to think long and hard about it. It would likely be a situation of me leaving my family to go work there, as relocation would likely not be a realistic option unless the pay was over the top (I am not going to move back to an apartment; my next house better be at least as large as my current one, and include a larger yard and/or shop space before anything else).

Here, in my current position, I am not only the oldest developer on the entire team (and I am only a few years younger than the owner of the company), but I also am one of the few who doesn't have any children. My wife and I made the conscious choice not to have kids a long time ago, and we are constantly glad for it. In fact, she thanks me on a monthly basis for not "knocking her up".

Honestly, we'd probably make terrible parents, and we're pretty selfish as a couple. We know this, so why bring children into the mix, right?

That said - here in Phoenix (where it's actually difficult to find competent software engineers for any position), I've never seen or experienced there being an issue if you have kids; every employer I've worked for has been extremely flexible.

In fact, both at my current employer, and my previous one, they encouraged you to leave when your day was up. If the end of your day was at 5pm, they didn't want you stay a minute more if there wasn't a really good reason for it. Like things would have to be well and good on fire for that to happen; anything less was "go home, get some rest - it'll be here to fix tomorrow".

Re: How to Interview Engineers

#407

Post by kafkaesq »

lopatin wrote: post #166
kafkaesq wrote: post #158

Earlier quoted context omitted.

Perhaps it's not as easy a question as you think it is in the heat of the moment during a stressful interview? This point cannot be underemphasized. "Thinking aloud", not just in front of another person but under a very stressful situation (for most people) that also basically almost never occurs otherwise in daily life -- is a specific metacognitive skill that for many people can only be (even adequately) learned by…

Being a professional programmer is not an entirely stress-free job. Often, time matters and you have to think on your feet. That's why I think rejecting a programmer for losing their core competencies like problem solving, i.e. freezing, under a medium amount of pressure is valid.

Being a professional programmer is not an entirely stress-free job.

Sure -- it's just the tenor (and for some people, sheer intensity) of the psychological stress experienced during interviews is, for many people, basically orthogonal to the stress of real-life work situations -- or even genuinely dangerous (even physically threatening) situations in life, otherwise.

With the latter, it's like "Oh shit - the client's gonna get real pissed if I don't figure something out real quick".† Or even: "That guy looks like he's about to lunge at me - I better think of something!" For which your brain and your glands have benefitted from millions of years of evolution in support of mechanisms for pumping just the right kind and amount of juice into your system to "figure something out".

But with interviews it's more like: "This person's evaluating me, using some hidden criteria. Given that the problem is slightly tricky, I literally don't know if they're expecting to power on at all costs, or, secretly, that I simply admit that I don't know where to start just yet. Not only that, something tells me he's not stating the problem quite correctly -- they do that, no all the time, but way too often in these kinds of interviews. And on top of that he's just being plain overbearing... and now he's starting to fiddle with his phone. On top of starting 15 minutes late. Like he never really wanted to talk to me in the first place. If I ask too many questions -- or even just one instance of the wrong kind of question -- I'm screwed, and gonna have to hit my inbox for leads again. Oh great, now he's starting to offer 'hints', completely derailing my flow of thought and whatever self confidence I thought I had. Fuck it -- I just should bail and go work on my personal projects. No one will be paying me $150k but at least I'll be learning something."

† Where "the client is gonna get real pissed" is roughly equivalent to "if I can't get these rocks to flake in just the right way, we aren't gonna have any more arrowheads and were' all gonna starve!", to a first order approximation.

Re: How to Interview Engineers

#408

Post by kafkaesq »

zimzam wrote: post #177
lopatin wrote: post #166

Earlier quoted context omitted.

Being a professional programmer is not an entirely stress-free job. Often, time matters and you have to think on your feet. That's why I think rejecting a programmer for losing their core competencies like problem solving, i.e. freezing, under a medium amount of pressure is valid.

I've been a developer for years and worked for multiple companies: the most stressful professional situations I've ever have been in have been maybe a 4 out of 10 stress-wise, whereas interviews range from 7 to 9 out of 10. Interviews aren't ordinary job situations: they are contrived situations where people are making life-changing decisions based on a very short interaction.

The most stressful professional situations I've ever have been in have been maybe a 4 out of 10 stress-wise, whereas interviews range from 7 to 9 out of 10.

Agree mostly -- just that I guess I've fallen into more abusive environments than I should have allowed myself to over the years, where the stress levels have hit will into the 7-10 range.

But in healthy environments -- even when I really did screw something up (sometimes quite significantly) -- it's never above the 4-5 range.

Interviews aren't ordinary job situations: they are contrived situations where people are making life-changing decisions based on a very short interaction.

And pretending that they can read the tea leaves, and make that kind of assessment as to "whether this guy can handle a medium amount of pressure", to boot.

Re: How to Interview Engineers

#409

Post by kafkaesq »

FilterSweep wrote: post #316
cnp wrote: post #222

Earlier quoted context omitted.

Same here, and have worked on some extremely high-profile, complex things. Never _ever_ have I been as stressed as when asked to perform interview whiteboard questions. It simply doesn't compare.

Sometimes, you just have to appreciate the Torvalds-level of arrogance expressed in some of replies on HN.

You're reading too much into it. That wasn't Torvaldsian at all, by my reading.

Re: How to Interview Engineers

#410

Post by kafkaesq »

watwut wrote: post #229
Bahamut wrote: post #210

Earlier quoted context omitted.

I've had it happen - just in my past job search the past few weeks, I had a total blankout in my last Google interview session in person on a dynamic programming question, and I'm pretty sure that ended up being the reason why I got rejected as I felt pretty good about all 4 of my prior sessions. I am about to start work as a senior engineer for Apple with 4 1/2 years of experience, after passing two back-to-back ons…

I know it happens, but I don't think it happens to majority of people. Bad days are caled that way because they happen once in a while, not constantly. You had good three interviews and one bad at Google. You passed well at apple. That really sounds like bad day. But then there are people for who practicaly any question beyond "lets talk in general about what you like and how passionate for technology you are" is unf…

But then there are people for who practicaly any question beyond "lets talk in general about what you like and how passionate for technology you are" is unfair and causes black out entry single time. Thay is entirely different.

But that's the thing -- it literally takes just one person out of 5 or 6 to say "I don't know about this guy" to get the rest of the team to pass. No matter if he didn't seem all that well prepared or interested in you, you guys just didn't click, or you were exhausted because no one thought to let you get coffee or use the restroom.

Post reply on HN