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

When hiring developers, have the candidate read existing code

freakingrectangle.wordpress.com

Post reply on HN
Print view View original

91–100 of 565 posts

Re: When hiring developers, have the candidate read existing code

#91

Post by ipaddr »

lkrubner wrote: post #26

My one big tip: One vice that I see among hiring managers is an unwillingness to ask tough follow-up questions. If you ask a question and there is any vagueness in the answer, you need to drill down deep until all vagueness is eliminated, so you understand exactly what the person knows. Follow up on what's said, but also follow up on what is not said. Here’s a real-life example. I asked a recent applicant (for a full…

If you wanted to check if they can write a query than ask them to create a simple select or insert statement. The drilling down turned the interview into a hostile conversation. Easily ways to test that skill.

Re: When hiring developers, have the candidate read existing code

#92

Post by johnqian »

ddaalluu2 wrote: post #48
johnqian wrote: post #18

I sometimes ask candidates "what kind of interview do you feel would best bring out your strengths?" and try to adapt the interview to their response if I can. It's helpful if they want to talk about side projects or war stories, but doesn't pressure them to. I still give my coding challenge after. Wonder why no one else does this.

Quoted post unavailable.

I'm wary of engaging with this comment at all but... How are you so sure it was "some psycho test" rather than, say, their actual availability?

Re: When hiring developers, have the candidate read existing code

#93

Post by gaoshan »

HorizonXP wrote: post #19
gaoshan wrote: post #14

This is exactly what I started doing at my company a few years back. You are presented with a complete app written in the stack we use. This app has some bugs we will solve to get it working (nothing that's a trick... actual, commonly encountered bugs that have all the error messaging you need to solve them). Once it is working you will walk me through a particular flow of the app, explaining what is going on and why…

Are you able or willing to share some samples? I've been shying away from doing technical assessments the "old way," instead focusing on having a discussion about a candidates past projects. I feel like your way could be a good chance to get insights into someone's problem solving and critical thinking skills, which is truly what we value as a dev team.

I can’t share the code, unfortunately. It’s a full stack CRUD app with some third party API integrations. You’ve got it! Gaining insights into their problem solving and critical thinking is a primary goal (more important than fluency in the various frameworks used).

Re: When hiring developers, have the candidate read existing code

#94

Post by grog454 »

xtracto wrote: post #59
paulgb wrote: post #47

Earlier quoted context omitted.

One thing I like about this (as opposed to a “blank slate” coding challenge) is that it shows how well the candidate is able to fit into the broader design style of the surrounding code. Not just the superficial things (like naming conventions), but also the structural patterns.

Back when I was a hiring manager for programmers I liked setting a "code challenge" where we gave the candidate a simple game and he had to transform it into another game. For example, we gave you a tetris game, you had to change the code to make a snake game. Or change an Othello game to a "number sliding puzzle" game. It was very interesting comparing people that really made an effort to use the game code vs candid…

>It was very interesting comparing people that really made an effort to use the game code vs candidates that just deleted most of the stuff to implement their logic.

What does "very interesting" mean here? What does this particular comparison tell you? It's genuinely unclear to me which you prefer, why, and what signal you get beyond willingness to follow an instruction in a peculiar context.

Re: When hiring developers, have the candidate read existing code

#95

Post by gaoshan »

andrewflnr wrote: post #28
gaoshan wrote: post #14

This is exactly what I started doing at my company a few years back. You are presented with a complete app written in the stack we use. This app has some bugs we will solve to get it working (nothing that's a trick... actual, commonly encountered bugs that have all the error messaging you need to solve them). Once it is working you will walk me through a particular flow of the app, explaining what is going on and why…

"Bugs we will solve" seems to imply there's still a coding component. Is that correct? That's a different thing from what OP describes (and FWIW I'm pretty sure I like yours better).

Yes, that’s fair. However the bug is really trivial to solve and does not require much beyond reading the console error and then making a tiny change to the server code.

Re: When hiring developers, have the candidate read existing code

#96

Post by lanstein »

kozd wrote: post #77
BFLpL0QNek wrote: post #41

I like this approach. Far to often I’ve interviewed at places and been grilled by the interviewer only to find out when you start the quality isn’t great, what you where grilled on you won’t be working on “as that’s to hard” or “we don’t do that” despite being grilled on it and the level of skill not to great they just want senior people. It’s the bait and switch. At least being taken through existing code you know w…

Why no PRs?

I read “no open PRs”

Re: When hiring developers, have the candidate read existing code

#97

Post by aunty_helen »

lkrubner wrote: post #26

My one big tip: One vice that I see among hiring managers is an unwillingness to ask tough follow-up questions. If you ask a question and there is any vagueness in the answer, you need to drill down deep until all vagueness is eliminated, so you understand exactly what the person knows. Follow up on what's said, but also follow up on what is not said. Here’s a real-life example. I asked a recent applicant (for a full…

I had an interview like this for a senior position, it turned out to be the most enjoyable interview I've ever done. The group lead really showed himself and found out at what point would I stop and say I don't know.

There's nothing aggressive about this approach unless you make it that way and finding out if people will start bullshitting or admitting the limits of their knowledge is a massive advantage to someone you might need to depend on.

Re: When hiring developers, have the candidate read existing code

#98

Post by teddyh »

jra_samba wrote: post #86
teddyh wrote: post #81

Earlier quoted context omitted.

According to GNU libc, malloc(0) can return either NULL or a valid unique pointer value which can later be passed to free(). You seem to imply that one or the other is definitely true.

Yes. Write test code for glibc. You'll find it always returns one of the two. There is a reason for that.

Firstly, you seemed to imply that malloc(0) always, for all implementation, returns one or the other, and one of the two answers was wrong and the other was right.

Secondly, why should a C application developer know enough about the implementation details of malloc() to answer such an esoteric question? Malloc can not, by definition, be implemented in C, so it seems a bit out of scope.

Re: When hiring developers, have the candidate read existing code

#99

Post by jwatte »

BFLpL0QNek wrote: post #41

I like this approach. Far to often I’ve interviewed at places and been grilled by the interviewer only to find out when you start the quality isn’t great, what you where grilled on you won’t be working on “as that’s to hard” or “we don’t do that” despite being grilled on it and the level of skill not to great they just want senior people. It’s the bait and switch. At least being taken through existing code you know w…

Trunk driven development has worked well everywhere I've used it.

That being said, pull requests / code reviews / merge commits are totally compatible with that. Gerrit, for example, does every commit as a mini-pull-request on top of a branchless HEAD, and when the review finishes, you merge to main/trunk and off to CD it goes.

Re: When hiring developers, have the candidate read existing code

#100

Post by ChrisMarshallNY »

This makes a great deal of sense, to me.

But I am also the type of developer that would do well at this (experienced and older). Young folks, right out of school, or with just a couple of years of experience, would not do as well.

I’m pretty convinced that one of the goals of LeetCode tests is as a “young-pass filter.” It controls for people close to college age, where those types of problems are common, as well as people that are willing to work very hard, learning exercises that appear pointless.

Not sure that many companies, these days, are actually interested in older, more experienced, developers.

Post reply on HN