How to Interview Engineers • Hacker News Board

Re: How to Interview Engineers

#451

Post by Steeeve » Wed, Jun 28, 2017, 7:02 AM UTC

roguecoder wrote: post #429

Steeeve wrote: post #420

Earlier quoted context omitted.

> Please keep in mind that resumes nor any other data from the candidate can be trusted That's not a problem that is unique to software, yet nobody asks directors to prove their budget forecasting skills during an interview, or has their tech writers go through the process of building automated indexes or varied pagination. If you suspect someone can't write fizzbuzz, send them packing. Don't waste their time or your…

Tech writers are certainly asked to create technical documents to demonstrate their skills. Chefs might be a good model too; it absolutely the case that before hiring a chef they have to plan a menu and cook. We aren't business people: we do actual productive things.

> Tech writers are certainly asked to create technical documents to demonstrate their skills.

In an interview? Not that I've ever seen. Reviewing a portfolio is not what we're talking about.

> Chefs might be a good model too; it absolutely the case that before hiring a chef they have to plan a menu and cook.

If a chef is expected to plan a menu and cook as part of their interview process, they are going after a very high end job. They know the kind of food that the restaurant serves. They are provided with the tools, equipment, and ample prep time to properly consider their course of action. And let's not pretend that every chef has to go through a live cooking trial for every job, or that most high end chef's would not throw a hissy-fit and walk out the door if you assumed that they would show up to an interview ready to plan a menu and cook a meal.

--- "what? You've never heard of fizzbuzz? It's a simple game that..." cue a terrible explanation of the game missing key requirements that the interviewer expects the interviewee to just know.

So now the developer not only has to come up with a set of code under pressure, they have to do so with a set of unclear requirements. And what the heck, why not take away their daily development environment to ensure that they are more uncomfortable and let's have them do it on a whiteboard so they have no hope of resolving simple syntax errors that arise because this particular developer floats between four different languages at his current job.

What you see as a game to weed out a littany of liars and cheats is seen entirely differently from a job-seekers perspective. "I have 15 years experience building complex systems and this jackass wants me to write kiddie code on a whiteboard to prove what, exactly?"

I'd rather not work for somebody who operated off of the assumption that I was a liar and a cheat upon our first meeting. The only reason people subject themselves to this kind of treatment is because they _need_ a paycheck.

Re: How to Interview Engineers

#452

Post by btschaegg » Wed, Jun 28, 2017, 7:06 AM UTC

baddox wrote: post #159

et-al wrote: post #149

Earlier quoted context omitted.

> not fully thinking it through What I like about pklausler's example is that it allows for people to find edge cases without too much technical knowledge. If I have a candidate who doesn't ask about the inputs (e.g. "are the appointment sorted?"), I'd be wary. Engineers are often given vague specifications they need to clarify or account for.

I highly doubt I would ask if the inputs are sorted. I wouldn't expect them to be (why would they be, after all?), and I'd probably just give a solution that works regardless.

I agree. Also, since we're talking about two entries here, there really isn't much work to do...

One could even argue that relying on the order of the items in this case is going to result in a worse design overall (it's one additional thing the caller can get wrong).

Re: How to Interview Engineers

#453

Post by Scea91 » Wed, Jun 28, 2017, 7:51 AM UTC

Clubber wrote: post #444

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 agree. Most companies screw themselves with the technical interview by giving it. I give something simple like FizzBuzz and that's it. My big questions is: "What was one of your favorite projects and what did you do?" That will tell you everything I need to know. The problem with giving technical interviews is you are testing for someone who is an extrovert that can bullshit under pressure. That's not what you want…

I think you have it the other way round.

Asking about favorite projects is easier for extroverts that can bullshit under pressure than technical interviews.

Re: How to Interview Engineers

#454

Post by marcuslager » Wed, Jun 28, 2017, 7:58 AM UTC

poikniok wrote: post #370

marcuslager wrote: post #270

Earlier quoted context omitted.

To have a good chat I would hope they drew a coordinate system, mapped both appointments in Euclidian space, and then did an intersect between vector A (first appointment) and vector B (second appointment) to see if there are any data points in common.

What does this mean?

For a good discussion, instead of looking at the problem strictly programmatically, you could look at it as something you could map in vector space.

The dimensions of appointments are [startTime, endTime, location]. If you have points in one appointment that intersect with other appointments, then you have a collision.

Re: How to Interview Engineers

#455

Post by kulu2002 » Wed, Jun 28, 2017, 8:05 AM UTC

gilbetron wrote: post #168

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…

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…

Well...this questions seems to be OK for phone interview for entry level programmers who should know MIPS, CISC/ RISC architecture basics. I would ask such questions to fresh graduate who is supposed to be working on firmware level stuff like writing custom co-operative multitasking schedulers, OS routines, device drivers etc. Probably this type of question is not suitable for a web developers or Data analyst/ scientist

Re: How to Interview Engineers

#456

Post by fnord123 » Wed, Jun 28, 2017, 8:13 AM UTC

sqeaky wrote: post #403

fnord123 wrote: post #246

Earlier quoted context omitted.

>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 fr…

>Very few candidates are Diego Forlan

How would one know? Usually we know a friend who works somewhere and they say the company is shit. Or you work somewhere and someone doesn't work so you end up thinking they're shit. It's not often that you have both sides of the story.

>very few wrote books,

Books might indicate a good communicator and independent ability to complete a task but it's not an indication that someone is a good team member that fulfills a particular role.

>verfy few created a foundational open source project, etc...

I contend that this actually risks being a Balotelli. Good in the right atmosphere, but very independent and often stroppy when they don't get their way. They can be terrific in their element but often they're not good enough to build a team around.

Re: How to Interview Engineers

#457

Post by kulu2002 » Wed, Jun 28, 2017, 8:14 AM UTC

notadoc wrote: post #157

My own 2 cents for interviewing, for engineers and most other vaguely technical positions but perhaps broadly applicable: - Don't ask them to whiteboard, especially don't ask them to whiteboard some absurdity - Don't put a panel of 5-10 people against a single candidate, but if you must absolutely (why?) do not do it on the first interview - Don't ask time-wasting stupid questions about manhole covers, boiling bagels…

I usually ask candidates to draw and explain the system block diagram of project/ module they have worked on, on whiteboard or paper!

Re: How to Interview Engineers

#458

Post by BoiledCabbage » Wed, Jun 28, 2017, 8:25 AM UTC

gilbetron wrote: post #432

cr0sh wrote: post #417

Earlier quoted context omitted.

> Carpentry is far different than programming. But even so, and equivalent question I would ask a carpenter I wanted to hire would be, "How much hardwood flooring would I need to cover the rooms in my house?" If they answer, "I dunno" and then stare at me blankly, I'm certainly not going to hire them. It would only be valid not to hire them if they have already taken measurements and noted them down. If they can't do…

And because of that the kinds of answer we would expect from such a carpenter in that situation is, "Hmm ... how big is the room and what size of board are you using? 2 inch, 3 inch, 5 inch, or so mix? That's pretty popular these days. How much extra do you want - I usually recommend 15% so you have some in case you need to repair." Likewise, for the original question, I'd expect some sort of discussion or nuanced an…

> Likewise, for the original question, I'd expect some sort of discussion or nuanced answer. Something like, "Well, most modern CPUs are rated at the GHz, so on the basic level, we can say on the order of billions of operations - but we're getting a lot more cores, and given SIMD and such, you could actually go an order of magnitude or two over that, in theory. But if you are doing something that takes lots of clock cycles, it could drop down into 100s of millions, I suppose."

And again, none of that knowledge is relevant or required to be very competent at web development.

The equivalent question to a web developer would be how many lines of code would it take to make a bare bones site with a calculator in it? 1,000? 10,000?, 100,000? Options A and possibly B (with explanation would be acceptable).

Your question (although you don't seem to feel this way) is the equivalent of asking a carpenter: How many Watts of power will you consume while finishing this room? A carpenter who knows that may show lots of curiosity about their tools, but there are also plenty of skilled carpenters who don't know the answer to that.

Your interview question is more asking "How similar is this person to how I approach things?" than "How skilled is this person at doing their job?"

Re: How to Interview Engineers

#459

Post by [deleted] » Wed, Jun 28, 2017, 8:57 AM UTC

marcuslager wrote: post #270

venture_lol wrote: post #104

Earlier quoted context omitted.

If the candidate starts by drawing 2 lines, then marking start and end on the lines, you know you would be off to having a good chat

To have a good chat I would hope they drew a coordinate system, mapped both appointments in Euclidian space, and then did an intersect between vector A (first appointment) and vector B (second appointment) to see if there are any data points in common.

[deleted]

Re: How to Interview Engineers

#460

Post by fghvbnvbnfe » Wed, Jun 28, 2017, 9:35 AM UTC

patrec wrote: post #214

fghvbnvbnfe wrote: post #196

Earlier quoted context omitted.

I agree that it is "useless trivia." The reason is that things today are "fast enough." These days most slowdowns aren't the result of the CPU not executing instructions fast enough. Other factors dominate, such as memory access patterns, network delays, and interfacing with other complex software such as databases. Unless you are doing compute-heavy code, the speed of the CPU isn't much of a factor in estimating how…

I'm not infrequently surprised how people don't spot that something is orders of magnitude slower than it should be or pick the wrong architecture because they can't or won't do simple mental math to work out very roughly how long it should take to move some data around in memory, ssd or over the network or perform some simple computation on it. I'm having trouble believing that people who think a CPU can do thousand…

I don't think there's much predictive power there. The people who are answering thousands clearly just haven't though about it before and are on the spot. Humans are just terrible with big numbers, and thousands sounds like a lot already.

You may as well ask any other sort of technical trivia question and figure the people that happen to carry around more random facts about tech are more likely to understand the bigger things that do matter. It isn't necessarily wrong it's a pretty obtuse way to make a judgment. Why not just ask them about the memory hierarchy or network delays or whatever directly?