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

281–290 of 489 posts

Re: How to Interview Engineers

#281

Post by qb45 »

rasen58 wrote: post #181
gilbetron wrote: post #168

Earlier quoted context omitted.

A weeder question I've used: How many operations can a modern CPU perform per second: A) Thousands, B) Millions, C) Billions We'll accept C, and B with explanation. I'd say roughly 75% of the people I've asked (who have gotten through a phone interview) cannot answer it with any ability. People whine about the difficulty of interviews, but honestly, almost everyone we've ever hired have said the interview was pretty…

I feel like that's a bad question to ask. An algorithm question at least lets you attempt it and you can see if they know things. But this question isn't something that people normally talk about or think about. I think older engineers would think this is a normal question to ask since they/you have seen the evolution of computers over time, and have actually seen the number of operations changing to get into the bil…

> But this kind of thing may only be mentioned in one sentence in an intro computer systems course, and most young people wouldn't care about how many operations a CPU can do.

TBH, I'm slightly disturbed by these "young people" who have completely no idea how machines actually work.

But the question is silly because there are better ways to ask people if they know in case you require that they know and you probably shouldn't be asking anything at all if you don't care if they know.

Re: How to Interview Engineers

#282

Post by sangnoir »

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.

The kinds of pressure are different - unless if at your organization you do your time-critical coding in front of a panel with varying mixes of what looks like disappointment, boredom, impatience and eagerness to "give you a hint" on how they would solve it while thoroughly confusing you. If not, you are measuring the wrong metric to gauge potential candidate success.

Re: How to Interview Engineers

#283

Post by macca321 »

pklausler wrote: post #73

The sad reality of programming interviews is that it's absolutely necessary to ask several near-trivial questions in order to flush out the candidates with awesome resumes and impressive degrees who simply have no idea how to analyze a simple problem and solve it using a computer. Lately, I've been asking "given the starting and ending times of two calendar appointments, determine whether or not they conflict." No lo…

The problem with interviews is that there is no time for false starts. When approaching a coding problem in real life, I pick a solution that seems to be right.

Half the time I pick a good solution and half the time I've rushed in and picked the wrong one.

If I have picked the wrong one, I know within 30 mins that it is a flawed approach, but have usually explored the problem sufficiently to pick a good solution. The interview unfortunately ends after 30 mins.

I should also add that I'm not much better at this after 13 years of professional development than I was when I left uni, when it comes to manipulating linked lists and arrays. My systems design is a lot better though.

Re: How to Interview Engineers

#284

Post by rpeden »

deathanatos wrote: post #167
pklausler wrote: post #73

The sad reality of programming interviews is that it's absolutely necessary to ask several near-trivial questions in order to flush out the candidates with awesome resumes and impressive degrees who simply have no idea how to analyze a simple problem and solve it using a computer. Lately, I've been asking "given the starting and ending times of two calendar appointments, determine whether or not they conflict." No lo…

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.

Then again, you might run into a joker who has just memorized how to use reduce for finding the maximum or minimum element in a list of numbers.

Re: How to Interview Engineers

#285

Post by rubidium »

macca321 wrote: post #283
pklausler wrote: post #73

The sad reality of programming interviews is that it's absolutely necessary to ask several near-trivial questions in order to flush out the candidates with awesome resumes and impressive degrees who simply have no idea how to analyze a simple problem and solve it using a computer. Lately, I've been asking "given the starting and ending times of two calendar appointments, determine whether or not they conflict." No lo…

The problem with interviews is that there is no time for false starts. When approaching a coding problem in real life, I pick a solution that seems to be right. Half the time I pick a good solution and half the time I've rushed in and picked the wrong one. If I have picked the wrong one, I know within 30 mins that it is a flawed approach, but have usually explored the problem sufficiently to pick a good solution. The…

But if you can't do the calendar question and realize within (lets be generous) 3 minutes that double nested loops are the wrong approach... I think it'd be fair to question your abilities.

Re: How to Interview Engineers

#286

Post by qb45 »

dvnguyen wrote: post #34
rsyring wrote: post #6

Earlier quoted context omitted.

I had a guy work for me that was very academic minded regarding programming. He had a hard time letting go of the "pure" way of doing things and taking a good/practical approach to just getting stuff done. It can definitely be, but won't always be, a detriment in my experience.

What you've described is someone who follow some practices religiously. I don't see any correlation between people like that and ones with academic background.

I'm afraid academia may produce religion. After all, it's a place where they show you a bunch of tricks, you practice them in simplified applications and then risk leaving with a belief that you actually understand shit.

A recent example: https://news.ycombinator.com/item?id=14267555

Re: How to Interview Engineers

#287

Post by coldcode »

pavlakoos wrote: post #248
jk563 wrote: post #238

Earlier quoted context omitted.

What type of questions do you mean?

Imagine a cottage with all 4 walls facing south. And there is a bear visiting it. What is the color of bear's fur?

Is that a real question? I too would refuse that in a programmer interview, unless it was joke. Of course the answer is white - polar bear and you are at the north pole. Even as a puzzle question it's pretty lame. Still puzzling over the boiling bagels on Mars one...

Re: How to Interview Engineers

#288

Post by crispyambulance »

losteric wrote: post #169
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…

This is why it's important to start the interview with culture/work history questions to probe how they're feeling, watching their body language, before moving on to simple questions of increasing complexity. I've literally started nervous people with "naively print the string 'hello'"... After warming up, the best one eventually completed my max-difficulty questions.

This is the way to go.

I would add that it takes significant experience and preparation to interview people effectively. This is a difficult-to-learn soft-skill that not everyone has.

Too often folks just get dragged into an interviewer situations with no planning or coordination.

Re: How to Interview Engineers

#289

Post by pogaxvr »

0xbear wrote: post #247
seangrogg wrote: post #228

Earlier quoted context omitted.

Let's be real, if a roofer was asked anything comparable to a programming question it would be to provide an accurate approximation of the total number of roofing contracts completed globally within the last half-minute on the back of a coffee-stained napkin.

But that's not what's being asked by OP. Their question is rather simple, and software engineer should be able to answer it on autopilot, without even engaging her brain. As a hiring manager I would end the interview right there and then after the failure to answer something like this.

As an interviewee, I would roll my eyes at the ignorance of the interviewer.

This is the sort of question that reveals the ignorance of the person asking it. The correct answer is "yes". What is 'modern'? There are very modern embedded CPUs that operate in the low MHz range. How much power is being provided? A 'modern' CPU can be underclocked to ridiculous levels for power savings. What's an operation? Are we talking MOV AX, 1 or are we talking hashing a string?

It's the kind of question a dumb person asks thinking they're being quite clever.

Re: How to Interview Engineers

#290

Post by saw-lau »

deathanatos wrote: post #167
pklausler wrote: post #73

The sad reality of programming interviews is that it's absolutely necessary to ask several near-trivial questions in order to flush out the candidates with awesome resumes and impressive degrees who simply have no idea how to analyze a simple problem and solve it using a computer. Lately, I've been asking "given the starting and ending times of two calendar appointments, determine whether or not they conflict." No lo…

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…

The whole for loop thing - absolutely!

We used to ask people to right a function in C that converts an array of doubles from degrees to radians. It was amazing how many people had no idea and who had sailed through CV/resume screening, telephone interview, and 'technical discussion' part of the interview with ease.

Post reply on HN