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

341–350 of 489 posts

Re: How to Interview Engineers

#341

Post by kudokatz »

vonmoltke wrote: post #298
pc86 wrote: post #277

Earlier quoted context omitted.

> By definition this approach is going to unfairly reject a number of candidates. This is only a problem if the interview/hiring/capitalism process is meant to be fair. > Imagine how it must feel to be an uneducated demographic in most other parts of the world The less privileged here certainly had jobs in HS and college where you just filled out an application, the manager made sure you weren't a convict or on drugs…

> This is only a problem if the interview/hiring/capitalism process is meant to be fair. It's also a problem when those same companies want to bitch and whine about a "talent shortage" or a lack of diverse candidates.

> It's also a problem when those same companies want to bitch and whine about a "talent shortage" or a lack of diverse candidates

so much this. Why do companies get to receive all sorts of incentives to hire when candidates they reject walk into other great tech firms, make bank, and generate boatloads of value?

Maybe some should just pay more, too. There are plenty of firms just being too cheap to hire great talent, including some large, well-known ones.

Re: How to Interview Engineers

#342

Post by drewmol »

zippergz wrote: post #111
bogomipz wrote: post #109

>"After an engineer passes our process, they go straight to the final interview at companies we work with (including Apple, Facebook, Dropbox and Stripe)." Can anyone from any of these companies confirm this? This strikes me as really odd. So only one employee from FB, Apple, Dropbox, and Stripe needs to interview a candidate that Tripplebyte say is a "Go"? I'm having a hard time believing that.

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.

Interesting, someone clarified below that it is indeed final round. I would take it to mean 'the final interview', singular, as written. Seems misleading.

Re: How to Interview Engineers

#343

Post by abramz »

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.

I don't put out fires under the watchful eye of a would be colleague or employer.

Re: How to Interview Engineers

#344

Post by s_kilk »

codingdave wrote: post #150
aldarn wrote: post #93

Earlier quoted context omitted.

This is close but you need to ensure the start time is before the other ends, and test for the second one starting before the first also. There's four cases: [appointment 1 start] [1 end] [appointment 2 start] [2 end] (case 1 - no overlap, appointment 1 first) [appointment 1 start] [appointment 2 start] [1 end] [2 end] (case 2 - overlap, appointment 1 first) [appointment 2 start] [appointment 1 start] [2 end] [1 end]…

Or just sort by start time, then do the simple check.

Yeah, this is way easy if the two events are sorted by start_time first.

Re: How to Interview Engineers

#345

Post by cookiecaper »

watwut wrote: post #218
cookiecaper wrote: post #137

Earlier quoted context omitted.

I don't think it's odd. The article says that 15% of Triplebyte's clients dislike it when things get too theoretical. Absent other signals, veering deep into theory on the assumption that interviewers generally like that is clearly the wrong idea. My experience is that most people are happy to leave school behind, and they invoke theoretical concerns only when they are applicable and relevant. People want to hear abo…

Guess I Am lucky that I meet good programmers who were not above theory and continually keep themselves informed. Contrary to what you write, there is no dichotomy between the two and your coding skills are not harmed by learning theory or keeping interest in it. I also think that if knowing something harms me in the eyes of the company, then I do not want to work there. Such environment must be demotivating for lear…

You're continuing to conflate knowing theory with focusing too much on theory in the interview process. I don't think anyone begrudges candidates for knowing theory. It's when their answers are primarily theoretical instead of primarily practical that the issue comes into play.

Re: How to Interview Engineers

#346

Post by nsxwolf »

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.

The stressful situations tend to be things like "We just broke the production database, we need to figure out how to recover the data ASAP"... not "We need a new algorithm in FIVE MINUTES!"

Re: How to Interview Engineers

#347

Post by nsxwolf »

kudokatz wrote: post #340
FilterSweep wrote: post #280

Earlier quoted context omitted.

This is far too much of a simplification of (grand)Parent. you don't know the circumstances that 30 year old programmer with a 2 year old child at home is facing. You could also be like certain firms and immediately nix him on the "merits" of ageism. A female programmer might have travelled 2000 miles to just receive an abstraction question out of left-field over an irrelevant concept to the job. She flew out on this…

> 30 year old programmer with a 2 year old child at home ... nix him on the "merits" of ageism A choice, conscious or not, to dedicate time to raising a child at the opportunity cost of myriad other ways to spend time is not related to ageism at all.

Most programming jobs do not actually demand one make this form of Sophie's Choice. Perhaps the Valley is so diseased, but it's not the only game in town.

Re: How to Interview Engineers

#348

Post by BeetleB »

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. Often, time matters and you have to think on your feet

Not once in my career had I had to fix a problem in an hour, let alone 10 minutes.

I have had senior people get mad at me when I couldn't give an answer during a meeting - that's the closest to an interview type scenario where you need the answer now. But even then, I did not stress that I'd lose my job, which is similar to the stress the candidate is facing.

Re: How to Interview Engineers

#349

Post by sqeaky »

abramz wrote: post #343
lopatin wrote: post #166

Earlier quoted context omitted.

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.

I don't put out fires under the watchful eye of a would be colleague or employer.

Some developers are expected to work on the systems that processes a bajillion dollars of whatever per day and when it screws up they are often on the line for it.

I am not saying it is right, I am just saying at some shitty places it is.

Re: How to Interview Engineers

#350

Post by alexashka »

dsacco wrote: post #299
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…

I used to disbelieve hiring managers regularly encountered candidates who actually couldn't code, or whatever other basic technical thing was reported on their resumes. Such a possibility - even the audacity of it on a conceptual level - simply seemed beyond the pale for me. I had interviewed before and not done well, and that I could absolutely understand. But I had no way of relating to the idea of someone entering…

Let me ask: what company do you work for and how much effort does it put into finding, attracting and most important! retaining! people who are any good?

How much say do the people working on a team have, in who gets hired? I mean people who'll actually be working with the person day to day, not some manager.

If the answer is 'we tell recruiting agencies we're hiring for vague role X, Y and Z', then why are you surprised?

Is the work any interesting? No? Generic corporate codebase perhaps? And you're getting generic people applying? How strange :)

ps. This is not directed at you in particular. I just find it strange when people don't do an inch beyond 'we pay money', and then expect a mile beyond 'i do just enough to get paid'

Post reply on HN