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

21–30 of 97 posts

Re: The Technical Interview Rift

#21

Post by wyager »

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.

Re: The Technical Interview Rift

#23

Post by lisper »

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…

Actually, under non-brain-wedgie conditions, I can re-derive Newton-Raphson because I do have a good conceptual grasp of it. (In fact, after I got off the phone, I did it just to convince myself that I could. It took me about five minutes, which is nothing under realistic conditions, but a long time when you're on the phone.) But at the time I had a brain wedgie, and the interviewer just kept pushing and prodding and wouldn't let it go. It was damned annoying. I was sitting there thinking, why are you so fixated on this?

It was definitely their loss because the technical problems they were facing were very similar to ones that I had faced (and solved!) in a previous startup (network optimization problems). But I never even got to talk about that.

Because of that experience, I now make it point whenever I interview someone to always ask, particularly if they're floundering, "What should I ask you about that will let you show off your strengths?" I don't have any qualms rejecting someone who can't answer that question (and a surprising number of candidates can't).

Re: The Technical Interview Rift

#24

Post by ChuckMcM »

Pyxl101 wrote: post #20
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…

Isn't getting back plagiarized answers a good indication though? Did you tell them you wanted it to be their own work?

As I have gotten older one of the things I'm cognizant of is the difference between what I mean and what my kids hear. So "take this problem home and solve it" from me means that they should take it home work on it themselves and bring back their best solution. But they might hear it "take this out of my sight, put the answer on it, and bring it back to me." where in the land of "out of sight" there are really no restrictions on what or how they get it done. As a result I find myself being a bit prescriptive, saying "Take this home and work on it, and bring me your solution tomorrow, we're going to talk about your process of how you got to the answer. When we talk, saying 'I asked on Stack Overflow' isn't going to be a good answer, ok?"

Their response will be informative, from moral outrage that I would suggest they can't do the work, to understanding that the integrity of the process was part of the problem set. All of that helps you understand how they approach being asked to do things.

Re: The Technical Interview Rift

#25

Post by lisper »

Pyxl101 wrote: post #20
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…

> plagiarism

Triplebyte controls for that by having a followup on-line session where you have to walk them through your code and modify it on the spot. They probably use regular plagiarism filters too.

Re: The Technical Interview Rift

#26

Post by bdavisx »

Pyxl101 wrote: post #20
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…

>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

I know what you're saying, but there's different levels.

Several years ago, I read a couple of books on Hibernate/JPA and played around with it on some toy projects. Where I work never really ended up using it.

Should I put Hibernate on my resume? I know a lot more than someone who has never used it, but it's been a few years since I've done anything with it, and I never really used it in production/anger.

I wouldn't pretend to be an expert (and I'm guessing some people with my level of experience would), but I still think it's OK to put it on my resume (although I'm not sure if it's on my current resume because I don't really care to work with it :)).

Re: The Technical Interview Rift

#27

Post by mathattack »

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…

A+ is also relative to the environment. Performance doesn't always extend across companies. Solo programmers who are an A+ in informal environments struggle in environments that require more inter-programmer coordination. And some A+ specialists sometimes struggle when expected to be generalists, and vice versa. Some big company superstars thrive in small companies, but not all. And some startup superstars would fall apart with the structure of Microsoft and Google.

Re: The Technical Interview Rift

#28

Post by bdavisx »

cbanek wrote: post #11
psyc wrote: post #4

Earlier quoted context omitted.

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.

Yes, and they could easily hide a noisy, chaotic work environment in a video chat as well.

Re: The Technical Interview Rift

#29

Post by jasode »

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 questions like “solve a Fibonacci sequence” + whiteboard + no internet give you to know about a person fit for a development role?

- Go Beyond Fibonacci Pen/Paper Tests to Assess Candidates

- If you get Fibonacci’ed in your next job interview, perhaps you should look elsewhere? If you are the one doing the Fibonacci’ing, you are doing it wrong.

(In other words, if your team bombards candidates with Fibonacci, you of course will think your company consists of A+ players!)

His "tone" might have tripped the obvious sarcasm detector more readily if he wrote it to say: "it's time to hire a new developer to join your impressive Project Euler hackathon champions. blah blah blah"

Re: The Technical Interview Rift

#30

Post by protomyth »

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, and I was not willing to cheat by looking it up on Wikipedia while I was on the phone. Their loss."

Out of curiosity, what type of developer position were you interviewing for?

Post reply on HN