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

391–400 of 565 posts

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

#391

Post by weatherlite »

ChrisMarshallNY wrote: post #330
weatherlite wrote: post #285

Earlier quoted context omitted.

I get your point but its not like recent grads have it super easy getting their first job; you have decades of experience interviewing (part of which is Leetcode which you have probably done many times); for them it's probably the first time doing this. On top of it all many places don't want juniors at all.

Actually, I never took coding tests, until a few years ago, when I was looking for work, at age 55. I quickly learned, that if I saw a binary tree test, I might as well give up. Even if I did OK, the company was not going to give me a chance. What I do have, is a ginormous portfolio, with dozens of repos full of ultra-high-Quality code, for shipping products, and over a decade of checkin history, along with hundreds…

Hey I hear you, I'm not gonna gaslight your experience, let met just say this:

1) Getting a job that pays well isn't that easy in most fields

2) Getting a job as a software dev in FAANG or somewhere else desirable to many devs is plain difficult; you are competing against dozens and sometimes hundreds of candidates, some of whom are pretty good. There is no real "dev shortage" for these companies, if anything there's a huge inflation of devs who are qualified and want to work for them.

3) The tech interview process sucks and almost everyone acknowledges this and hates it; just 2 days ago I was asked a riddle about how to measure 45 minutes when burning ropes that take 60 minutes to burn. That was freaking half the interview, the other half was a difficult array question. Looking at the solution now there's no way I could come up with it even on a good day. And the company was a run of the mill company most people haven't even heard of, not exactly a FAANG. I was interviewing for a team with a pretty esoteric tech stack which I am super qualified for - but alas I get stressed when confronted with boys scouts riddles in a high pressure situation - so I must not be worthy of the job.

What I'm saying is - I think we all suffer in this together, it might be a bit better for recent grads but not by much. In the next downturn you will have dozens of people who know you well and will recommend you and help you get a job - a recent grad has nothing and will be the first to be let go since most of them can't really produce much yet. I'd take being 50 something with 2 decade worth of experience and connections than being a recent grad now.

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

#392

Post by Nursie »

dhzhzjsbevs wrote: post #255
olliej wrote: post #209

Earlier quoted context omitted.

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…

People seem to have forgotten what code was like back in the bad old days. Fuck that dogpile of bullshit. You've never seen a 1200 line diy function to parse XML have you?

I apologise if I left you with that one when I left my first job in 2003!

:)

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

#393

Post by chucksmash »

mstipetic wrote: post #261
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’ve never understood this. I’ve had Teams grill me on questions I know most of them wouldn’t pass and they themselves said they’re struggling with delivering things. Some weird dick measuring thing

It could be that, but it doesn't have to be.

If you're on a team that isn't currently having staffing issues, I don't think it's weird to want your next hire to be better than the median person on the team. "Raise the bar," etc. Asking harder leetcode questions seems like a bad way to achieve it, but I get the impulse. If the bar for member nine of the team is approximately "better than the bottom 4" then that 9th person in is likely to have at least one moment of "wait, how did you pass that interview?" at some point after they come on.

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

#394

Post by woldenron »

whitesilhouette wrote: post #360

I do almost the same but a bit differently. Like a lot of people have suggested here that they can't share their company's proprietary code (neither can I). So I have cooked up some sample questions asking people to code for a app involving REST and CRUD (because that's resturant what we do at office). It's not much work and can be done in 2-3 hours. Then I get down to discuss their answers and the 'why' questions ar…

> 2-3 hours

You pay for that wasted time, yes?

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

#395

Post by lucb1e »

andrewflnr wrote: post #316
lucb1e wrote: post #51

Earlier quoted context omitted.

> 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™".

TIL of "Gang of Four". I first thought you meant Goblet of Fire and that there was a harry potter reference in compsci that I had yet to learn :(

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

#396

Post by NateEag »

someweirdperson wrote: post #286
wildpeaks wrote: post #206

Earlier quoted context omitted.

I agree, the PR is invaluable to preserve context: the trunk history remains simple and linear thanks to squash merges, and you can still see the fine grained commits (and matching discussions/reviews) in the closed PR. It's also a way to give insight when onboarding new developers: if something is surprising, they can see why things came to be this way, not just accept the result at face value.

Explanations should end up in comments, documents, and the commit-comment of the squash (creating a good one takes some time when squashing). The PR and original branch show dead-ends that should not be required reading to understand things.

I'm personally a fan of small, clean commits, rebasing without squashing before merge, always making a merge commit, and writing a clear, through merge commit explaining what the branch does.

That way, I can treat the series of merge commits to trunk as the simple, linear overview of history, but when I'm bug-hunting I get small, clear commits to search through with git bisect.

It also means I get more useful blame output, as instead of huge hunks of a file being all from one giant bomb commit, I can see the process and evolution that the whole change went through as the original author pieced it together. That can be really helpful when dealing with obscure bugs or understanding systems with little documentation, by helping you get back more of the original author's thought process and seeing how their mental model evolved as they built the feature.

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

#397

Post by sethammons »

jseban wrote: post #313
actually_a_dog wrote: post #306

Earlier quoted context omitted.

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".

In over a decade of enforced code review experience, I've had one developer who was too immature to take feedback. Some folks take it personally and they shouldn't as long as the feedback is about the code. This requires some work on both reviewer and reviewee.

The guy who couldn't take feedback (person A) had code merged in that wasn't properly tested. Person B said, "hey A. I could use some help. We wrote some tests around $feature that were missing and the tests show the feature doesn't work. We see $unexpected results. Wanna make sure we agree on how this should work."

Person A: no, it works, I tested it.

B: could you help us identify the flaw in the tests then - they seem rock solid.

A: no, my code works.

B: ... ok, can you join us and talk through it?

A: no, it works.

A was removed from the team after management came in and A continued to not acknowledge his code could be wrong.

This was aberrational. We, as an org and as a team, constantly strove to keep the focus on the quality of the code. And, yes, his code was borked.

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

#398

Post by kibwen »

doix wrote: post #368
boomlinde wrote: post #289

Earlier quoted context omitted.

Where I work, development is trunk based and without pull requests, and all code is reviewed. When I want to submit code, I push it to a staging area that tracks master. This causes the commits to appear in Gerrit where (conflict-free) rebasing can be performed with a single button and the code can be reviewed. During the staging I can change anything about the commits to my hearts content. Once everyone is satisfied…

What you are describing, is pretty much exactly how it works at every company I've worked at that used PRs. You create a new branch from master, make your changes, push the branch to github/bitbucket/gitlab, make a PR. While the PR is open, you can make any changes you want to the commits in that branch (since it's just a branch). People look at the PR (which shows the diff) and approve it if they are happy, or reque…

> I presume everyone here is talking about creating branches in the main repo and requesting review before merging the branch to master.

Regardless of whether someone is pushing to a branch in the upstream repo or pushing to a branch in a fork, the workflow is the same either way. At worst, it just means adding a remote if you want to check out someone's code locally.

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

#399

Post by NateEag »

aaronbrethorst wrote: post #250
jseban wrote: post #240

Earlier quoted context omitted.

> PR’s are great for open source projects as act as gatekeeper so not everyone can commit freely Yeah exactly, PR's are based on the fact that you have some person who is the owner that have complete power, and many other contributors who have zero power and whose contributions will mostly be rejected. You simply don't have that situation in a company, where everyone is an owner on equal terms, and all contributions…

I’m not sure why people are downvoting your lived experience. I’ll just say one thing: quit. Right now. This is a BAD environment.

He's getting downvotes because he's persistently overgeneralizing from his unfortunate, legitimate lived experience to a bunch of dogmatic claims about the fundamental nature of the pull requests that contradict many other people's own lived experience.

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

#400

Post by dahfizz »

woldenron wrote: post #394
whitesilhouette wrote: post #360

I do almost the same but a bit differently. Like a lot of people have suggested here that they can't share their company's proprietary code (neither can I). So I have cooked up some sample questions asking people to code for a app involving REST and CRUD (because that's resturant what we do at office). It's not much work and can be done in 2-3 hours. Then I get down to discuss their answers and the 'why' questions ar…

> 2-3 hours You pay for that wasted time, yes?

Do you also demand payment when you have to stand in line at the grocery store?
Post reply on HN