Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Technical Interview Rift

blog.techmasters.chat

Post reply on HN
Print view View original

11–20 of 97 posts

Re: The Technical Interview Rift

#11

Post by cbanek »

psyc wrote: post #4
cbanek wrote: post #3

Earlier quoted context omitted.

On the other hand, would you really accept an offer without having at least met the people you'd have to work with? Especially if you have to move across the country?

Video chat is good enough for me. I don't need to know about their posture or how long their legs are.

This might just be me, but video chat doesn't really do it. You don't get an idea of the building, bathrooms, cafeteria, and the general idea of how often your coworkers bathe.

All of these can be pretty important to my general mental health.

Re: The Technical Interview Rift

#12

Post by jghn »

kafkaesq wrote: post #10

Some useful advice, but something about the overall tone seems a bit off: You are a manager and it’s time to hire a new developer to join your impressive team of A+ players. That's where things started to go of course. You're not an "A+ player", and most of your team aren't "A+ players" either. You're just human beings doing the best you can and (hopefully) trying to improve a bit each day -- like anybody else. No on…

When I see job postings or recruiter messages talking about how they only hire The Best I immediately tune out. At best they'll be extremely misguided and delusional. At worst they'll be massive Dbags

Re: The Technical Interview Rift

#13

Post by nilkn »

blantonl wrote: post #6

I view technical interviews that require algorithm solving and coding on a whiteboard as ridiculous. Primarily, because I am deathly afraid of them. And here is why. I own and operate two online businesses in the Radio Communications space that are the de-facto standards for our industry. I've coded both of them from the ground up in PHP/MySQL and manage all the day to day administration of these sites. Our infrastru…

It sounds to me like you're more of a technically inclined software executive/business person than a coder. Would you agree or disagree with that statement? Your run-of-the-mill programmer isn't going to be writing any contracts or license agreements and they're certainly not going to be managing any financials.

If the interviews consist entirely of whiteboard problems, then they're probably just planning on sticking you onto an agile team where you'll grab tickets off a queue every morning and churn through them at your own pace. It sounds to me like this is quite a bit different from what you've actually been doing. So I guess the point I'm trying to drive at here is that maybe your mistake is identifying yourself as just a software developer when you're actually an executive?

Re: The Technical Interview Rift

#14

Post by lisper »

I think Triplebyte has the right idea: essentially a take-home test conducted over a period of a couple of days. It allows a candidate to show off what they can do under realistic conditions, instead of allowing an interviewer to poke at what they can't do under highly unrealistic high-pressure conditions. A typical tech interview is more like a spelling bee than a realistic test of a candidate's abilities: if you happen to get a word/question you know, you look awesome. If you don't, you don't. (Not long ago I screwed up a tech interview because I couldn't remember/figure-out-on-the-spot the iteration condition for estimating square roots by the Newton-Raphson method, and I was not willing to cheat by looking it up on Wikipedia while I was on the phone. Their loss.)

I just wish Triplebyte would expand their outreach beyond YC companies.

Re: The Technical Interview Rift

#15

Post by xenihn »

nilkn wrote: post #13
blantonl wrote: post #6

I view technical interviews that require algorithm solving and coding on a whiteboard as ridiculous. Primarily, because I am deathly afraid of them. And here is why. I own and operate two online businesses in the Radio Communications space that are the de-facto standards for our industry. I've coded both of them from the ground up in PHP/MySQL and manage all the day to day administration of these sites. Our infrastru…

It sounds to me like you're more of a technically inclined software executive/business person than a coder. Would you agree or disagree with that statement? Your run-of-the-mill programmer isn't going to be writing any contracts or license agreements and they're certainly not going to be managing any financials. If the interviews consist entirely of whiteboard problems, then they're probably just planning on sticking…

If you're trying to say that he should be seeking a CTO position instead of a developer/engineer position, then I agree.

Re: The Technical Interview Rift

#16

Post by kafkaesq »

lisper wrote: post #14

I think Triplebyte has the right idea: essentially a take-home test conducted over a period of a couple of days. It allows a candidate to show off what they can do under realistic conditions, instead of allowing an interviewer to poke at what they can't do under highly unrealistic high-pressure conditions. A typical tech interview is more like a spelling bee than a realistic test of a candidate's abilities: if you ha…

Not long ago I screwed up a tech interview because I couldn't remember/figure-out-on-the-spot the iteration condition for estimating square roots by the Newton-Raphson method

(1) Better to say you were unable to "remember", rather than a "figure out". No one ever "figures out" things like the Newton-Raphson method over the phone -- not even people like Isaac Newton or Joseph Raphson (substituting whatever comparable level of distraction on had to contend with in those days, absent telephones -- "while ordering a beer at the pub", I guess).

(2) The use of this question as a binary hiring filter (mindlessly copy-and-pasted from their rough impression of what ever other company is doing in 2016) was a failure on their side, not yours.

Re: The Technical Interview Rift

#17

Post by luhn »

jakewins wrote: post #8

> These are ways to gauge if they know the langue without making them write code. You should never ask a developer to write anything from scratch, or write anything. But.. why ? You are hiring someone to write code, what better way to gauge their ability to do so than a work sample? Obviously you don't drill someone on sorting algorithms, unless that's what you are hiring them for, but make them solve a simple task t…

The argument I usually hear is that many people don't do well under pressure or with others looking on. So by doing coding tests or whiteboard tests or whatever, you're selecting for people who do well in high-pressure situations, rather than people who are talented coders.

But I agree with you. I've interviewed many people who have an impressive resume and can talk the talk, yet can't even do Fizzbuzz.

Re: The Technical Interview Rift

#18

Post by jackmott »

kafkaesq wrote: post #10

Some useful advice, but something about the overall tone seems a bit off: You are a manager and it’s time to hire a new developer to join your impressive team of A+ players. That's where things started to go of course. You're not an "A+ player", and most of your team aren't "A+ players" either. You're just human beings doing the best you can and (hopefully) trying to improve a bit each day -- like anybody else. No on…

oh you said toxic.

Re: The Technical Interview Rift

#19

Post by amorphid »

When I worked as a technical recruiter, I found that a great way to screen candidates was to explain the "box" I was trying to put them in. I described the work I'd done to research the position, why I was screening for certain criteria, and that ultimately I wanted to get their approval on the summary I had written about them. Being non-technical, this worked better for positions I was experienced recruiting for of course.

For example, when recruiting a web developer, I'd start by asking a hiring manager what they wanted.

"Get me a full stack Rails developer who knows OO Javascript."

Then I'd just drill into why they asked for that until I didn' have manh questions. I'd be able to describe roughly what projects needed attention, how the tech stack helped solve that problem, and ask the candidate to help me sell them as someone who can do that. It wasn't perfect, but it worked better than most recruiting attempts I've experienced so far.

Now as a developer with a few years of experience, I feel I have no idea what I am doing, and am winging it at all times :)

Re: The Technical Interview Rift

#20

Post by Pyxl101 »

lisper wrote: post #14

I think Triplebyte has the right idea: essentially a take-home test conducted over a period of a couple of days. It allows a candidate to show off what they can do under realistic conditions, instead of allowing an interviewer to poke at what they can't do under highly unrealistic high-pressure conditions. A typical tech interview is more like a spelling bee than a realistic test of a candidate's abilities: if you ha…

I have tried using take-home tests before. The level of plagiarism was astonishing. And that's just the plagiarism I could detect.

Even with a problem that's unique to my organization, I don't know how I could trust that the actual candidate themselves was the one who completed it, and that they completed it without unfair assistance (e.g. from other people). Similarly, I have a habit of looking over someone's resume and picking a few random technologies they mentioned to discuss. I'm surprised how often candidates claim experience with a technology and can't really describe what they've done with it or discuss it intelligently. The level of dishonesty is high.

For all of the downsides of interview-based hiring, at least I know what I'm getting (modulo error bars on assessment efficacy).

> I couldn't remember/figure-out-on-the-spot the iteration condition for estimating square roots by the Newton-Raphson method, and I was not willing to cheat by looking it up on Wikipedia while I was on the phone

I don't ask the kind of questions that require obscure knowledge. I just ask questions that you can problem-solve with regular rational thinking, with questions that usually admit a "naive" brute-force style solution that can be improved upon. If you did want to look up some algorithm that would be fine with me, but I am more impressed by a quick and confident reasoning through the problem followed by a fluid implementation of the naive solution, than I am of sophisticated solutions with better algorithmic performance or accuracy.

Post reply on HN