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

161–170 of 565 posts

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

#161

Post by bredren »

bluefirebrand wrote: post #70
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…

> Bonus points for no PR’s and trunk driven development as that shows a very mature team. I'm not sure what Trunk Driven Development is, could you elaborate?

Do you follow a style of git behavior now? I transitioned from purely git flow projects to most of my time on a trunk-based team this year.

Pretty striking difference.

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

#163

Post by spike021 »

EMM_386 wrote: post #112

Please comment your code, when it is is necessary. I don't need "we need to loop here from 1 to 50", I need "we have to rate-limit this function to under 60 transactions per second due to hardware requirements", etc. If you are putting "magic numbers" anywhere, COMMENT it as to what that number is, why you chose it, etc. I'm 30 years into this game and I still come across code that takes way too long to reason about.

100% agreed.

A trend I've noticed the past couple years is that people make the excuse of "code should be self-documenting" so they don't need to add comments. But then very helpful contextual hints that are not otherwise documented anywhere, like the one you provided, are completely non-existent and the original dev has left the team, it's been 2-3 or more years since the last time someone touched it, etc.

Code should be self-documenting, don't get me wrong. But that's more in the vein of showing (what), not telling (why/how). There still needs some be some method of telling.

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

#164

Post by travisgriggs »

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…

> Not sure that many companies, these days, are actually interested in older, more experienced, developers.

I’m beginning to appreciate the value of cohorts as I age. I work in a ver successful triad, ages 51, 58, 61. We recently tried to integrate a young-30s in our group. It did not go well. They recently moved from our team and are working elsewhere with a group of people closer to same skill, aptitudes, and age. Both they and we are much happier this way. It’s a small sample set obviously. I value a diverse world where we tolerate and learn from each other. But years of working experience have made me wonder if we shouldn’t just let age/skill cohorts naturally work together.

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

#165

Post by fma »

jasoneckert wrote: post #56

Of course, if a developer comes with experience and personal references from acquaintances, you don't need to test their abilities at all during the interview process. For example, I hired a backend developer last month. She already had the job because she came highly recommended from a trusted friend of mine, but she didn't know that. Here's how the interview went down: Me: I see on your resume that you've achieved…

Same here...except I tell up front when they apply that it's more of a formality for HR. I respect their time and don't want them to waste time preparing or getting nervous. I tell them it's mostly for the team to get to know them and for them to evaluate the team and we'll keep the interview light.

I still give my team the option to decline them if there's major red flags - but I have not had that happen.

Also, a reminder...an interview it is a 2 way street. Your 1 question interview doesn't give the candidate an opportunity to interview you or your team and the "Welcome to the team" is a little presumptuous...I assume it was left out for dramatic effect and I'm sure (I hope?) you allowed the interviewee time to ask questions.

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

#166

Post by anyfoo »

BFLpL0QNek wrote: post #150
zdragnar wrote: post #119

Earlier quoted context omitted.

> Bonus points for no PR’s and trunk driven development as that shows a very mature team. Ugh, pass. Trunk development is fine. Skipping PRs just brings back nightmares of SVN. Even if 90% of PRs are approved without comment, it's extremely helpful for everyone to have a second set of eyes on work before it is merged in.

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'm sorry, no, there's plenty of code that requires much more than two sets of eyes, and outside discussion, for any project above a certain size. I trust your experience that the teams and projects worked out like that, but they must have been suitable to that approach, which is definitely not universal.

As one example, do you think cross-functional changes to the Linux kernel from even trusted contributors can just be merged without review and feedback from people across all affected subparts of the kernel, as long as they have been written through pair programming? That's a big open source example, but plenty of companies have plenty of projects for which that already applies as well.

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

That is an easy trap to fall into (and wildly annoying), but it does not mean that PRs have no use outside of that.

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

#167

Post by rzimmerman »

I have found a lot of value from putting up real code from our code base (maybe simplified with some parts removed) and asking the candidate to explain what a function does. It’s very fair, low stress, and you can ask open-ended questions about “why this way?” or “what are some other ways to do this?”

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

#168

Post by [deleted] »

macintux wrote: post #126
gaoshan wrote: post #85

Earlier quoted context omitted.

1 hour. The initial bug takes most people about 5 minutes or less (the console error practically tells you what to do if you actually read it)

The number of technicians who freeze when they see an error message is really discouraging.

[deleted]

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

#169

Post by a_square_peg »

sgustard wrote: post #130
a_square_peg wrote: post #88

Would really like to see one day a post about 'when hiring developers, read their CV and have a technical discussion about their past work in relation to the role required' becoming a thing.

I do that extensively when hiring and it is valuable. But sadly, many people can hold a technical discussion without actually being able to read/write code. I'd like my orchestra to have a lively discussion of music theory, but I still need to hear them play the violin.

I agree it's not a straightforward thing - it's just that in many cases people seem to be hiring a violist but screening them with live sessions of Guitar Hero.

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

#170

Post by satran »

EMM_386 wrote: post #112

Please comment your code, when it is is necessary. I don't need "we need to loop here from 1 to 50", I need "we have to rate-limit this function to under 60 transactions per second due to hardware requirements", etc. If you are putting "magic numbers" anywhere, COMMENT it as to what that number is, why you chose it, etc. I'm 30 years into this game and I still come across code that takes way too long to reason about.

As a general guide I comment the why, now the what. The what can be generally understood by reading the code. But the why is not so easy.
Post reply on HN