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

481–489 of 489 posts

Re: How to Interview Engineers

#481

Post by chrisbennet »

drdeadringer wrote: post #475
alexashka wrote: post #412

Earlier quoted context omitted.

I can think of half a dozen ways to attract applicants in a way that'd significantly increase the quality of the applicants while at the same time significantly decreasing the number of the applicants. See, you are assuming a basic process of a job board and anyone applying for the position. I am saying you are so entrenched in mediocrity that you can't fathom there are much better ways. I will say this though - they…

> I can think of half a dozen ways to attract applicants in a way that'd significantly increase the quality of the applicants while at the same time significantly decreasing the number of the applicants. Like what?

He would have but they were too large to fit in the margin...

Re: How to Interview Engineers

#482

Post by 0xbear »

pogaxvr wrote: post #480
0xbear wrote: post #383

Earlier quoted context omitted.

The worst thing you realistically can do to stall your CPU is miss cache every time you read data from RAM. If you do this for every instruction (which would be quite a feat in itself), you divide your instruction throughput by about 200. But even then, and even on the shittiest modern CPU you'll be retiring millions of instructions per second.

The MSP430, released in 2010, can be clocked down to 32kHz. That's pretty much the state of the art in modern, low-power devices.

And if you know that, I'm pretty sure you'd pass that interview.

Re: How to Interview Engineers

#483

Post by 4ydx »

marcuslager wrote: post #454
poikniok wrote: post #370

Earlier quoted context omitted.

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.

This problem is solved with a couple of simple if statements. Finding a "solution" that is more complex than necessary or introduces knowledge that really isn't needed is the sign of a programmer who... over-engineers and is likely to be a detriment.

Re: How to Interview Engineers

#484

Post by lostmsu »

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…

Bad idea.

I have not interviewed many people yet, but already during one lunch (!) interview (where I don't ask any questions), a guy was so proudly talking about his achievements at his previous job in quite generic terms, that I've got an impression he was teached the whole story, rather than actually lived it.

Later he was not hired. According to (trusted) others in the interview loop he did not know how to do any basic shit.

Re: How to Interview Engineers

#485

Post by colordrops »

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.

> Being a professional programmer is not an entirely stress-free job.

understatement of the year.

Re: How to Interview Engineers

#486

Post by nwjtkjn »

bryanrasmussen wrote: post #470
nwjtkjn wrote: post #145

Earlier quoted context omitted.

Sounds like an effective filter to me. Where I work, this would be the first part of one of the interviews, with the second part being something more like "Given a list of calendar appointments, what is the maximum number which can be attended without conflicts?"

don't you need a little bit more info about that list of calendar appointments? like at least an assumed time length? (assuming the list happens on the same day)?

Yeah I was thinking each appointment had a start time and end time.

Re: How to Interview Engineers

#487

Post by Clubber »

lostmsu wrote: post #484
Clubber wrote: post #444

Earlier quoted context omitted.

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…

Bad idea. I have not interviewed many people yet, but already during one lunch (!) interview (where I don't ask any questions), a guy was so proudly talking about his achievements at his previous job in quite generic terms, that I've got an impression he was teached the whole story, rather than actually lived it. Later he was not hired. According to (trusted) others in the interview loop he did not know how to do any…

But you could tell something was fishy by listening to him. You said you got the impression he taught the whole story rather than lived it. That's exactly what you are looking for; that's why it's so valuable. A real developer can tell when someone is bullshitting him in about 3 sentences.

Having said that, let me be clear. This isn't a good tool if all you have to do interviews is a manager. They probably won't be able to tell the difference, especially if they are just generic managers with little to no technical experience. They aren't the type you want giving technical interviews.

Re: How to Interview Engineers

#488

Post by trishume »

deathanatos wrote: post #445
trishume wrote: post #193

Earlier quoted context omitted.

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

> 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. Such allocation is possible in languages such as C++/Rust/C as well. (Though to how much the standard library in each supports you may vary.) My point was…

Yah I know normal linked lists are totally possible in all languages. I should have specified I was talking about the use case of sharing data through immutable singly-linked lists.

In these languages you use them specifically because you can prepend without worrying about other things still holding a reference, even in other threads. In Rust you'd need Arc to do that.

Also yes you can use custom allocators in Rust/C++, but then you have to have everything have the same lifetime. With GC'd functional languages you don't because the GC will move them to the old generation if necessary.

I'm mainly talking about the empirical question of why Lisp/Haskell/OCaml use linked lists so much, but in other languages they're rare (e.g I see/use them less than heaps). In most cases where you want fast prepend you just append to a vector and just treat it as reversed or reverse it after.

Re: How to Interview Engineers

#489

Post by Zephyr314 »

theflork wrote: post #474
Zephyr314 wrote: post #116

Earlier quoted context omitted.

This interpretation is correct; they skip to onsite, but get a full onsite. (Source: we interview triplebyte candidates regularly)

how is the quality of the candidates coming thru the triplebyte pipeline compared to recruiters, or direct site applications? I'm considering using triplebyte, but also want to control where my applications are sent to.

They are of similar quality to candidates that get through our normal screening process (direct applications). It is best to be very specific about what types of candidates you are looking for so they can match as well as possible. We're happy with them in general.
Post reply on HN