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

141–150 of 565 posts

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

#141

Post by quickthrower2 »

0x20cowboy wrote: post #31

I think we should just jump to the end game and make interviewees do ultra man triathlons while solving differential equations. Then at the finish line, they knife fight each other to find the one we let go to the next stage in the interview. That way we can be sure who has stamina and the best competitive programming problem solving skills. Something like squid game will truely find the A players. I mean, we wouldn’…

I interpreted squid game as an analogy for real life. If you staying alive depends on money which depends on having a job, then algorithmic interviews are a mild squid game after all.

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

#142

Post by jra_samba »

teddyh wrote: post #122
jra_samba wrote: post #102

Earlier quoted context omitted.

Of course malloc is implemented in C. Look at the glibc source code.

Malloc cannot, IIRC, be implemented in standard C only. It needs non-standard system calls. Specifically, how does malloc() itself allocate new memory?

mmap, brk, sbrk are standard POSIX system calls.

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

#143

Post by dilyevsky »

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?

I’m assuming based on gp everyone merges into master, no one reviews each other commits. Very uh.. mature

Btw trunk based in general can still have short lived branches and prs. That’s what most public projects on github are doing

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

#144

Post by bkuehl »

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.

Agree completely.

Also, good commenting skills take years to master.

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

#145

Post by quickthrower2 »

ineedasername wrote: post #69

Reading probes the most fundamental skills. Reading code is probably 95% of what a developer does as part of their job. This is true. Most of the time I'm only reading my own code, and over the years I've been motivated to code better by having to go through crap I wrote early on.

In my jobs I am reading other peoples code most of the time. Maybe a consequence of small company/team “jack of all trades” culture and also there are more “not mes” than “mes” contributing to the code base. Hell someone doesn’t even need to be currently employed there for them to have the pleasure of me reading their code (or maybe my pleasure!)

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

#146

Post by jra_samba »

yongjik wrote: post #129
jra_samba wrote: post #84

Earlier quoted context omitted.

No, that's not true. If you know anything about C and writing secure code (which I what I was probing for) you know about using malloc(). You know because you have to know something about the internals of memory management. Imagine you just read a 4 byte value off the network, and it's part of a protocol that specifies how many more bytes there are to read. You might (in error, ahem... :-) pass that value to malloc()…

Unless you are specifically hiring for low-level network performance tuning (which is not how 99% of Googlers are hired), this still seems like a trivia question that's only marginally related to a person's C(++) competency. My impression is that Google discouraged asking such questions. Source: worked at Google.

I don't code to in C++ anymore. Did a long time ago. I'm looking for careful programmers around security and API design. This is nothing to do with performance tuning. It's to do with security.

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

#147

Post by no-dr-onboard »

reflection99 wrote: post #137
no-dr-onboard wrote: post #135

I’m personally against this approach. I’m an appsec person. I absolutely do not know how to write most of the code I review. In my past two jobs I’ve been required to read code and explain it during interviews. I’ve never had trouble explaining what’s going on because on a very basic level, most languages use the same conventions. If this were a heuristic of a good developer, it would let me (not a dev) in and who kn…

Interesting take

I’ve got more:

I think one way to iterate on this to weed out guys like me would be to ask process based questions that reveal the candidates experience and preferences:

“Brainstorm with us on how you would you make this messyFunction more performant given $these conditions”

“We are thinking of developing a feature that would call this function more often. Would you turn this into a micro service?”

“Looking at this db call, how do you see this scaling if we increase the number of x and y?”

“Is the following PR safe or sane?”

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

#148

Post by [deleted] »

jra_samba wrote: post #68
llimllib wrote: post #63

Earlier quoted context omitted.

I'm not anything other than a C tourist, and I see that the man page says it returns either NULL or a "unique pointer value that can later be successfully passed to free()." I'm kind of at a loss about why it can return either of those two things, somebody want to take a shot at explaining it?

Both NULL and a unique pointer value can be safely passed to free() :-). Answers to this question taught me about the candidates taste and understanding of good API design :-). Both NULL and "unique pointer" are correct answers, but all modern implementations only chose to return one of these. My follow-up question is "why ?" :-).

[deleted]

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

#149

Post by dilyevsky »

dasil003 wrote: post #123
mhh__ wrote: post #50

Earlier quoted context omitted.

arguably worse for smaller companies. if you hire the wrong person you can't even try and move them somewhere better suited to them

Hard disagree on this. Large companies can't afford false negatives because false negatives can hide out and move from team to team without detection. At a small company if the same thing happens it means leadership is incompetent and you have bigger problems anyway.

Large companies can and often do afford sizeable percentage of workforce making zero to negative contributions. This would be devastating for a small team with a finite runway

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

#150

Post by BFLpL0QNek »

zdragnar wrote: post #119
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. 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 your team.

The best teams I worked on who delivered working code fast, efficiently even when they are some of the most complex projects I worked on committed straight to trunk, had a very good build pipeline (super import) and worked closely together for review. The standards where extremely high yet the general feeling was it was less dogmatic, micromanaged or kept behind a gatekeeper.

The projects I’ve worked on with dogmatic pr’s generally failed to deliver anything in any amount of reasonable time. 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.

Post reply on HN