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

461–470 of 565 posts

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

#461

Post by phone8675309 »

ChrisMarshallNY wrote: post #100

This makes a great deal of sense, to me. But I am also the type of developer that would do well at this (experienced and older). Young folks, right out of school, or with just a couple of years of experience, would not do as well. I’m pretty convinced that one of the goals of LeetCode tests is as a “young-pass filter.” It controls for people close to college age, where those types of problems are common, as well as p…

The company I work for is desperately hurting for older, more experienced developers. We use very mature tech (to put it charitably) - Java/Spring, Python/Django, C++ for OS interfacing parts - and we are having trouble filling roles for junior and senior software engineers.

Part of that is the company is insisting on going hybrid after the pandemic, so they filter out full remote candidates for long term positions.

To connect to the article, we have three questions in our interview that lasts an hour and a half - in one of which the candidate is given a small program with a bug and we see how they troubleshoot it - the idea is not to fix it, it's to see how they think.

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

#462

Post by padheyam »

I am a solo non-technical founder who hired and fired around 10 developers on a freelancer platform before finding the gem of a developer who single handedly completed the platform. Unfortunately, after a year he has left and now I'm struggling to find a replacement. The web app is still running fine, but further development is stalled. I'm wary of giving access to the entire codebase to the would be new hire. And I being a non technical person, have no idea how to give only partial access to my developer. Just rambling after reading the title. Sorry!

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

#463

Post by SonOfLilit »

padheyam wrote: post #462

I am a solo non-technical founder who hired and fired around 10 developers on a freelancer platform before finding the gem of a developer who single handedly completed the platform. Unfortunately, after a year he has left and now I'm struggling to find a replacement. The web app is still running fine, but further development is stalled. I'm wary of giving access to the entire codebase to the would be new hire. And I…

I'm a consultant and former technical founder with a lot of experience in helping non-technical people have control over their software projects. Feel free to contact me (username on gmail) to think about how to proceed in this situation.

Edit: obviously interviewing is one of the issues you're facing, but far from the main one. Trust is hard :)

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

#464

Post by hedora »

olliej wrote: post #209
rileyphone wrote: post #198

Earlier quoted context omitted.

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.

No, every project I have worked on has review gated commits. It is a /basic/ step in ensuring that a project maintains a high quality codebase. Review does cause delays, because reviewing takes time, but we've generally found that the speed "gained" through poor change control is more than made up for through bad code. Review also shouldn't be causing ego antagonisms. You're coworkers. You have to be able to work tog…

Have you ever worked on a new codebase?

I've found PR's become important approximately when feature momentum starts to drop.

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

#465

Post by hedora »

onion2k wrote: post #205
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…

The prs where dogmatic as more junior teams get caught up in superficial things such as names, package structure, syntax preferences rather than what the pr actually does. All this means is that you and your team failed to learn anything from the PR process. If simple things like naming or syntax repeatedly come up then you have a style convention but the devs are ignoring it. The very obvious solution to that is to…

Even better, identify actual problems you are actually encountering, and design a minimal process to solve those problems.

(Automating code quality stuff with linters is a no-brainer though.)

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

#467

Post by hedora »

olliej wrote: post #211
chrismcb wrote: post #156

Earlier quoted context omitted.

> demo/quick mob session Are you suggesting that a meeting to review cost is going to be faster than a code review? And any comments will be lost? And pair programming? No thanks. I think it you are doing actual code reviews, you are doing something wrong.

Code reviews are incredibly valuable, and are a crucial part of software development at all of tech companies. I would argue that if you aren't doing code review, then you're saying that you believe you and all your company's engineers are better than the engineers at Google, Apple, Mozilla, Microsoft, Oracle, ....

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 actual bar is "hire stronger engineers than the dregs from the giant shops".

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

#468

Post by hedora »

ozim wrote: post #214
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 would not use trunk based development as indicator of mature team. As you write there is much more to it and one can only see through it after joining company. For me trunk based development alone would be indicator that company is immature and does not even know they can have a process.

I view knowing when trunk based development does and does not make sense as an indicator of a mature team.

Thinking it always does or doesn't make sense just tells me you don't have experience working on diverse projects.

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

#469

Post by csmpltn »

buf wrote: post #456
BlargMcLarg wrote: post #444

Earlier quoted context omitted.

Entire post can be summed up as "this is my answer, here is me rationalizing correlation=causation without any empirical evidence". We could dissect the entire thing but really, if that is how it works for you, fine. Just don't push it onto others as the absolute truth. If this stuff was really so great, empirical research would've hammered it home decades ago. But it doesn't, and continues to struggle finding any me…

This isn't used widely because it is hard. But it's not but novel. 1. Companies want to standardize their hiring when really they should be looking to customize it to each candidate. 2. Lots of companies want to spread the blame of a bad hire across a committee of 4 or 5 people, but I think if you looked you'll find many startups doing it this way. They stop when they grow to a large size. They do it because frankly…

> "My evidence isn't that great I admit. I've only helped build 3 unicorns (helped found one of them) and started 3 $1M+ companies as a solo founder."

Again with the awkward appeal to authority.

Cut straight to it. Your post's title is "how to hire actually good engineers". So how many of those have you actually hired? How many of them stayed there 2 years into their roles? How do you know you've actually hired "good" engineers, and not just people you yourself thought were good enough at the time you interviewed and hired them? Have you actually followed up on your hires 3/6/12 months into their roles, to check that they're still as good as you thought they were?

By the way - "$1M+" sounds like a particularly low budget for "actually good engineers", ironically enough.

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

#470

Post by hamburglar »

TameAntelope wrote: post #294
hamburglar wrote: post #218

Earlier quoted context omitted.

I think I gave one example: if the doc includes the rationale for the value, it needs to be updated. But your more relevant experience tells you that’s wrong. I really don’t understand such aversion to a one or two line comment, but let’s just not work together in the future. ;)

I explicitly said not to write “why” docs to explain specific value choices, but rather document the context around the setting, and what happens when the value is raised or lowered, and why you might want to do that, so I’m thinking this isn’t a topic you’re grasping very well. You’ll be fairly lonely if you reject working with everyone who’s read Clean Code, and truly alone if you won’t work with anyone who underst…

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.

Post reply on HN