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

71–80 of 97 posts

Re: The Technical Interview Rift

#71

Post by lj3 »

luhn wrote: post #17
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.

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

And I've interviewed many people who can do fizzbuzz because they studied for it (CTCI) and wind up being terrible programmers.

The end result? Technical interviews are, at best, a completely random hiring signal. You'd be better off flipping a coin. It's better to be lucky than good, so why not use luck as a selection criteria?

Re: The Technical Interview Rift

#72

Post by clifanatic »

jdmichal wrote: post #31
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…

You're argument is exactly what I call the difference between a "trade programmer" and a "computer scientist". You are describing the former, while all the Google-copycat interviews with algorithms and data structures are designed to hire the latter. As you said, trade programmers typically glue together existing components and frameworks. Sometimes, this is really all that's necessary, as you have proven with your b…

> You're argument

* your

"you're" expands to "you are" - substitute "you are" in the sentence above and you can see that it's incorrect.

Re: The Technical Interview Rift

#73

Post by mgkimsal »

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…

Almost no one advertises for an executive that has a handle on software development, contract management, financial oversight and more.

Re: The Technical Interview Rift

#74

Post by AvenueIngres »

sqeaky wrote: post #63
mancerayder wrote: post #35

Earlier quoted context omitted.

If you start with github repositories for your candidates, aren't you filtering out people who do things other than work? Most of us work 40 to 60 hours a week, and sign paperwork that says that any code we write belongs to the company. But now we need to work Saturday and Sunday on open source projects so we're worthy of sharing a coffee with a hiring manager?

> says that any code we write belongs to the company. I have turned down several jobs when they tried to hit me with that clause. I have negotiated a better clause that gave them the work I made for them, which just happens to line up with state law here > But now we need to work Saturday and Sunday on open source projects so we're worthy of sharing a coffee with a hiring manager? I wouldn't want to hire someone who…

>I wouldn't want to hire someone who didn't enjoy coding enough that they didn't have something on publicly visible repo.

There is lots of reason why competent developers would not actively participate to OSS or have public repos. I think you are holding applicant to an unreasonable standard that does not entails they are bad if not upheld. I have worked with some extremely talented people - far more than I ever could be - who had 0 contributions, 0 repos and publicly available code.

Why? Because they valued the time spent with their family and friends more. They got the job done which is ultimately what I pay them for. Which is all that matter really. Are they competent? Do they get work done? Can they potentially take-up bigger engineering challenges (i.e can they grow). Yes? Welcome at X co.

Re: The Technical Interview Rift

#75

Post by x0x0 »

kafkaesq wrote: post #57
x0x0 wrote: post #34

Earlier quoted context omitted.

figure out in the sense of discover? sure Figure out in the sense of work out the updates, particularly for f:R -> R, if you already understand NR? That's totally doable in 5 minutes with paper; it's just figuring out an x intercept. And remembering/finding f such that f(sqrt(2)) = 0 I've also been asked, in person, the derivative of x^x. Hope you remember logarithmic differentiation! It's not like, had you happened…

"Discover" in the sense of "derive ab initio , truly never having seen an iterative root-finding method, or anything analogous to it" -- like Newton and Raphson both did, separately -- I highly doubt it. Re-derive your (or my) perhaps-more-than-a-bit-stale-by-this-point derivation, from way back when, under non-interview conditions? Yeah sure -- assuming we were actual math majors, or among the 10% or of CS majors wh…

oops -- when I said "figure out in the sense of discover? Sure" I was unclear, but I agree -- that request would be ludicrous.

That said, I have full faith that Gauss would pass that interview. Probably Euler, Tao, Dantzig, and Turing too =P

But it's not entirely unreasonable for optimization/OR/ML people. Mostly they have to remember how to construct the right function to find the zero of. Most applications of NR just want to find the zeroes of gradients of loss functions.

I certainly am not disputing the silliness... I personally am not good at math at a whiteboard while someone is staring at me. And full disclosure: I remember NR from the picture -- the x intercept of the tangent is (hopefully) closer to the zero than the initial guess.

Re: The Technical Interview Rift

#76

Post by jghn »

jdmichal wrote: post #31
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…

You're argument is exactly what I call the difference between a "trade programmer" and a "computer scientist". You are describing the former, while all the Google-copycat interviews with algorithms and data structures are designed to hire the latter. As you said, trade programmers typically glue together existing components and frameworks. Sometimes, this is really all that's necessary, as you have proven with your b…

I think your percentages are too low. IMO it's more like 95-97% of businesses are 99-100% served by what you describe as a trade programmer.

The problem is that it seems that 90+% of shops think they're 0% served by trade programmers.

Re: The Technical Interview Rift

#77

Post by jghn »

AvenueIngres wrote: post #5

Here is my take on hiring: an active Git repository with a decent amount of non-trivial code/projects generally gets applicants I have to evaluate to skip the whiteboard interview and instead grab lunch or coffee with me. We then discuss technology/software engineering. I find this approach to have yielded much more conclusive results, though it probably would not "scale" well. You can quickly tell whether someone is…

Do you just look at their own projects or their public activity in general? I have a lot of the latter but very little of the former and the stuff I do have in the former category isn't particularly flattering.

Re: The Technical Interview Rift

#78

Post by jghn »

lj3 wrote: post #69
sqeaky wrote: post #63

Earlier quoted context omitted.

> says that any code we write belongs to the company. I have turned down several jobs when they tried to hit me with that clause. I have negotiated a better clause that gave them the work I made for them, which just happens to line up with state law here > But now we need to work Saturday and Sunday on open source projects so we're worthy of sharing a coffee with a hiring manager? I wouldn't want to hire someone who…

> I wouldn't want to hire someone who didn't enjoy coding enough that they didn't have something on publicly visible repo. Why? Those people sound like terrible employees. Those are the people who come into work to punch the clock and get paid while saving their energy and creativity for their side projects, which is what they'd really rather be working on.

Most of my coding output for my job ends up on a public github repo, which is the best of both worlds.

Re: The Technical Interview Rift

#79

Post by lj3 »

jghn wrote: post #78
lj3 wrote: post #69

Earlier quoted context omitted.

> I wouldn't want to hire someone who didn't enjoy coding enough that they didn't have something on publicly visible repo. Why? Those people sound like terrible employees. Those are the people who come into work to punch the clock and get paid while saving their energy and creativity for their side projects, which is what they'd really rather be working on.

Most of my coding output for my job ends up on a public github repo, which is the best of both worlds.

That would be nice. Are you a library or framework developer?

Re: The Technical Interview Rift

#80

Post by x0x0 »

wyager wrote: post #21
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 don't have time for that. Nobody wants to spend their evenings working on exams. I'd prefer a few hours of onsites any day.

It's more reasonable for TripleByte because they share across companies. I agree, for a single company I have to be really interested to agree to give up 4+ hours...
Post reply on HN