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

471–480 of 489 posts

Re: How to Interview Engineers

#471

Post by sqeaky »

Steeeve wrote: post #420
sqeaky wrote: post #384

Earlier quoted context omitted.

You say we need to figure a few basic things out, how do we do if a person has basic confidence if not by asking them questions. Please keep in mind that resumes nor any other data from the candidate can be trusted, because a huge amount of candidates lie or are mistaken about their own skill. I once interviewed a candidate who claimed to have 10 years of SQL experience but couldn't write a query on the order of "sel…

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

Perhaps budget forecasting is more difficult to check in an objective way. It seems silly to compare that to easily checked skills like technical writing or software development.

After my experience interviewing it seems reasonable to expect that no one can write fizzbuzz and the only way to know otherwise is to have them write it.

Why are you so opposed to the idea of meritocratic interviewing? Why not check a few things that can be easily and objectively checked? Have you ever interviewed people?

Re: How to Interview Engineers

#472

Post by sqeaky »

Steeeve wrote: post #451
roguecoder wrote: post #429

Earlier quoted context omitted.

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…

I didn't say that any given person was a liar or cheat. It seems clear to me that some significant fraction of the interviewing population is and I cannot tell the difference just by looking at you. So I must do something to weed out the liars and cheats from you.

I prefer to do something objectively testable and easy enough that most programmers worth hiring should excel at it. I also do what I can to reduce stress, I explain that I am human and make mistakes too. I explain that would prefer a two way dialog to a battery of questions. I also try to explain that I think requirements always have some vagueness and sometimes need clarification.

I am curious why I should be lenient on someone unable to seek clarification on requirements? Would you want want to work with someone who couldn't seek help on requirements? I have seen that person and at the beginning of my career I was briefly that person, it is not productive and can a sink project if that person is trusted too much.

Re: How to Interview Engineers

#473

Post by rmah »

pmiller2 wrote: post #380
rmah wrote: post #317

Earlier quoted context omitted.

I once had to diagnose and fix a bug in a financial system that went belly up under extremely heavy load -- causing the company lose tens millions of $'s per hour (literally). Turned out to be a timing problem caused by satellite comms latency. The solution required us to modify how a couple different algorithmic worked. That situation was highly time sensitive and over-the-top stressful (for me anyway).

I'm sure you would acknowledge that's a very exceptional situation, right? That's the point of this whole subthread: that this kind of stress is exceptional in a work situation.

I would agree that it was exceptional. But I would also argue that how your people perform during exceptional situations is what makes or breaks teams and companies.

Re: How to Interview Engineers

#474

Post by theflork »

Zephyr314 wrote: post #116
zippergz wrote: post #111

Earlier quoted context omitted.

I don't think "the final interview" means a single person. I took it to mean the onsite round, with however many people that entails, skipping the recruiter screen, phone screen, etc.

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.

Re: How to Interview Engineers

#475

Post by drdeadringer »

alexashka wrote: post #412
Ntrails wrote: post #363

Earlier quoted context omitted.

Attracting more good people won't reduce the number of bad applicants (it will increase it). Retaining staff doesn't mean that you aren't hiring at .2 headcount per annum. Assuming that there's a basic process of CV review (by team members who would work with) followed by non technical phone interview. You will still have people who fail fizzbuzz. I'm not talking about small errors reading the problem - but the inabi…

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?

Re: How to Interview Engineers

#476

Post by sqeaky »

fnord123 wrote: post #456
sqeaky wrote: post #403

Earlier quoted context omitted.

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

I would argue I know because I have done many interviews, not nearly as many as the author of the article. Most interviewer candidate are about as qualified as a stuffed animal, except I would allow a stuffed animal in the office because they tend not to break things.

I agree with you that on your points about books and project founding, but I would hear a candidate out and not make hard unchangeable presumptions.

As for how do I "know" I can't know, I am only in the interview for an hour or two. The best I can do is get a sense. If the candidate nails fizzbuzz, explain the nuances of git v mercurial for 20 minutes and provides a plausible explanation for his previous place of employments toxicity then that affects my decision making one way. If it feel as though their reasons are thinly veiled excuses, they don't know foundational tools or fail at fizzbuzz... well I don't let interviews proceed to where people fail all three when they start with some minor points against them. Too many red flags and I call it done.

Re: How to Interview Engineers

#477

Post by kafkaesq »

rmah wrote: post #473
pmiller2 wrote: post #380

Earlier quoted context omitted.

I'm sure you would acknowledge that's a very exceptional situation, right? That's the point of this whole subthread: that this kind of stress is exceptional in a work situation.

I would agree that it was exceptional. But I would also argue that how your people perform during exceptional situations is what makes or breaks teams and companies.

No one doubts that performing under pressure is important.

It's the idea that this kind of pressure can in any meaningful way be simulated (and the candidate's response adequately gauged) using the shticks and routines that people try to do in the current standard interview process that people take issue with.

Re: How to Interview Engineers

#478

Post by pogaxvr »

gilbetron wrote: post #339
pogaxvr wrote: post #289

Earlier quoted context omitted.

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…

And you are one of the types of person the question is meant to weed out - people so threatened by a simple question they get defensive and hostile. And thanks for calling me dumb!

Thanks for projecting 'threatened' onto me!

You're the type of interviewer I would weed out, so by all means keep asking the question.

Re: How to Interview Engineers

#479

Post by Steeeve »

sqeaky wrote: post #472
Steeeve wrote: post #451

Earlier quoted context omitted.

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

I didn't say that any given person was a liar or cheat. It seems clear to me that some significant fraction of the interviewing population is and I cannot tell the difference just by looking at you. So I must do something to weed out the liars and cheats from you. I prefer to do something objectively testable and easy enough that most programmers worth hiring should excel at it. I also do what I can to reduce stress,…

You know... I re-read my post early this morning and I thought... "that was way more hostile than necessary". But it was too late to edit. Sorry about that.

I think digging my heels in further at this point is making my opinion appear stronger than it is.

Re: How to Interview Engineers

#480

Post by pogaxvr »

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

Earlier quoted context omitted.

Clock rate != operations. It's like you didn't bother to read what I wrote.

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.
Post reply on HN