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

311–320 of 565 posts

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

#311

Post by andrewflnr »

GuB-42 wrote: post #107
andrewflnr wrote: post #37

My thesis is that the true measure of reading code is still the ability to fix and extend it. So my current ideal interview problem is still a tiny toy codebase, where the interviewee is tasked with adding some (relatively trivial) feature to it. Like ten lines of code, but where those lines require you to have grokked the other couple hundred or so. Any downsides?

By doing that you will be selecting for the "cracker" type. That is people who are able to get into any code, even under adversity, and do anything they want. It is a great skill to have even if you job doesn't involve removing copy protection, for example, he may be the only person who will be able to fix a bug in that old code base written in an obscure language when the last person to work on it left the company 1…

Uh, no. The skill here is one used by literally any programmer who starts work on a project they didn't start. Not that there's zero overlap, but come on.

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

#313

Post by jseban »

actually_a_dog wrote: post #306
jseban wrote: post #301

Earlier quoted context omitted.

I'm not criticising the review itself as much as rather the PR workflow and the tools of github, especially the blocking mechanism. It's my opinion that collaboration should happen much sooner rather than being pushed to the end with the review of a PR, and that you should have designated people who have the power to sign something off as production ready. If a team inside a company want to gather inspiration from th…

There is nothing about github hat prevents you from working that way. I don't see what your issue is. But, I will say that I don't want people who can't separate criticism of their code from criticism of themselves on my team. You can certainly have whatever feelings you want, as long as it doesn't get in the way of producing the best possible product, all things considered.

> I don't want people who can't separate criticism of their code from criticism of themselves

Yeah good luck with that, nobody can completely separate criticism of their work from criticism of themselves. You are making your job as the team leader way to easy for yourself, "I only hire robots, that's how I solve all these pesky people issues".

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

#314

Post by caffeine »

buf wrote: post #224

I've interviewed maybe 500 engineers in my career. I'm an early engineer of Instacart, 3rd engineer of Eventbrite, founding engineer of Reforge. Started 3 companies myself. My interview is always the same: 1. Bring code you've written 2. Share your screen 3. Explain what it does and I will casually ask questions about it You get so much information from this: - How they think about code - If they think it could be be…

I think this is a great interview. I do something similar.

I’ve done most of my interviewing in finance where:

1. The engineers are mostly really good

2. They almost never have side projects, and everything they have ever done is super secret and proprietary.

For this it makes sense to ask people to do a take-home, and then ask them questions about it when they come in.

I usually also ask them to add a simple feature to their code and just silently watch them code it. You learn a lot from watching how someone breaks down a simple problem, especially where they are expert (ie they are working in their own codebase).

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

#315

Post by Izkata »

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?

Trunk-based development, as I've seen it explained in the past, isn't what that site describes. The way I understood it is, no branches at all, everything committed straight to trunk, and extensive use of feature flags to keep incomplete features hidden.

Short-lived branches like that site's describing just sounds like a team that's adopted git pretty well, but not formalized usage into gitflow or similar...

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

#316

Post by andrewflnr »

lucb1e wrote: post #51
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.

> fit into the broader design style of the surrounding code[, including] the structural patterns. That might require one to be familiar with those ahead of time. If that's what you're hiring for, that's perfect of course, but I personally haven't had much experience with design patterns outside of a few C# ones in school five years ago. Yet I see myself as a competent amateur programmer (and C# isn't even my strong s…

I read the "patterns" part as idioms of the codebase, e.g. what a route handler looks like if this is an HTTP server, or the standard way to make an entity in a game. I think that's one of the more critical parts of the test. Certainly not GoF style "Design Patterns™".

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

#317

Post by comprev »

wingerlang wrote: post #279
irrational wrote: post #276

Earlier quoted context omitted.

How are they sharing their code? At my company things are locked down so tightly that I can’t move code off of company computers. I would have to look at the code on one computer and type it into a computer of my own. Unless people are doing interviews on their company computer or the company is careless with their code, I’m not sure how someone would even share their work code.

Not sure how locked your computer is but everywhere I've ever worked, it's been trivial. Email the source file, zip it and upload somewhere, pastebin temporary, airdrop it, usb sticks.

My client is in the financial industry and have to use their equipment as a remote contractor.

The win10 laptop is locked down tight, including removable drives disabled, DNS forced through corporate servers, SSH blocked outside network, etc. I wouldn't be surprised if all activity was somehow centrally logged for compliance too.

I had to request permission to whitelist my VPN account to access Github.com. Even with VPN disabled the laptop still uses corporate DNS.

The security policy is designed to prevent theft.

Of course there _are_ ways to circumvent these protections but you'd be in a world of legal trouble if caught.

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

#318

Post by stephen_g »

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.

Yeah, it was pretty popular for a while but I doubt many people really do it because of it’s shortcomings. I guess if you spent most of your time in feature freezes trying to stabilise the upcoming release of your product, but I’ve often felt it’s better to either just have a few feature branches queued ready to merge once the master branch is tagged and released, or to branch master into a release branch once you have a feature freeze and only commit bug fixes to that. But then you have the annoyance of having to cherry-pick features between the branches.

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

#319

Post by andrewflnr »

dasil003 wrote: post #123
mhh__ wrote: post #50

Earlier quoted context omitted.

arguably worse for smaller companies. if you hire the wrong person you can't even try and move them somewhere better suited to them

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.

At the risk of over-explaining (hopefully) obvious satire, I'm considering a "false positive" to be someone who was hired who should not have been, i.e. the hiring process gave a positive result that was wrong.

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

#320

Post by swinglock »

wingerlang wrote: post #279
irrational wrote: post #276

Earlier quoted context omitted.

How are they sharing their code? At my company things are locked down so tightly that I can’t move code off of company computers. I would have to look at the code on one computer and type it into a computer of my own. Unless people are doing interviews on their company computer or the company is careless with their code, I’m not sure how someone would even share their work code.

Not sure how locked your computer is but everywhere I've ever worked, it's been trivial. Email the source file, zip it and upload somewhere, pastebin temporary, airdrop it, usb sticks.

You would do that? Now I'm beginning to consider if I should be asking candidates to bring some intellectual property owned by their current/previous employer as a filter.
Post reply on HN