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

201–210 of 489 posts

Re: How to Interview Engineers

#201

Post by missblit »

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…

It's all fun and games until one of your appointmets is specified in rfc2550 format, and the meeting room is on a big ship crossing the international date line on the same day daylight savings time changes for the ship's country while a new timezone is voted into effect. Meanwhile the other meeting room is a videoconfrerence between the international space station and a ship travelling at close to the speed of light, but the real twist is the two meetings don't actually have anyone in common!

Re: How to Interview Engineers

#202

Post by paulie_a »

Honestly drop the question/answer aspect for technical checkouts. Offer a problem then work with them to solve it. The most important aspects are two fold, What questions do they ask, and now that you are being cooperative and a team mate, how do they interact with you.

EDIT: But during the entire process keep in mind they are hopefully interviewing your company. Far too many companies forget this aspect and the entire process has become lopsided in favor of companies making candidates jump through hoops.

Re: How to Interview Engineers

#203

Post by watwut »

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…

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.

Re: How to Interview Engineers

#204

Post by bogomipz »

ryandrake wrote: post #198
bogomipz wrote: post #179

Earlier quoted context omitted.

>"Assuming you don’t pass 100% of on site interviews or you don’t take the first offer immediately, triplebyte will save you some amount of time." How exactly do they save me time? Can you elaborate? >"Beyond the force multiplier for pre-onsite interviews, they also can predict which companies you will have a higher success rate with for your on site." What is the "force multiplier" here? Again this is a job where yo…

Let me try to answer: Say you plan to interview at Apple, Facebook, Dropbox, and Stripe. Lets say each company requires 2 rounds of interviews. Without these guys, you're doing two rounds at each company = 8 interviews. With these guys, you do one round with them, and one round with each of the companies = 5 interviews. If that's how Triplebyte works, it would be a huge time saver.

Does every engineer unquestionably want to work for any and all 4 of those companies? Aren't these very different companies? Is there any significant commonality here other than Tripplebyte has some connection at all of these?

Re: How to Interview Engineers

#205

Post by watwut »

lomereiter wrote: post #187
rasen58 wrote: post #181

Earlier quoted context omitted.

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…

They might not care, but in that case this question essentially tests if a person understands what 'GHz' means and can think logically, which is not that much to ask.

Why would web programmer think about processors and GHz is beyond me. There are jobs where it might matter, but for most of them it is completely irrelevant.

Re: How to Interview Engineers

#206

Post by std_throwaway »

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…

If one meeting ends at t1 and the other meeting starts at t1, do they conflict?

To which meeting does t1 belong? One, both, neither? Can we set up an event at t1 which is not in conflict of either? How about two events at t1?

Re: How to Interview Engineers

#207

Post by watwut »

mikebenfield wrote: post #189
symlinkk wrote: post #180

Earlier quoted context omitted.

When the hell would you ever need to know that? Do you ask carpenters how many times their screwdrivers spin per minute? It just seems like useless trivia.

Whether this is a good interview question I don't know, but: > When the hell would you ever need to know that? I find this such a strange perspective. You're writing code for a computer. Sometimes you need to estimate how quickly it should run, or else estimate how quickly it could run with optimal code. Surely it's obvious that knowing how fast your computer does stuff, at least within 3 orders of magnitude , is a n…

Unless you are writing assembler, speed of your code is very distant of instructions. You don't count instructions when estimating speed. Not in higher level languages, not when working with database and definitely not in something like javascript that runs in browser.

Re: How to Interview Engineers

#208

Post by bookmarkacc »

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?

It would be reasonable to ask tree related questions. If the questions falls within a normal use case. Traversing a filesystem is something you should be familiar with. Reversing a binary tree. No

Re: How to Interview Engineers

#209

Post by std_throwaway »

missblit wrote: post #201
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…

It's all fun and games until one of your appointmets is specified in rfc2550 format, and the meeting room is on a big ship crossing the international date line on the same day daylight savings time changes for the ship's country while a new timezone is voted into effect. Meanwhile the other meeting room is a videoconfrerence between the international space station and a ship travelling at close to the speed of light,…

Also keep in mind Heisenberg while traveling along state lines.

Re: How to Interview Engineers

#210

Post by Bahamut »

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.

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 onsite interviews with them, and I hardly have studied specifically for technical interviews. I possess an MS in mathematics.

Don't presume anything about an individual just because the person happened to not answer a particular question - the person could be actually much smarter than you. It could have just been a bad day, or a number of factors.

Post reply on HN