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

551–560 of 565 posts

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

#551

Post by damethos »

jahnu wrote: post #416
buf wrote: post #382

Earlier quoted context omitted.

Hi, comment OP here. I decided to blog about this. It's cheeky, apologies. https://siliconvict.com/articles/6-how-to-hire-actually-good...

No worries at all :) > Sorry to be blunt, but chances are they aren't very good, and they are definitely not as good as they think they are. I don’t know what to tell you. It’s just so wrong it’s kinda wild how sure you are about this. At least half of the excellent colleagues I worked with in the past 10 years don’t fit your criteria. You’d be lucky to hire any of them.

I felt exactly the same when I read this. Plenty of people who are very good engineers have nothing in public to show.

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

#552

Post by mountainriver »

jahnu wrote: post #270
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…

Surely this will filter out ~50% of people who are good but don’t have any public code? I have a family and as such no free time for coding so I haven’t written any code I can legally show anyone else in more than a decade. But everyone who has employed me is more than happy with my work. Not to mention code is only half of why you would want to employ any developer.

Yeah we do this but also give people an option of either a take home test or live challenge. It works really well and fits all developer types.

At the end of the day all your after is signal on how well they understand software. There are lots of ways of doing that

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

#553

Post by hamburglar »

TameAntelope wrote: post #511
hamburglar wrote: post #470

Earlier quoted context omitted.

And I explicitly said sometimes you want to write about the rationale. I didn’t actually realize you were attempting to dictate that that wasn’t allowed. That seems pretty nuts. And I think people who read Clean Code and aren’t dogmatic and condescending about trivial choices like this are pretty fine.

What you want and what is the best way to communicate are not always aligned. And I'm not dictating anything, or being dogmatic and condescending, but I guess it's easier to think I am if you're trying to have an Internet Argument Moment.

> I'm not dictating anything, or being dogmatic

You literally dictated that explanatory code docs shouldn’t talk about rationale for constants. And your evidence for this is that apparently Clean Code says so.

> condescending

Well you can claim not to be condescending all you want but that’s how I interpreted your explanation that the only reason I disagree is that you “understand it better,” and I’d imagine that’s how most people would read it.

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

#554

Post by hedora »

olliej wrote: post #543
hedora wrote: post #467

Earlier quoted context omitted.

Having engineers better than the average employee at those companies is a lower bar than you'd imagine. Smaller companies can pay much more (in expectation), and can simply poach the cream of the crop (who are invariably frustrated by useless process and corporate politics) from the big ones. On top of that, most development processes are designed to minimize the blast radius of underperforming engineers, so your act…

No, it isn't. I know the standard of engineers at FAANGs. Having engineers better than the competent engineers that are responsible for the dreaded process at the FAANGs, MS, etc is hard. The review policies of big projects tend to have been hard learned, and dismissing them because "they're useless process" is a poor choice.

I'm speaking based on the experience of dozens of engineers, including ones from all of MFAANG, and a half dozen almost-FAANGs.

I think you're conflating whether a process is useful for the organization with whether it is useful for the engineers implementing it. Since processes have to be uniform, you need to either figure out how to retain someone that's been at the company for a decade to continue to work maintenance jobs, or you need to figure out how to keep the fresh grads that will replace them from breaking the world.

The right choice for the organization is to keep production stable, and the bus factor high.

The right choice for the engineer is to demand massive comp increases (comparable to startup acquisition windfalls), and also the abilty to stop working maintenance.

A lot of the best engineers I've worked with used to be in a FAANG. Almost none of them would consider going back. They universally cite broken processes as the reason they left.

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

#555

Post by Riverheart »

mstipetic wrote: post #502
Riverheart wrote: post #485

Earlier quoted context omitted.

Or they don't have the time or manpower to fix/learn things and are trying their best to hire someone to help right the ship before bringing you onboard. Such a negative take.

Which engineer that is that good would spend years of his time improving a low performing team?

One who needs a good, steady paycheck at a stable company? Just because hiring team doesn't have time to learn/apply a specific piece tech on the job doesn't mean they're low performers or less competent than the interviewee. They can be sufficiently busy with their current jobs and need someone experienced to lay the groundwork for others to run with. People that go and implement stuff when they're already busy usually half arse it. Those people are just creating issues that'll be fully realized months, years later.

If you say you know tech X, manager wants to hire for tech X to solve a business need, and I'm asked to help interview, I may ask you questions about things I don't know or do myself because it's my professional responsibility to my employer and manager to help them hire a quality candidate. Maybe some people use the interview as a place to be jerks or show off but that's not always true. Personally I'd rather not be involved in the process at all.

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

#556

Post by bgro »

But wait, how is this fair to the millions of software engineers that can only pass interviews by memorizing the question? Isn't that the whole point? To gatekeep people with other learning styles and fast track people who arguably cheated on tests throughout school?

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

#557

Post by NateEag »

ithkuil wrote: post #548
rectang wrote: post #473

Earlier quoted context omitted.

I use the same workflow as NateEag and mdavidn. My preference is: • All commits SHOULD pass all CI tests • Merge commits MUST pass all CI tests The reason I don't require every commit to pass all tests is to maximize reviewability and logical consistency of commits. For example, if a file needs to move, and then be modified slightly to function in its new location, I prefer to break that into two commits: 1. A verbat…

Do you enforce the presence of merge commits, i.e. no-ff?

If I'm enforcing any of this, then I enforce that, yes.

All of these constraints can be enforced programmatically, and if you're going to adopt them at all I think automating them is the way to do it.

Personally, whether I enforce this branching strategy varies from team to team and project to project.

Many projects I've been on had much, much bigger issues to deal with, so something second-order like this never gets to the top of the stack.

That said, it's an approach I like, and I think it yields benefits if you have a team that's bought into it.

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

#558

Post by hnfong »

leaflets2 wrote: post #517
hnfong wrote: post #304

Earlier quoted context omitted.

The point is not necessarily whether it's morally wrong to violate a contractual agreement when the other party is likely to do so. It's that the interview process proposed by the G[...]P may force the candidate to do things that may be illegal to pass the interview. The candidate is of course responsible for their own choices, but the point is that as an interviewer, if you force your candidates to do this, you migh…

> you might short list those who have a tendency to violate contract terms. An asshole filter https://siderea.dreamwidth.org/1209794.html (maybe you've read already?)

I'm familiar with the general concept but never read that specific article. Fun reading though, thanks!

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

#559

Post by akhmatova »

devoutsalsa wrote: post #101
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 took a job once because they were honest about the fact that the code was a complete shit show, and that’d I’d have to clean it up. I’m sure this is naive on some level, but I’d say you don’t have to lie to people. Just help them imagine doing the job and let them decide if that’s how they want to spend their time.

I’m sure this is naive on some level, but I’d say you don’t have to lie to people.

Sounds perfectly sensible, and not naive at all.

I'd much rather come into a situation where they were both already aware of, and entirely honest about the current shit-show status of the project -- than a situation where everyone thinks what they're doing is great and bleeding edge but when you actually take a good look at their assets, as it were... not only are they manifestly and visibly unwashed -- but no one seems to notice the stink.

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

#560

Post by akhmatova »

whatshisface wrote: post #103
devoutsalsa wrote: post #101

Earlier quoted context omitted.

I took a job once because they were honest about the fact that the code was a complete shit show, and that’d I’d have to clean it up. I’m sure this is naive on some level, but I’d say you don’t have to lie to people. Just help them imagine doing the job and let them decide if that’s how they want to spend their time.

Bad code + time allowed to clean it up = perfectly well-defined business requirements + a license to think about code craftsmanship. That's a lot of people's dream job.

Not sure if it's my "dream job".

But yeah, when you think about -- a sufficiently fecal-encrusted, lost-cause codebase is almost indistinguishable from an actual greenfield opportunity.

Post reply on HN