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

People suck at technical interviews

seldo.com

Post reply on HN
Print view View original

171–177 of 177 posts

Re: People suck at technical interviews

#171

Post by danielweber »

SnacksOnAPlane wrote: post #11

My go-to question for technical interviews is "how would you write Scrabble?". It's very open-ended. I expect them to ask me questions like "what do you mean, write Scrabble?", to draw out some class diagrams, and to implement some scoring. It shows how self-directed they are and how much they trust themselves to develop architecture. I hate questions about bit-twiddling and sorting algorithms. I wouldn't remember th…

I expect them to ask me questions like "what do you mean, write Scrabble?", to draw out some class diagrams, and to implement some scoring. It shows how self-directed they are and how much they trust themselves to develop architecture.

This is a psychological test. You describe how you would imagine yourself solving it -- which may or may not be accurate -- and think that's how "good developers" would approach the problem.

The candidate doesn't know you. You might be the person who says "I'm looking for the candidate to tell me that is a stupid question" or "I expect the candidate to make a first simple iteration planning to throw it away instead of bothering with UML diagrams."

For the candidate, this is a game of rock-paper-scissors where they have to guess the state of the PRNG sitting across the table from them. There is a much better route: tell the candidate what you want[1] and see if they give it.

[1] Tell them directly; it shouldn't be buried in a post on your company's blog. I have encountered this pattern myself.

Re: People suck at technical interviews

#172

Post by chrisbennet »

pastProlog wrote: post #63
tptacek wrote: post #20

This is a really excellent post. It talks about a bunch of things that are hobby-horses of mine (I help run recruiting for a large software security firm), and I find myself agreeing with more of it than I disagree with. I would go a little further than Laurie does. I think several of the goals he sets up for his process are not in reality achievable in an interview process. Starting axiom: job interviews are among t…

> job interviews are among the most hostile experiences professionals endure in our industry I don't find being questioned during an interview hostile, although I do feel I need to be prepared to be tested. The most bothersome part for me is companies asking for me to list several references, often specifically asking for previous managers. I am usually given a standard application form to write their names, phone nu…

Re: references

I've had former manager (and friend) call me and ask: "Are you looking for work?" When I told him "no", he told me that a recruiter had called him to "check my references" as a pretense so they could ask him if he was looking to hire anyone.

I would be very careful about giving out references.

Re: People suck at technical interviews

#173

Post by chrisbennet »

nkcpiytdhauwuhc wrote: post #10

Fizzbuzz isn't supposed to be a test of your knowledge of the modulo operator. It's supposed to be a very low bar that can filter out a large percentage of candidates who have no business being there. If you spend 20 minutes on Fizzbuzz, you're doing it wrong. It should take 10 tops, and be limited by how quickly the candidate can write.

It isn't supposed to be a test of whether you know the modulo operator but in practice it works out that way.

True story; my wife was going over her (correct) answers to a coding test with the interviewer and he asked her "What's this?" in reference to the modulus operator. The interviewer didn't recognize it.

I use the modulus operator almost daily so it seems obvious to me but I realize that everyone has different experiences or things they are ignorant about. IMO, fizzbuzz is a test of whether you know the modulus operator "trick".

Re: People suck at technical interviews

#174

Post by lutusp »

chrisbennet wrote: post #173
nkcpiytdhauwuhc wrote: post #10

Fizzbuzz isn't supposed to be a test of your knowledge of the modulo operator. It's supposed to be a very low bar that can filter out a large percentage of candidates who have no business being there. If you spend 20 minutes on Fizzbuzz, you're doing it wrong. It should take 10 tops, and be limited by how quickly the candidate can write.

It isn't supposed to be a test of whether you know the modulo operator but in practice it works out that way. True story; my wife was going over her (correct) answers to a coding test with the interviewer and he asked her "What's this?" in reference to the modulus operator. The interviewer didn't recognize it. I use the modulus operator almost daily so it seems obvious to me but I realize that everyone has different…

> It isn't supposed to be a test of whether you know the modulo operator but in practice it works out that way.

Yep. And at HN, actually knowing this or anything else assures that you will be downvoted with a probability of 1.

> I use the modulus operator almost daily so it seems obvious to me but I realize that everyone has different experiences or things they are ignorant about.

I see the modulo operator applied to a common undergraduate math question -- if a given date lands on a Tuesday, and if you add 500 days, what day of the week does the result land on?

Re: People suck at technical interviews

#175

Post by kethinov »

Ryel wrote: post #115
Matt_Mickiewicz wrote: post #105

Earlier quoted context omitted.

Not one company has invited you to come onsite for a day-long interview to code alongside the team? You should be upfront with the employer. "I think the best way for me to showcase my skills would be to come onsite for a day, and tackle whatever projects you're working on currently. After 8 hours, you'll have a good assessment as to whether or not it's a fit, and vice-versa."

Not one company has asked me to write code on a computer. Also important to note these are almost all fully funded companies with solid dev teams. I've had great offers that just never worked out due to fit (or rather lack of passion from the dev teams). I've thrown the offer out there on several occasions but it's always refused or delayed to the point where contact drops. One time the senior engineer told me my off…

Offering to pay for it probably puts people off.

You're suggesting a quite legitimate (if not common) method of assessing your skills. You're already paying for it with your time, as are they.

If they think it's a novel idea and worth their time to give it a shot, they might go for it. Or possibly give you homework as a decent compromise.

But the upfront suggestion of money exchanging hands does add a certain ridiculousness to the idea on the face of it.

Just ask for a coding assignment or a trial day at the office on an actual problem to work on without cash and it might work better.

Re: People suck at technical interviews

#176

Post by danielrm26 »

While I can see potential danger in hiring friends, I think it's wrong to say outright that it's a bad idea.

Most bad hiring of friends comes from being bad at hiring in general. If you hire someone BECAUSE they're your friend, then you're doing it wrong. The idea is to hire people who are qualified and who you know to be quality over a long period of time.

Used properly, friendship can just be considered a source for good references in this case, and potentially some additional glue during tough times.

It's true there are risks to hiring friends, especially if it's done poorly or for the wrong reasons, but it's also true that there can be extraordinary benefits.

Re: People suck at technical interviews

#177

Post by russelluresti »

watwut wrote: post #57
russelluresti wrote: post #23

I'm not sure I agree with the "team fit" thing. I get his point - most people don't understand what team fit is or can't separate it from personal bias. But here's my counter-argument. Every company and team has different core values. "Team fit" means matching company and team values. For example, I work on educational software for teacher and students. My definition of "team fit" (for this particular team/company) i…

Most people are fully able to work in both 100% done and release flawed but soon scenarios. Most people simply adjust to company they work in just fine. Almost all are also can work in both team and lone gunman settings - although they will have preference there. Unless you are very careful, you can select out very good candidates basically based on how companies they previously worked in performed in those scenarios…

There's a difference between what you CAN do and what you VALUE doing. Yes, people can put up with conditions they find undesirable, but they'll be unhappy and cause others working with them to be unhappy as well.
Post reply on HN