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

361–370 of 565 posts

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

#361

Post by nullc »

no-dr-onboard wrote: post #135

I’m personally against this approach. I’m an appsec person. I absolutely do not know how to write most of the code I review. In my past two jobs I’ve been required to read code and explain it during interviews. I’ve never had trouble explaining what’s going on because on a very basic level, most languages use the same conventions. If this were a heuristic of a good developer, it would let me (not a dev) in and who kn…

You might be overestimating the grade of people who make it through coding interviews.

I'd rather hire-- as a coder-- someone that could read code but would fail an interview where they coded, than someone who could pass some trivial coding interview but couldn't read code.

Obviously, people need to do both, but the reading seems less likely to get a false positive/negative in an interview.

Heck, given two candidates one who cannot currently code but reads code fluently vs one who can code (and not just pass a coding interview) but cannot read code-- I'd still prefer the reader. It's the more important skill.

Average industrial programmer is going to write 8 lines of code per day. If you can correctly read a codebase, you can probably manage to write 8 working lines of code per day for it on average. Maybe you wouldn't be #1 one the team overnight, but a fluent reader is at least on track to be average even if they hardly write at all now.

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

#362

Post by throwaway14356 »

in my ignorance i wondered.. perhaps it is possible to have some automation compare methods used in the employers software with ones used by the dev in their public repos?

Imagine how interesting a job offer would be if they can prove you will get to do things you know well.

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

#363

Post by ignoramous »

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…

> Those companies have often been sink or swim though and if you don’t make the grade you’ll be kicked out pretty quick.

I hope they weren't some gatekeepers you ran into... "don't use emacs and fish and the dvorak keyboard? you don't fit in here."

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

#364

Post by brongondwana »

EugeneOZ wrote: post #350
brongondwana wrote: post #340

Earlier quoted context omitted.

Yeah, but at this point you're not left with many other options other than sticking your finger in the air and hoping you can detect if they know how to write code.

Only if you are limiting yourself by the options mentioned by the top comment author :) I was interviewed many times without showing any of my code. The most effective way I saw: the interviewer gives you some code and asks you how you could refactor it, what parts you would implement differently.

To be fair, my "interview" for Fastmail was debugging a real production issue in realtime with one of the founders.

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

#365

Post by dgb23 »

Manuel_D wrote: post #118
csmiller wrote: post #75

Earlier quoted context omitted.

https://trunkbaseddevelopment.com/

https://trunkbaseddevelopment.com/trunk1c.png So trunk driven development means no PRs, until you decide you want to use PRs?

What’s the benefit of having release branches without commits if you can just use tags? I guess the difference is mostly cosmetic?

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

#366

Post by anyfactor »

berkes wrote: post #325
anyfactor wrote: post #297

Earlier quoted context omitted.

> You could clone an open source repo and use that if you're worried. The value isn't the code; it's the conversation. Open Source code plagiarism is a major problem and doing random forks/clone of popular repos to up your github cred is a thing and in my opinion it is unethical. Even if the interviewee tells you it is an open source project you will have a hard time distinguishing their code and the code from the or…

Who said th ex interviewee must present 'own' code there? The conversation can just as well be around a library, product or system that isn't authored or contributed to, by the interviewee. 'What architecture is used here, and what are the down and upsides in this implementation'. 'What would you do different'. 'Which part do you admire, and what don't you like'. Etc.

Don't you think it is implied?

Also why would I voluntarily talk about codebases authored by anyone other than me while having in-depth knowledge about it? Nobody looks under the hood of things that interests them, let alone be critical of it’s design.

Talking about product and system design is something that is vastly different than stand-alone codebase. If you as an interviewer are interested about something you have the capacity of directing the conversation flow toward that. Ask them introductory questions about a product/system, gauge their interest in it then ask their opinion about it.

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

#367

Post by olliej »

jseban wrote: post #356
olliej wrote: post #345

Earlier quoted context omitted.

What tool are you talking about? I've had patch review as back and forth comments in email, in bugzilla, in myriad other bug databases. If you can't send out an email with your patch as an attachment, and get feedback, then we have a problem, and the problem is not the adversarial nature of review.

But why would you use such a remote asynchronous late stage feedback loop, if you are literally sitting in the same room as your collaborators, during the whole development process?

You're not understanding the purpose of review.

The goal in review is to try to catch any oversights or errors in the code you wrote. The code you wrote may have been the result of of discussions with your coworkers, but the code still gets reviewed, even if by people you discussed the implementation with. That review will occasionally find things you missed, and then you can cycle, and re-review.

By definition, the review can only happen at the end of change development.

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

#368

Post by doix »

boomlinde wrote: post #289
zdragnar wrote: post #119

Earlier quoted context omitted.

> Bonus points for no PR’s and trunk driven development as that shows a very mature team. Ugh, pass. Trunk development is fine. Skipping PRs just brings back nightmares of SVN. Even if 90% of PRs are approved without comment, it's extremely helpful for everyone to have a second set of eyes on work before it is merged in.

Where I work, development is trunk based and without pull requests, and all code is reviewed. When I want to submit code, I push it to a staging area that tracks master. This causes the commits to appear in Gerrit where (conflict-free) rebasing can be performed with a single button and the code can be reviewed. During the staging I can change anything about the commits to my hearts content. Once everyone is satisfied…

What you are describing, is pretty much exactly how it works at every company I've worked at that used PRs. You create a new branch from master, make your changes, push the branch to github/bitbucket/gitlab, make a PR. While the PR is open, you can make any changes you want to the commits in that branch (since it's just a branch).

People look at the PR (which shows the diff) and approve it if they are happy, or request changes. If there are no conflicts, you can merge with a single button. Otherwise you need to resolve conflicts somehow. I normally just rebase the branch off updated master and force push.

> Creating a separate branch, pushing this to your public copy of the repository and then asking someone to pull from that branch into their master branch seems absurd to me.

That's how it works for open source projects because people do not have permissions to make branches in the main repo, so they must fork and have the changes in a different repo. I've never seen this done at a company, I presume everyone here is talking about creating branches in the main repo and requesting review before merging the branch to master.

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

#369

Post by jseban »

mstipetic wrote: post #261
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…

I’ve never understood this. I’ve had Teams grill me on questions I know most of them wouldn’t pass and they themselves said they’re struggling with delivering things. Some weird dick measuring thing

They want someone to do all the work so they can continue coasting, team effort!

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

#370

Post by lelanthran »

llimllib wrote: post #63
jra_samba wrote: post #55

When I did interviews @ Google (I only do hiring committee work now, thank god :-) I usually asked questions around bugs I added to an existing codebase, to see if the candidate can avoid the pitfalls I ran into by making bad assumptions. As I'm a pure C coder, my starter question was usually something like: a). What does malloc(0) return ? b). Why does it do that ?

I'm not anything other than a C tourist, and I see that the man page says it returns either NULL or a "unique pointer value that can later be successfully passed to free()." I'm kind of at a loss about why it can return either of those two things, somebody want to take a shot at explaining it?

> I'm not anything other than a C tourist, and I see that the man page says it returns either NULL or a "unique pointer value that can later be successfully passed to free()."

>

> I'm kind of at a loss about why it can return either of those two things, somebody want to take a shot at explaining it?

Any return from malloc, whether it succeeds or not, is a valid argument to `free()`. Hence, it can return NULL because `free(NULL)` is legal, and anything other than NULL has to be a unique pointer, because if it returns a duplicate then calling `free()` no the duplicate will crash.

Post reply on HN