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

How not to hire a software engineer

tonsky.me

Post reply on HN
Print view View original

151–160 of 239 posts

Re: How not to hire a software engineer

#151

Post by r_smart »

wink wrote: post #114

On the plus side: I wholeheartedly agree with all those points. On the contra side: Nothing of this really felt like it helped me. I found interviewing people absolutely horrible and almost never had a good feeling. People who seemed like they may have been a good fit didn't get offers for one reason or another, some people seemed awesome in the interview and then weren't. Overall I've been happy with the decisions I…

At my last employer, I sat in on an interview for a co-op with my boss. After asking the interviewee some questions the conversation went basically like this:

Boss: Do you have any questions for me?

Co-op: No

Boss: Would you like to know about the company? What we do?

Co-op: No

I couldn't help myself from laughing. I know he's just a student, but he's still a 20 something adult. No interest at all, just looking to check another box on his list of credentials. At least fake it!

Re: How not to hire a software engineer

#152

Post by cr0sh »

tuco86 wrote: post #47

I really liked what my last interviewer did. He did not think of an abstract quiz to test some abstract skills. He took a Problem they where fighting with for some time and we just had a conversation about it. When can you start?.. Tomorrow.. See you then. Find someone you can work with on the actual problems you face: work with them during the interview. Just struck me as genius. I was nervous about my CV not lookin…

It does sound like a good way to interview a candidate.

But I can see from the company's side it being a bit of a potential legal challenge issue. Depending on what the problem is and how deep it goes into the codebase or whatever, you might get into proprietary process information that someone outside the company shouldn't have access to, possible IP access violations, etc.

If it can be done in such a way to avoid those pitfalls, then it might be ok. But I bet it's a tricky challenge, and may be why it isn't done often?

Re: How not to hire a software engineer

#153

Post by ticmasta »

We ask a programming question that's harder than fizz buzz but not terribly difficult. There's an opportunity to get the gist, but miss some edge cases which leads to good conversations. When I go in to discuss the solution, I ask how it went and we end up with three scenarios:

1) candidate is modest (it was pretty tricky but I think I got it) and they did a good job

2) candidate is modest (it was tough I think I screwed X up..) and they made some major mistakes

3) candidate says it was easy and totally blew it.

I've yet to have a candidate who said it was a breeze actually ace it.

Re: How not to hire a software engineer

#154

Post by tombert »

Years ago, I was interviewing, and they asked me a fairly typical "Design Twitter" question.

I always hate these kinds of questions because it took Twitter 10 years to get to where it is, and I'm certain they didn't design all of it in 15 minutes on a whiteboard.

Anyway, I'm drawing little boxes and arrows, and when the subject of a DB comes up, I ask "do you want availability or consistency", because I figured that CAP theorem was part of the "gotchas" on this. The interviewer said "I want both", to which I replied, kind of sheepishly, that you cannot have both. We go back and forth, and eventually I pull up the CAP theorem wiki page on my phone and he had to concede the point.

This is rare; usually when I know more than the interviewer, they double down on their wrong ideas. I have several stories like that.

Re: How not to hire a software engineer

#155

Post by cr0sh »

kod wrote: post #134
gwbas1c wrote: post #125

Earlier quoted context omitted.

Doctors have to go through a rather grueling licensing process. The job interview is mostly about determining mutual interest. Doctors also need to go through periodic re-credentialing. To put it bluntly, when a doctor has credentials, you at least know that they're competent; and more competent than 2-4 1-hour quizzes.

Speaking as a licensed attorney, passing the bar does not mean that you're competent.

But if you were applying for a position at another firm, what would they likely look at to determine competency?

I'm not a lawyer - but my guess would be how many cases they've handled in the past, whether those were with another firm or by themselves (not sure what this is called - if anything - "self-employed lawyer"?), and how the case turned out and such (though this latter thing may not tell you much - after all, they could be a great lawyer and candidate, but lose every single case not based on anything they did or didn't do).

As you can probably tell - I really don't know what I am talking about in this area...

Re: How not to hire a software engineer

#156

Post by bendixso »

morkfromork wrote: post #3

Lately I have done a few at home code challenges for companies. They usually take several hours. They are perfectly functional and use minimal code but, the only feedback I receive is: "we're not moving forward". They won't discuss anything with me. The only impression I get is that your company is terrible and I will never respond to your recruiters again.

Never take a code test until you speak on the phone with an engineer at the company. That way, they need to at least trade something valuable of theirs (expensive engineer time) for something valuable of yours (your time). When you adopt this policy, all kinds of B.S. magically vanishes from your life.

After all, you would never continue to try to win the affection of a guy/girl who wouldn't at least give you a first date? Why do the same for a company that can't bother to give you some of their time?

Re: How not to hire a software engineer

#157

Post by tombert »

morkfromork wrote: post #3

Lately I have done a few at home code challenges for companies. They usually take several hours. They are perfectly functional and use minimal code but, the only feedback I receive is: "we're not moving forward". They won't discuss anything with me. The only impression I get is that your company is terrible and I will never respond to your recruiters again.

I hate these take-home code projects, to a point where I won't do them for similar reasons that you mentioned ("we're not moving forward, we will keep your resume on file!").

It's sort of a selfish way of interviewing; to write good code for these projects, it can take me upwards of 8 hours. An engineer where I live (NYC) can fairly easily make $50/hour (usually more), so they effectively expect me to give $350-450 of time for this company where there's a fairly high likelihood that they'll tell me to buzz off. I typically write in a very functional lispy style (even when I did JavaScript), and while the overall understanding of FP has improved in the last couple years, a lot of the interviewers would simply not understand what I was writing, and ask me to write it "more object oriented".

Big corporations like Google can get away with that, but for a small startup I really don't think it's worth it to do them (not to mention that I had a friend who did one of these assignments, and they ended up using his code in production without paying him).

Re: How not to hire a software engineer

#158

Post by ignoramous »

ummonk wrote: post #136
ignoramous wrote: post #23

I think the crux of the problem is... Everyone knows what to expect in a SAT exam, and still if one complains that they didn't bother preparing for it 'cause they do not have enough time... That excuse is not getting them an admission to top institutions, which admittedly have no short supply of folks willing to prepare and go through the grind. It is sad that interviews in tech have been reduced to a process that re…

>It is sad that interviews in tech have been reduced to a process that resembles SAT-esque entrance exams. And now, there's an entire industry around prepping candidates for the interviews. I'm not sure why that is bad. The more standardized the interview process is, the more consistently people can prepare for interviews and know what to expect. The interview process doesn't have to represent actual work, as long as…

> I'm not sure why that is bad. The more standardized the interview process is, the more consistently people can prepare for interviews and know what to expect.

Yep, agree. You tend to then hire folks who are good at interviewing and not at getting the job done. I think there is no right answer but multiple right answers. Provide three or four different interview loops and let the candidate choose which one they want to opt for: for instance, one loop is the standard algorithms/data-structure, the other loop is a take-home problem, the third could be tptacek-style, the fourth could be stripe-style, and so on...

> That's an obviously false premise.

Sorry, I didn't get. The article argues that obviously that many folks with that much amt of work experience can't all be secretly terrible that we continue to find it hard to hire and so the current interview process needs an overhaul.

Re: How not to hire a software engineer

#159

Post by jimbokun »

TallGuyShort wrote: post #84
kristopolous wrote: post #10

I look to see if I can trust them to not do dumb things. That's really it. What's the ego, arrogance, competence, willingness to ask questions, interrogate things, redefine problems to be less work (or none at all). Do you see what's not there? Programming language competency. Database knowledge. Things like that. I've been hired as a Ruby programmer, I didn't know Ruby. I was hired for mainframes in the 90s - I had…

I interview quite a lot, and one of the things I try to do in an interview is work through a problem that I almost certainly understand more deeply than any of the candidates (both because it's my niche and because I've worked through the exact problem with hundreds of candidates before). There's a certain minimum bar that I expect any educated and intelligent individual to achieve if they're a good match for the job…

" I looked up the problem and found out he had done Ph.D. research in that area, and there was no general O(n log n) solution - only solutions that could do that in most practical cases."

The Kobayashi Maru of programming interview questions!

Re: How not to hire a software engineer

#160

Post by therealx »

TallGuyShort wrote: post #142
jrochkind1 wrote: post #135

Earlier quoted context omitted.

I think that would be kinder to the applicants if you told them that there were going to be things you didn't expect them to know required for a good solution and you didn't necessarily expect a good solution but were interested in how they approached it. You'd still be able to tell nearly as much by what questions they asked, and it would be less testing for "How well do they do under unrealistic/unrepresentatives k…

I generally do tell them it's a complex problem and I'm looking more for how they approach it than any specific solution. I don't tell them everything I'm looking for because then they'll just pretend to be the way I want them to be. But I disagree that it's unrealistic. I've had far too many employees and coworkers who don't understand what is being asked of them or don't know what they're doing, and try to fake it…

I like this idea because it allows me to figure out if they have one of the most important skills: being able to say "I don't know" without wasting a lot of time.

IMO anyone else saying you should tell them the solutions might not have answers are dancing around needing to have that skill.

Post reply on HN