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

351–360 of 489 posts

Re: How to Interview Engineers

#351

Post by vorpalhex »

JoeAltmaier wrote: post #306
FilterSweep wrote: post #304

Here's a concept I had a question about that I don't think gets discussed that often... If a company were to offer a base salary at a mere third of the Google base salary for the same job, why should an applicant have to copy Google's depth of computer science abstraction in the coding interview? Is the onus on the developer for even entertaining such a demanding question at a low pay, or does the current economy fav…

I don't see a connection between pay and the interview process. Should the company also make their chairs one-third the height? Have one third the whiteboard marker colors? Feed you one-third of a lunch?

My willingness to jump through hoops is proportionate to how much I want to work with you. If you pay me well and treat me well, I want to work with you. If you're trying to hire me for 50% of market, my tolerance is much lower.

Re: How to Interview Engineers

#352

Post by kodr »

JoeAltmaier wrote: post #306
FilterSweep wrote: post #304

Here's a concept I had a question about that I don't think gets discussed that often... If a company were to offer a base salary at a mere third of the Google base salary for the same job, why should an applicant have to copy Google's depth of computer science abstraction in the coding interview? Is the onus on the developer for even entertaining such a demanding question at a low pay, or does the current economy fav…

I don't see a connection between pay and the interview process. Should the company also make their chairs one-third the height? Have one third the whiteboard marker colors? Feed you one-third of a lunch?

well, if you interview for a nurse position, you shouldn't have to pass the doctor interview.

Re: How to Interview Engineers

#353

Post by JoeAltmaier »

kodr wrote: post #352
JoeAltmaier wrote: post #306

Earlier quoted context omitted.

I don't see a connection between pay and the interview process. Should the company also make their chairs one-third the height? Have one third the whiteboard marker colors? Feed you one-third of a lunch?

well, if you interview for a nurse position, you shouldn't have to pass the doctor interview.

Oh. I thought the statement was "for the same job".

Re: How to Interview Engineers

#354

Post by ubernostrum »

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.

Why not go all the way, then?

Armies train people by having them run obstacle courses with guns being fired all around them. Do a "realistic" interview, then, to really test how someone does "under pressure". Have them sitting alone in the room, and a screaming angry manager runs in yelling obscenities at them about how the production system is down, it's costing the company millions of dollars, and if they want to have a job they'd better get it fixed ASAP!

And have that same manager stand over their shoulder the whole time, yelling yet more obscenities. If the candidate doesn't get it fixed in, say, five minutes, then obviously they lack even the most basic qualifications to work as a programmer and you can reject them. Heck, save money and don't even do it on-site -- get their phone number and do it 3AM on a weekend, just like a real on-call situation!

Or... maybe the whole "under pressure" thing is just an excuse people use to cover for the fact that they like making people squirm, enjoy the feeling of power they have from knowing someone else's future is in their hands and that person knows it, and want to savor by making the trained monkey stand up and dance on command... or else.

Unfortunately, people who like the "under pressure" idea of interviewing seldom realize that sooner or later they're going to be the monkey and someone else will be the organ grinder.

Re: How to Interview Engineers

#355

Post by ubernostrum »

watwut wrote: post #203
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…

I wonder how all those people unable to answer interview question passed school. I don't think they are fraudsters, they are simply not too good programmers who can't solve simple problems by themselves. Many dudes believe themselves to have technical talent just for memorising done basis. That does bit imply problem solving ability. Momentary blackouts happen - rarely.

Momentary blackouts happen - rarely.

Funny thing -- these folks have, y'know, actual data on this stuff:

http://blog.interviewing.io/you-cant-fix-diversity-in-tech-w...

Choice quote:

As you can see, roughly 25% of interviewees are consistent in their performance, but the rest are all over the place. And over a third of people with a high mean (>=3) technical performance bombed at least one interview.

Re: How to Interview Engineers

#356

Post by WorldMaker »

rpeden wrote: post #284
deathanatos wrote: post #167

Earlier quoted context omitted.

I have similarly asked "write a function, minimum(), that takes a list of integers and returns the smallest integer in the given list" for quite some time. It's disturbingly effective. I've always asked something that involved a loop, to ensure that candidates understood how to write a for loop. (I have a variant of the above, a "more complicated" question, that involves maintaining two pointers/iterators; that remov…

A decently clever candidate could sneak out of that first one without a loop. Something like numbers.reduce((a,b) => Math.min(a,b)) would do it in JavaScript. In general, if a candidate realizes they can use reduce for that purpose, in my experience interviewing candidates they probably wouldn't have much trouble doing it with a loop, and it would usually be a signal they're going to have a pretty good interview. The…

I find that's a telling way to determine the experience of the interviewer. I'm saddened by the number of times an interviewer has asked me, "What is a reduce? How does it work?" Of course, that information isn't very helpful in the flow of an interview, it's mostly just upsetting.

Re: How to Interview Engineers

#357

Post by ubernostrum »

cl0wnshoes wrote: post #319

I've performed interviews and phone screens for years and out of all the techniques I've tried all of them typically end up with me thinking I'm doing it wrong. Basic domain questions, problem solving, white boarding, white boarding along side the person helping them out, coding in an IDE, take home projects. As of today, in Kansas City, I'm looking at around 4% pass rate, and close to 90% utter face palming failures…

You know the quote: if you encounter an asshole first thing in the morning, you encountered an asshole. If you encounter assholes constantly all day long, it's probable you're the one who's the asshole.

If you have a 90% rate of "utter face palming failures", the problem isn't with the people you're interviewing, it's with the interviewer and/or the interviewing process.

Re: How to Interview Engineers

#358

Post by wmil »

roflc0ptic wrote: post #297
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…

>> "Thinking aloud" ... is a specific metacognitive skill Is there evidence for this claim? I'm inclined to believe it but that's experiential. It's also something I've never had to work to acquire, but that could be a cultural thing (my family and friends talk a lot about thinking) or a personal history thing (I have a minor learning disability, and it has forced me to develop strong, conscious meta-cognition). It's…

I think psychology has a lot of models of cognition without a clear winner, so there's probably no conclusive answer at the moment.

But talking through a problem forces you to use verbal reasoning. A lot of programming can be done well with non-verbal reasoning skills.

Personally, quickly sketching some timelines on a piece of paper would be the fastest way to get the correct checks. Talking it through would force me to convert my mental visualizations into words, and that'd make me stumble.

Re: How to Interview Engineers

#359

Post by ubernostrum »

jkaptur wrote: post #192
timebomb wrote: post #63

Where I work, we'd be totally happy to ask interviewees how to reverse a binary search tree. As soon as an actual developer creates a pull request that does as such. Which hasn't happened yet. So we don't ask about things like that. And everyone seems happier.

I don't get it. Programmers are surrounded by trees. The filesystem, your code's AST, dependency trees, the HTML DOM, any JSON ... why do people consider it so unreasonable to ask a question about simple manipulation of a well-understood tree data structure?

Because it implicitly selects for inexperienced/mediocre candidates over experienced ones.

Even among people who did a degree that involved implementing these algorithms, 99% or more will never do it again once they set foot off their campus, because they'll just use a library that already has it implemented. Then they'll free up room in their brain's working set for the stuff they actually do have to implement. And the longer they go like that, the longer it'll take and the more difficult it'll be to find where all those tree algorithms got paged out to in their brain, and the worse they'll look on an interview which consists solely of asking for that stuff.

Meanwhile, the inexperienced and likely unqualified (given what people claim about the average CS graduate) person who just walked out of their college graduation still has it fresh and ready to regurgitate onto your whiteboard, and passes with flying colors: great technical skills, great "fundamentals", A+++++ hire ASAP!

The solution to this is to stop using proxies for the thing you want to know, and start actually testing for the thing you want to know.

Re: How to Interview Engineers

#360

Post by loup-vaillant »

Stratoscope wrote: post #162
barrkel wrote: post #129

Earlier quoted context omitted.

It's actually a tricky problem to think clearly about unless you start enumerating the cases, or get pen and paper out to draw some boxes. I don't think it's completely trivial to verbalise. But I also don't think a competent programmer should fail to work it out. I like the problem, and I'll probably use it in future :) It'll be a low bar for those times where you're getting the impression that a bigger task will be…

It may be easier to verbalize than we think. I just realized that for me the trick might be to not be too abstract and formal when first thinking it out, but look at it more like an everyday problem. Instead of this: "Given two appointments, one that starts at time A and ends at time B and another that starts at time C and ends at time D, how can I tell if they conflict?" More like this: "I need to run another errand…

Funny; for me, the abstract version is exactly what I need. And the answer pops out almost immediately:

  B
(Assuming A <= B and C <= D, for which I may ask the interviewer about.)
Post reply on HN