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

191–200 of 565 posts

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

#191

Post by TameAntelope »

arduinomancer wrote: post #190
TameAntelope wrote: post #178

Earlier quoted context omitted.

You can just name the variable to explain what the number is, and if you need more info, there should be a "Why?" doc somewhere explaining the context generally, WITHOUT tying itself directly to the current choice (otherwise you'll have to update the "Why?" doc every time you update the number in the code, which is almost certain to go out of sync). No need to interweave documentation and code, in most cases. Sometim…

This would not work based on my experience What actually would happen is the next person comes along and changes the code and doesn’t update the external doc because it’s probably buried among 100 other pages on confluence and they don’t even know it exists If the comment is in the code they will see it and update accordingly

I think you missed what I said; there's no need to update the external doc just because you updated the value.

The external doc is an explanation of what the value does, and what happens when that value is updated, not why it's set to a specific value.

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

#192

Post by TameAntelope »

jonahx wrote: post #186
TameAntelope wrote: post #178

Earlier quoted context omitted.

You can just name the variable to explain what the number is, and if you need more info, there should be a "Why?" doc somewhere explaining the context generally, WITHOUT tying itself directly to the current choice (otherwise you'll have to update the "Why?" doc every time you update the number in the code, which is almost certain to go out of sync). No need to interweave documentation and code, in most cases. Sometim…

>No need to interweave documentation and code, in most cases. Locality is the reason, and it's a good reason. Of course, I don't want to see paragraphs of explanation inline, but a one-line comment giving context for some choice that might be confusing is much better and faster to work with than a separate WHY doc.

It's neither faster nor better, in practice.

It's not faster because you can just name the variable whatever it is the value represents, so by adding a second descriptor (the comment) you're introducing needless complexity.

It's not better because you really shouldn't be changing a value you don't understand the context around, which means reading much more than a one-line comment.

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

#193

Post by baskethead »

There's only 1 real answer to hiring.

Make sure the candidate's personality is a good fit for the team, have them do a fair coding question, and then hire them quickly. Give them 3 months to become productive and if not, fire them quickly and give a 3 month severance package.

You can probably analyze the data and figure out which of the employees are good at spotting good candidates and lean on them to make the decisions, but overall fast-hire-fast-fire is the best for everyone, except for fake candidates.

This also gives you the opportunity to take chances on borderline candidates or candidates with less experience.

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

#194

Post by dghlsakjg »

bluefirebrand wrote: post #179
beanaroo wrote: post #173

Earlier quoted context omitted.

Gitflow, and its various flavours, has been a popular alternative. Though it seems trunk-based is considered the preferred standard due to emphasis on achieving a stable main branch, simplified pipelines and faster cycle times. This requires a bit more maturity to get right if I'm not mistaken as you need good automation, test coverage and code review practices.

I've never heard of Gitflow or anything. I've been doing this stuff for almost a decade and trunk based with short lived development branches is all I've ever seen. Bizarre.

Funnily enough, I've never heard of trunk based, but the flow described is what I have heard called the 'github flow'.

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

#195

Post by ja27 »

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 did this. I had a folder with a few printed sheets of code hiding some slightly tricky C/C++ bugs from our codebase. I would ask the candidate to see if they could identify the issue. I don't think anyone ever actually got them but at least I got an idea of their thought process and experience. So mixed results.

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

#196

Post by hamburglar »

BFLpL0QNek wrote: post #150
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.

Skipping pr’s is not equal to skipping code review. If you pair, there’s two sets of eyes, to commit both pairs have to sign a commit. You can also organise a demo/quick mob session before commit. Then there’s a level of trust in your teammates. PR’s are great for open source projects as act as gatekeeper so not everyone can commit freely. If you need to gate keep your team members then I’d question the strength of y…

> If you need to gate keep your team members then I’d question the strength of your team.

Everyone is “gated” on a code review. The PR is one mechanism by which you can make code reviews easy. It says nothing about the strength of the team.

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

#197

Post by hamburglar »

TameAntelope wrote: post #192
jonahx wrote: post #186

Earlier quoted context omitted.

>No need to interweave documentation and code, in most cases. Locality is the reason, and it's a good reason. Of course, I don't want to see paragraphs of explanation inline, but a one-line comment giving context for some choice that might be confusing is much better and faster to work with than a separate WHY doc.

It's neither faster nor better, in practice. It's not faster because you can just name the variable whatever it is the value represents, so by adding a second descriptor (the comment) you're introducing needless complexity. It's not better because you really shouldn't be changing a value you don't understand the context around, which means reading much more than a one-line comment.

I think the GP is referring to the very common case where you can’t possibly say what needs to be said in a single variable name, but one or two lines of comments is sufficient.

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

#198

Post by rileyphone »

anyfoo wrote: post #166
BFLpL0QNek wrote: post #150

Earlier quoted context omitted.

Skipping pr’s is not equal to skipping code review. If you pair, there’s two sets of eyes, to commit both pairs have to sign a commit. You can also organise a demo/quick mob session before commit. Then there’s a level of trust in your teammates. PR’s are great for open source projects as act as gatekeeper so not everyone can commit freely. If you need to gate keep your team members then I’d question the strength of y…

I'm sorry, no, there's plenty of code that requires much more than two sets of eyes, and outside discussion, for any project above a certain size. I trust your experience that the teams and projects worked out like that, but they must have been suitable to that approach, which is definitely not universal. As one example, do you think cross-functional changes to the Linux kernel from even trusted contributors can just…

Sure there are a 1% of megaprojects that require additional process, but for the rest PRs are a method to control code quality socially. They introduce delays and foster ego antagonisms, so less methodical ways to control quality are optimal if the requirements are met (buy-in + skill) and complexity isn't too great.

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

#199

Post by viceroyalbean »

grog454 wrote: post #94
xtracto wrote: post #59

Earlier quoted context omitted.

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.

I do think there is some signal based on how well the developer can utilise existing structures without getting stuck in "all you have is a hammer". That said the tradeoff is mostly time-based so if it is a take home without constraints a lot of that signal is lost.

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

#200

Post by hamburglar »

TameAntelope wrote: post #191
arduinomancer wrote: post #190

Earlier quoted context omitted.

This would not work based on my experience What actually would happen is the next person comes along and changes the code and doesn’t update the external doc because it’s probably buried among 100 other pages on confluence and they don’t even know it exists If the comment is in the code they will see it and update accordingly

I think you missed what I said; there's no need to update the external doc just because you updated the value. The external doc is an explanation of what the value does , and what happens when that value is updated, not why it's set to a specific value.

That sounds wonderful in theory but it doesn’t seem realistic in general to have this doc explaining a particular constant and why/how it was chosen that doesn’t need updating if someone comes along and chooses a new value. I appreciate that you think you’ve discovered the answer here, but experience tells me it ain’t that simple.
Post reply on HN