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

261–270 of 565 posts

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

#261

Post by mstipetic »

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

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

#263

Post by lastdong »

jseban wrote: post #240
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…

> 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 sorry you had such bad experience but you were working with the wrong people (feels like toxic even). PR reviews work best in environment where trust is key, and deciding together (emphasis on together) best approach to reach a goal is the main drive. In the end PRs should make you and the team stronger, as the knowledge is shared collectively.

IMO every developer should be an admin of the repo, but more importantly it’s not a gate, it’s a process that benefits communication. All the team can read and learn from small addings to the code base.

PR reviews should not equate to 100 comments either, complex discussions can (should imo) be worked out in a call discussing (dialog) best approach. Think of white boarding a problem with a fellow engineer friend.

Ofc, teams differ and some teams work better with other processes and other tools.

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

#264

Post by jseban »

heurisko wrote: post #251
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…

> 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 PRs can be approved based on two people's opinion. There doesn't need to be a central gatekeeper. > So you get these really weird situations where more junior, or less skilled, people can block PR's and demand ch…

> Sometimes junior, or less skilled people, have something valuable to say. Especially if the code could be simpler.

Yeah and sometimes they are naive, dogmatic and overconfident, and on a crusade to change all the things! because they have read some blog post by uncle bob, and this tool is putting them in absolute power every time they do a review.

> In a stalemate, the PR could be sent to a third party. I've suggested this many times to avoid unnecessary conflict.

Ok and who might this lucky scapegoat be? I have a feeling it's not the manager for some reason..

> I don't think it is PRs that are the issue, rather your working environment.

The issue, which I'm trying to illustrate, is that the tool makes the working environment worse by introducing (hostile) dynamics between people that don't exist, which leads you into situations that you don't have resolutions for, situations that should not occur.

Using a tool that allows you to block other people's work causes unnecessary conflict in a team where people are supposed to be working together.

Edit: blocking contributions is a normal and natural thing in an open source workflow, and it is not normal and natural in a team inside a company.

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

#265

Post by lytefm »

michaelrhansen wrote: post #25

This is my standard practice - I give a real world data fix script that has been simplified to understand and comment on in 20 minutes. The interviewee is the code reviewer before it gets run in production. It covers things like performance, security, typical syntax mistakes, and working with sensitive data. The best part is actually not the script, but the stories it triggers about past challenges.

> The interviewee is the code reviewer before it gets run in production.

Yeah I've also been using this approach for Fullstack Devd: A small page with a bit of CRUD + a small ticket description of what the page is supposed to do.

The code contains various bugs or questionable implementations, the interviewee is supposed to analyze the code and to either fix the issues right away or to write comments.

Nobody is expected to get everything right within the time slot, but I've found it to be a great test on how a candidate might perform in their day to day work.

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

#266

Post by jseban »

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.

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

I agree, also sounds like an unusually well defined role with a clear way of having impact. I would also take this job any day over another job that would bait and switch me into some rewrite death march.

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

#267

Post by [deleted] »

deepsun wrote: post #254
buf wrote: post #238

Earlier quoted context omitted.

I've never been put in the situation where an engineer shared something alarming from a proprietary code base, but hypothetically if someone brought with them the code for how to hack superuser privs for an old company, that would be an ethics violation and I would pass.

Well it does not matter if it's alarming or not. They are in violation of their signed NDAs with their previous employer. Also, if they don't work there anymore, they should've deleted all the code (if they had it) and surrendered/cleared up all the laptops. But I like your idea, anyway I give big kudos to candidates with their own pet projects.

[deleted]

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

#268

Post by jseban »

lastdong wrote: post #263
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 sorry you had such bad experience but you were working with the wrong people (feels like toxic even). PR reviews work best in environment where trust is key, and deciding together (emphasis on together) best approach to reach a goal is the main drive. In the end PRs should make you and the team stronger, as the knowledge is shared collectively. IMO every developer should be an admin of the repo, but more importan…

> I’m sorry you had such bad experience but you were working with the wrong people (feels like toxic even).

It's the tool itself and it's imposed workflow of blocking work and gaining absolute power in demanding changes, that causes the working environment to become toxic. Nobody would ever do that in a meeting "I'm blocking this work now until my demands have been met". That would be incredibly hostile, but with this tool it becomes normal.

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

#269

Post by vippy »

lizardactivist wrote: post #247

Related to this, is solving programming-trivia on white-board with a clock ticking and someone watching over your shoulder still a thing? I think that's leaning to interrogation, and less of interviewing.

No post body was provided.

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

#270

Post by jahnu »

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.

Post reply on HN