The Technical Interview Rift • Hacker News Board

Re: The Technical Interview Rift

#31

Post by jdmichal » Tue, Oct 18, 2016, 7:04 PM UTC

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 businesses. Computer scientists are qualified to create those underlying systems in the first place, properly weighing and selecting the algorithms and data structures to meet constraints.

I don't mean any of this to cast a negative light on trade programmers. They are 80-90% what a business needs, and I think there should be better opportunities for people to become such without the 4-year degree. [0] However, the limitations also need to be understood, and in my opinion a business is best served with a smaller set of computer scientists to provide technical guidance. Otherwise, you will see a lot of history-repeating-itself type of bad decisions.

[0] This is basically the hole that bootcamps have attempted to fill. They could also be filled with associates degrees or apprenticeships.

Re: The Technical Interview Rift

#32

Post by inframouse » Tue, Oct 18, 2016, 7:11 PM UTC

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.

On the one hand, there a significant number of people that can't fizzbuzz applying for the jobs.

On the other hand, there are a significant number of people that can only do the interviews and are not good engineers in general once hired.

This is made even worse by 1) the cottage industry teaching people to crack/break the interview process, and 2) the number of people hyping their personal "brand" via conf talks, standards nonsense, etc. as a way to sidestep more engineering vetting. (Not everyone does this of course -- but there's a significant number of people that do it just for career upside).

Personal anecdote as a hiring manager: I've found that some of the best interviewees but mediocre mid-level engineers are those with a history of low to mid-level jobs at the largest companies.

Re: The Technical Interview Rift

#33

Post by jeremyis » Tue, Oct 18, 2016, 7:13 PM UTC

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…

There was no take home test for me. It was a 45 minute multiple choice test, a timed coding problem after that which you could skip if you did well on the test, and then a 3 hour or so chat that involved an hour of coding something and various systems and algorithms questions

Re: The Technical Interview Rift

#34

Post by x0x0 » Tue, Oct 18, 2016, 7:15 PM UTC

kafkaesq wrote: post #16

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…

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 to not have used this trick for a derivative in the last 10+ years, you could look up and recall in 5 minutes given you understand chain rule. I remembered it, but what kind of filter is this?

Re: The Technical Interview Rift

#35

Post by mancerayder » Tue, Oct 18, 2016, 7:18 PM UTC

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…

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?

Re: The Technical Interview Rift

#36

Post by oceanofsolaris » Tue, Oct 18, 2016, 7:19 PM UTC

kafkaesq wrote: post #16

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…

Not to sound too snobby (I would have notrecognized the Newton-Raphson method is by its name either), but I think it is at least plausible to figure out the method on the spot.

If you either know how the first order of a Taylor series looks like or just brainstorm a bit about how the derivative could help you in finding a root, you will figure out the Newton-Raphson method rather quickly. But then, it really depends on the job whether this is actually knowledge the interviewer would want to test.

That said, I completely understand that even if you would have the required knowledge, it is really easy to fumble during a high-stress situation.

Re: The Technical Interview Rift

#37

Post by bmj » Tue, Oct 18, 2016, 7:20 PM UTC

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…

Question for you: is your judgement of the applicant affected by whether or not they have an active GitHub repo?

Re: The Technical Interview Rift

#38

Post by t0mbstone » Tue, Oct 18, 2016, 7:21 PM UTC

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…

This is pretty much almost exactly the same boat that I am in.

Re: The Technical Interview Rift

#39

Post by kafkaesq » Tue, Oct 18, 2016, 7:21 PM UTC

jasode wrote: post #29

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…

>, but something about the overall tone seems a bit off: [...] You're not an "A+ player", and most of your team aren't "A+ players" either. I believe you misinterpreted the author's backhanded "compliment" about teams' _self-proclaimed_ "impressive A+ players" . His tone is sarcasm if you combine it with the repeated fixation on "Fibonacci" puzzles in the rest of the essay: - quote: , what possible insight does quest…

Ah - so he's a bit ahead of me (with his sarcasm), then. It's just that I see the "A+" label (and its various synonyms: "phenomenal", "astonishing", "rockstar", "badass", "10x-er", etc.) touted in all seriousness, far too often -- that I guess I've become conditioned to being always a bit negatively triggered by them.

Re: The Technical Interview Rift

#40

Post by nilkn » Tue, Oct 18, 2016, 7:22 PM UTC

xenihn wrote: post #15

nilkn wrote: post #13

Earlier quoted context omitted.

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.

Yes, or some sort of VP position.