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

191–200 of 489 posts

Re: How to Interview Engineers

#191

Post by null0pointer »

0xffff2 wrote: post #134

As someone with an actual accredited engineering degree, I find it bizarre that Silicon Valley has decided that the term "engineer" doesn't even need to be qualified anymore. Even without getting into the flame war over whether "software engineers" are real engineers or not, there's a very large pool of engineers to which this post doesn't apply at all. I can't be the only one in the latter pool that reads HN, can I?

I used to be reluctant to call myself an engineer. I don't actually get to do too much engineering in my work. But I've seen too many less qualified people calling themselves engineers so I might as well... Besides, my degree is from the Engineering faculty at my university rather than Science where the CS/SE degrees are. At least that's how I justify it to myself.

Re: How to Interview Engineers

#192

Post by jkaptur »

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?

Re: How to Interview Engineers

#193

Post by trishume »

deathanatos wrote: post #170
DonaldFisk wrote: post #160

Earlier quoted context omitted.

(Singly linked) lists have many advantages (e.g. useful operations on them are side-effect free), but whether they should be used depends upon which problems you solve and which languages you use. It's unsurprising they're used all the time in Lisp, and functional programming languages generally. I'd advise against their use in C or other languages without garbage collectors. They're rarely needed in languages (such…

What language would you recommend using a singly-linked list in, aside from Lisp? Why is it any less valid in non-GC'd languages? (Aside from memory management in C is fraught with error, but that's a problem not unique to singly-linked lists.) I've never looked (at least, that hard) at the language; it was always a question of "is this the appropriate data structure for this task?". Linked-lists have somewhat peculi…

Linked lists make way more sense in languages with bump-pointer allocating garbage collectors specifically. In those languages (e.g Haskell, OCaml, Java) allocation is really cheap and they preserve locality so allocating all the links isn't as much of a penalty.

Also if you don't have a garbage collector you have to do reference counting, and if you want parallelism your reference counting has to be atomic, which when you're sharing a lot of linked list nodes, is another large penalty.

Re: How to Interview Engineers

#194

Post by fghvbnvbnfe »

adrianratnapala wrote: post #186
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.

Well does it take about a second or about an hour to make one turn of the screw? If a carpenter doesn't know the answer to that in his bones, he won't be fastening many things together.

It takes significantly less than a second to turn a screw once. A couple orders of magnitude less actually, to give it some relation to the computer question.

Which really just demonstrates the point, I think. At some point things are "fast enough" that it just doesn't matter. We've reached that point with computers. Unless you are working in a niche field that needs serious compute, the sources of performance problems are almost never going to arise from issues like trying to execute too many add instructions in a given period. The delays will come from things that are significantly harder to see - network, database, or program architecture + runtime.

Re: How to Interview Engineers

#195

Post by aldarn »

mpetrovich wrote: post #147

We've had success with take-home coding challenges. After 1-2 technical phone screens, we send applicants a coding challenge for which they have 48 hours to complete. The coding challenge is representative of some of the work we do (e.g. Given our API, create a D3 visualization of X) and should take applicants several hours to complete. In submissions we look at everything from overall program structure and approach…

Do you specifically hire D3 developers? This sounds like a pretty difficult "coding challenge" for a non-D3 guy, let alone someone who may not even primarily use javascript. Having used D3 sparingly before i've found it something that requires a fair amount of upfront domain knowledge to get much done beyond something extremely simple (unless of course you copy an existing example, which is what I always did). This seems unreasonably difficult for someone with no prior knowledge to accomplish in a 48 hour window whilst working etc -- you may find you are inadvertently optimizing your interview process for the unemployed with this kind of time limit / coding investment.

Re: How to Interview Engineers

#196

Post by fghvbnvbnfe »

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…

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 fast the program will run.

Re: How to Interview Engineers

#197

Post by cyrux004 »

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…

Can you expand on the boiling bagels on mars question ? Havent heard of that before

Re: How to Interview Engineers

#198

Post by ryandrake »

bogomipz wrote: post #179
itsdrewmiller wrote: post #164

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. 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. It’s not a guaranteed slam dunk for every single person (and you still have to pass their process) but I think the value pro…

>"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.

Re: How to Interview Engineers

#199

Post by Stratoscope »

FT_intern wrote: post #185
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 most logical and clear answer for me (assuming I didn't already screw up by making assumptions about the data format, problem definition, etc.) is: 1. Figure out which appointment starts first 2. Check if first_appointment.end > second_appointment.start So: boolean AreAppointmentsConflicting(int start1, int start2, int end1, int end2) { // first and second refer to the start time of the appointments. // The first…

Personally I find the first version a bit hard to follow, and the second one makes my head spin.

But I can understand the objection to the third version too. I don't think the problem is that the expression is too simple - simplicity is generally a good thing! - but that it's easier to reason about non-conflicting times instead of conflicting times:

If my other meeting ends by the time this one starts, we're good.

Or if this meeting ends by the time the other one starts, we're good.

Otherwise we have a conflict.

So now if you like the step-by-step approach, we can write a function that seems pretty straightforward and easy to understand:

  boolean AreTimesCompatible( TimeRange thisRange, TimeRange thatRange ) {
      if( thatRange.end
I think it reads fine as a single expression too, given an appropriate comment explaining the idea (which you'd want anyway):

  // Time ranges are compatible if that one ends by the time this one
  // starts, or if this one ends by the time that one starts.
  // Otherwise they overlap.
  boolean AreTimesCompatible( TimeRange thisRange, TimeRange thatRange ) {
      return
          thatRange.end
And here is the matching function to go with either of those:

  boolean AreTimesConflicting( TimeRange thisRange, TimeRange thatRange ) {
      return ! AreTimesCompatible( thisRange, thatRange );
  }

Re: How to Interview Engineers

#200

Post by Jemaclus »

IMO, hiring is like a funnel. At the top of the funnel is the entire universe of people. At the bottom of the funnel is your hire. The goal is to filter out as many people as possible as quickly as possible. One key point is whether or not they can write code.

Keep in mind writing code is the BARE MINIMUM required for a job. If they can't do that, they shouldn't be on-site in the first place. If you have your candidate taking a day off work and taking a day worth of engineering talent off engineering-related tasks, and you're spending that time asking them to write code, you've failed to apply the filter higher up in the funnel.

Ideally, you verify their coding ability BEFORE you bring them into the office, whether via a tech phone call, live-coding session, or take-home assignment. Before the haters start saying "but they can fake it!", hold your horses. Once you've established that the candidate can code, when you bring them on-site, you quickly VERIFY your previous conclusions. You quickly VERIFY that the coding assignment you gave them was completed by them. This should take no more than 15-20 minutes. Maybe you just have them walk through a chunk of code. Maybe you ask them to recreate their answer. Something. Anything.

But if you send in three different engineers, and they all spend the entire hour asking the candidate to solve programming tasks, you're literally evaluating the BARE MINIMUM of the hiring requirements. And there's so, so, so much more to being a good engineer than writing code.

Outside of a QUICK verification, your on-site questions, imo, should NOT be writing code (or even pseudo-code). They should be about previous projects, architecture, personality, professionalism, punctuality, communication, teamwork, autonomy, and collaboration skills -- all the non-tangibles that answer the basic question of "Do I want to sit next to this person for the next 6-12 months?"

If your idea of a good interview is to ask someone to generate a calendar between two dates or sort a list or find the minimum integer in a list, you're completely, totally missing the point. You're evaluating the bare minimum to get them in the door -- and if you're doing that in-person, you're wasting your time. You should have filtered that out before they walked in the door.

Remember, these candidates are often lying to their bosses and calling in sick or using up valuable PTO to take an entire day off work to come sit in your office. Don't waste their time with redundant tests and things that you could have figured out before they walked in the door.

(And dear god, some of the questions in these comments are... awful... at evaluating anything except, I dunno, getting the right answer. Yikes.)

Post reply on HN