When hiring developers, have the candidate read existing code • Hacker News Board

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

#171

Post by twblalock » Sat, Apr 16, 2022, 4:07 AM UTC

EMM_386 wrote: post #112

Please comment your code, when it is is necessary. I don't need "we need to loop here from 1 to 50", I need "we have to rate-limit this function to under 60 transactions per second due to hardware requirements", etc. If you are putting "magic numbers" anywhere, COMMENT it as to what that number is, why you chose it, etc. I'm 30 years into this game and I still come across code that takes way too long to reason about.

Don't do it unless you are going to treat keeping comments up to date the same way you treat keeping the code up to date.

I've lost count of the number of times I've seen comments that were just wrong -- they applied to the code as it was written years ago, not today.

Write good code, and it should be obvious how it works. Use comments sparingly and only when things are not obvious. Update the comments when you change the code, and make sure your code review process doesn't let outdated comments slip by.

If you can't commit to the above policies, then don't comment your code at all.

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

#172

Post by jgauth » Sat, Apr 16, 2022, 4:10 AM UTC

bkuehl wrote: post #144

EMM_386 wrote: post #112

Please comment your code, when it is is necessary. I don't need "we need to loop here from 1 to 50", I need "we have to rate-limit this function to under 60 transactions per second due to hardware requirements", etc. If you are putting "magic numbers" anywhere, COMMENT it as to what that number is, why you chose it, etc. I'm 30 years into this game and I still come across code that takes way too long to reason about.

Agree completely. Also, good commenting skills take years to master.

> good commenting skills take years to master

As a newer developer, it’s nice to hear you say that. I often find that I spend more time deliberating over comment wording and variable names than I spend writing the code itself!

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

#173

Post by beanaroo » Sat, Apr 16, 2022, 4:11 AM UTC

bluefirebrand wrote: post #160

csmiller wrote: post #75

Earlier quoted context omitted.

https://trunkbaseddevelopment.com/

Okay now I'm wondering what the alternative is, because this just looks like "development" to me.

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.

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

#174

Post by Yhippa » Sat, Apr 16, 2022, 4:13 AM UTC

beebmam wrote: post #125

bluefirebrand wrote: post #70

Earlier quoted context omitted.

> Bonus points for no PR’s and trunk driven development as that shows a very mature team. I'm not sure what Trunk Driven Development is, could you elaborate?

Virtually all game companies use Trunk Based Development, in my experience, including many very large studios. (Outside of game engine development, which isn't really done by game studios anymore with a few exceptions)

Interesting, I wonder if that's why you see insane build numbers like 1.2.4045.26836?

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

#175

Post by dasil003 » Sat, Apr 16, 2022, 4:20 AM UTC

dilyevsky wrote: post #149

dasil003 wrote: post #123

Earlier quoted context omitted.

Hard disagree on this. Large companies can't afford false negatives because false negatives can hide out and move from team to team without detection. At a small company if the same thing happens it means leadership is incompetent and you have bigger problems anyway.

Large companies can and often do afford sizeable percentage of workforce making zero to negative contributions. This would be devastating for a small team with a finite runway

Indeed! But it's generally much harder to reach consensus and actually remove someone at large companies. Especially for a startup with limited runway it's existential, whereas at a large company there is far more to lose from a lawsuit than from eating a high salary as a net negative.

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

#176

Post by enraged_camel » Sat, Apr 16, 2022, 4:23 AM UTC

twblalock wrote: post #171

EMM_386 wrote: post #112

Please comment your code, when it is is necessary. I don't need "we need to loop here from 1 to 50", I need "we have to rate-limit this function to under 60 transactions per second due to hardware requirements", etc. If you are putting "magic numbers" anywhere, COMMENT it as to what that number is, why you chose it, etc. I'm 30 years into this game and I still come across code that takes way too long to reason about.

Don't do it unless you are going to treat keeping comments up to date the same way you treat keeping the code up to date. I've lost count of the number of times I've seen comments that were just wrong -- they applied to the code as it was written years ago, not today. Write good code, and it should be obvious how it works. Use comments sparingly and only when things are not obvious. Update the comments when you chang…

>> Don't do it unless you are going to treat keeping comments up to date the same way you treat keeping the code up to date.

This should be easy enough to verify during code review, no?

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

#177

Post by rpmisms » Sat, Apr 16, 2022, 4:23 AM UTC

I would like this. I'm a lowly front-ender with some engineering chops working towards a full-stack/backend role, and this would help me convey my knowledge better than getting brain freeze when trying to remember syntax in a language I might not be great in.

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

#178

Post by TameAntelope » Sat, Apr 16, 2022, 4:28 AM UTC

EMM_386 wrote: post #112

Please comment your code, when it is is necessary. I don't need "we need to loop here from 1 to 50", I need "we have to rate-limit this function to under 60 transactions per second due to hardware requirements", etc. If you are putting "magic numbers" anywhere, COMMENT it as to what that number is, why you chose it, etc. I'm 30 years into this game and I still come across code that takes way too long to reason about.

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. Sometimes, when we fail to write good code, sure. But let's try to write good code!

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

#179

Post by bluefirebrand » Sat, Apr 16, 2022, 4:28 AM UTC

beanaroo wrote: post #173

bluefirebrand wrote: post #160

Earlier quoted context omitted.

Okay now I'm wondering what the alternative is, because this just looks like "development" to me.

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.

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

#180

Post by MichaelMoser123 » Sat, Apr 16, 2022, 4:29 AM UTC

I saw that back in the nineties: my employee had an interviewing task where you had to look at a c++ listing with obvious errors, the task was to find the errors, like memory leaks, buffer overruns, use of stack allocated memory, etc. Actually few candidates would pass this test...

I don't think they will do this: the interviewing process at most places seems to emulate that of the industry leader, nowadays that's google, correct me if I am wrong.