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

211–220 of 565 posts

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

#211

Post by olliej »

chrismcb wrote: post #156
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…

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

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

#212

Post by angarg12 »

lucb1e wrote: post #3

That's interesting, I've never heard testing code skills by reading instead of writing. An example would have been nice though, as I'm not sure how to find a piece of code that does something standalone that is too large to grasp in 20 minutes yet make a reasonable prediction at the output. That combination seems kind of weird. I wonder how well it would work to modify OP's idea and present a candidate with some code…

My company has an initiative to bring in students for a 3 day event where they attend workshops and talks.

We were brainstorming what type of content would make fun and educational workshops for students. I proposed something along OPs lines. I called them "debugging minichallenges". The idea is to present students with a buggy implementation for a simple problem, and they need to find and fix the bugs. Just as OPs argues, the concept is that reading and understanding code is a fundamental skill.

I have the set of sample implementations in my Github, for example the one in Python [1]. This is our first time running this workshop so I can report how well it did after the event.

[1] https://github.com/angarg12/minichallenge-flood-fill-python

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

#213

Post by hinkley »

Yhippa wrote: post #174
beebmam wrote: post #125

Earlier quoted context omitted.

Virtually all game companies use Trunk Based Development, in my experience, including many very large studios. (Outside of game engine development, which isn't really done by game studios anymore with a few exceptions)

Interesting, I wonder if that's why you see insane build numbers like 1.2.4045.26836?

I suspect you'll find that two of those numbers are decided by committee, one by a human, and the other by the build system.

There's good odds that it's the 26836th build, the 4045th snapshot, and the second time they've broken the file format. (or the 2nd expansion, or both)

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

#214

Post by ozim »

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

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

#215

Post by angarg12 »

johnqian wrote: post #18

I sometimes ask candidates "what kind of interview do you feel would best bring out your strengths?" and try to adapt the interview to their response if I can. It's helpful if they want to talk about side projects or war stories, but doesn't pressure them to. I still give my coding challenge after. Wonder why no one else does this.

When hiring at scale we value consistency so this wouldn't work well. However in my company we started an initiative called "candidate experience". In one of the interviews we allocate some time for the candidate to "flex" as you put it. We ask open ended questions such as "what is your proudest achievement?" or "is there anything you wanted to tell us but didn't had a chance to?". These questions are not used to evaluate the candidate and often are no even recorded, and gives a chance for the candidate to relax and put forward their best self.

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

#216

Post by wonderbore »

srigi wrote: post #208
dwaltrip wrote: post #158

Earlier quoted context omitted.

> If you are putting "magic numbers" anywhere, COMMENT it as to what that number is, why you chose it, etc. Better yet, turn magic numbers into constant variables whose name becomes the comment. Of course, comments can also provide additional context :)

Agree. I also add to this - name your constants by meaning, not value. Too many times I see const ONE_HOUR_IN_MS = 3600000 Instead I would like to see const RESEND_DELAY = 3600000

Better yet:

    const ONE_HOUR_IN_MS = 3600000
    const RESEND_DELAY = ONE_HOUR_IN_MS

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

#217

Post by tisc »

srigi wrote: post #208
dwaltrip wrote: post #158

Earlier quoted context omitted.

> If you are putting "magic numbers" anywhere, COMMENT it as to what that number is, why you chose it, etc. Better yet, turn magic numbers into constant variables whose name becomes the comment. Of course, comments can also provide additional context :)

Agree. I also add to this - name your constants by meaning, not value. Too many times I see const ONE_HOUR_IN_MS = 3600000 Instead I would like to see const RESEND_DELAY = 3600000

I like to combine those:

    const RESEND_DELAY_MS = ONE_HOUR_IN_MS;
Having the unit in the name saved me more than once and having non-contextual constants for sizes increases readability imo.

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

#218

Post by hamburglar »

TameAntelope wrote: post #204
hamburglar wrote: post #200

Earlier quoted context omitted.

That sounds wonderful in theory but it doesn’t seem realistic in general to have this doc explaining a particular constant and why/how it was chosen that doesn’t need updating if someone comes along and chooses a new value. I appreciate that you think you’ve discovered the answer here, but experience tells me it ain’t that simple.

Care to elaborate on why your experience tells you this? I’ve put this into practice numerous times with positive effect, so my more relevant experience tells me this is a winning strategy, compared to in line docs, which are objectively worse in nearly every way.

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

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

#219

Post by harrydehal »

travisgriggs wrote: post #164
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.…

Throwing in my own anecdotal example and tiny sample size: many years ago I was part of a trio of 20s, 40s, and 60s front-end devs – all rare and elusive Bay Area natives who grew up in very different part of SV history with very different backgrounds.

On first glance, we really should not have worked well together. But the group clicked because it shared a value system (be it for writing clean code, good documentation, user experience, collaboration, etc.).

And it was two introverts and one extrovert, to boot!

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

#220

Post by mongol »

wonderbore wrote: post #216
srigi wrote: post #208

Earlier quoted context omitted.

Agree. I also add to this - name your constants by meaning, not value. Too many times I see const ONE_HOUR_IN_MS = 3600000 Instead I would like to see const RESEND_DELAY = 3600000

Better yet: const ONE_HOUR_IN_MS = 3600000 const RESEND_DELAY = ONE_HOUR_IN_MS

I don't get why this is better. My approach:

const RESEND_DELAY_MS = 3600000; // because TTL in Agora

Post reply on HN