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

521–530 of 565 posts

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

#521

Post by Silhouette »

mdavidn wrote: post #460
NateEag wrote: post #396

Earlier quoted context omitted.

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 o…

I'm with Nate here. Commits are a form of documentation and can be useful for grouping together related changes. All of this context is lost when squash merging. That said, I do aggressively rebase and amend commits on the feature branch to consolidate commits into one for each change, including any minor fixes discovered later. For example: When I want to see tests or documentation or config related to a change, I'l…

Commits are a form of documentation and can be useful for grouping together related changes. All of this context is lost when squash merging.

In some ways it is unfortunate that services like GitHub and GitLab have become so dominant in the industry. If you're just working with plain git there is no assumption that squashing is some kind of binary decision the way the UIs of the online VCS services tend to present it. It's normal to do an interactive rebase and squash some commits to clean things up before sharing your code, yet keep logically separate changes in their own distinct commits, and you can have a much nicer commit history if you do than with either the no-squash or squash-everything extremes. Of course you can still do that with something like GitHub or GitLab as well but I think perhaps a lot of less experienced developers have never learned how or even why they might want to.

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

#522

Post by jameshart »

lkrubner wrote: post #518
jameshart wrote: post #30

Earlier quoted context omitted.

This is a "Guess what I'm thinking" question. Non-psychic candidates will struggle with this challenge, so you might find it produces some false negatives. Since you already seem to know so much about debugging slow performing database queries on your particular RDBMS stack, though... what was your thinking in looking to bring on board someone else who duplicates that exact knowledge? Oh, and it'll be a missing index…

The point is to start with something open ended, so the candidate can talk as much as they want on the subject, broadly, and then, based on what they say and what they don't say, I narrow in on particulars: "Are you aware of any differences in dialect between the SQL of MySQL and the SQL of PostGres?" It's not like they lost points for the stuff they didn't know, I simply wanted to be sure I understood the limits of…

You might want to consider if there’s a way to discover that without triggering the candidate’s imposter syndrome. Your script above reads like Tom Cruise trying to get Colonel Jessup to admit he ordered the code red. All that’s missing is the candidate breaking at the end and screaming “YOU’RE DAMN RIGHT I DON’T KNOW HOW TO DEBUG SQL”.

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

#523

Post by pojzon »

ravenstine wrote: post #425
pojzon wrote: post #231

Earlier quoted context omitted.

If you want me to clean up the mess your ppl created over the years -> be ready to pay me hefty premium or equity. Often times it requires not only a lot of skill but also a lot of work. I can do it but be prepared to pay me 2-3 times the normal wage.

I see a few people didn't like what you said, and that's mystifying to me because while I understand the point of view of the business owner, as well as the reality that nearly all code stinks more or less, at the end of the day your #1 obligation is to your own interests. There's no reason people should choose to work on projects they don't like if they have no financial need to do so, or if the pay isn't enticing e…

We need an oath the same way doctors do. We also need Software Craftsmanship principles. Unfortunately industry sucked in too many coding monkeys to make such drastic move with good pacing. Like you said - ppl have to die or be annoyed a lot to start regulating IT hard.

But TBH mission critical software has completely different set of checkboxes that are not so easy to fulfill.

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

#524

Post by hiptobecubic »

jseban wrote: post #405
NateEag wrote: post #399

Earlier quoted context omitted.

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.

I'm simply pointing out that the workflow of the pull request is made for a different workflow than what you normally have inside a team in a company, and it therefor quite a bad fit. And illustrating this with a few examples. I'm getting downvoted because I'm criticising developers favorite tools that lets them pretend to be Linus Thorvalds for a moment.

No it isn't, though. It's not like there's a "right way" to run a team. The teams I've been on that didn't review code always ended up imploding because because people rationalize their innocent corner-cutting when they don't have to deal with the embarrassment of sending it off to anyone.

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

#525

Post by developit »

nickcoury wrote: post #8
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 favorite front end interview did this exact thing. The interview started with an issue taken straight from the Preact GitHub codebase. The interviewer provided the issue text and the commit right before it was fixed to pull down onto my machine. I had an hour to figure out how to build and reproduce the issue, Take in the high level structure of the code base, figure out how to drill down in a debugger to find whe…

This sounds fun

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

#526

Post by actually_a_dog »

jseban wrote: post #309
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.

Yeah there's nothing that prevents you from using a tool in exactly the opposite way that it's designed to be used, but it's also pretty unlikely that it's going to happen or that it's going to be successful.

I'm beginning to think you've never actually used github. Are you trolling?

The tool does not stop you from working in the way you suggest. Maybe it's not what the engineers who wrote it originally envisioned, but it's both simple and easy to work in the way you suggest.

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

#527

Post by icedchai »

mylons wrote: post #507
jacquesm wrote: post #352

Earlier quoted context omitted.

> I guess they expect them to be just faster versions of juniors. No, they expect them to be: - more independent - able to bring past experience to bear on present problems - make fewer mistakes - be able to help others rise to the next level - possibly make good team leads at a later stage

yes and no. the last company I worked at is a feature factory. They have senior, and staff engineers, on various product teams that have 0 technical influence. What they expected is you to somehow increase quality of the product via code review and writing design documents... but the quality of the product was being destroyed by a handful of people making all of the technical and architectural decisions and forcing t…

I think we must've worked at the same place. I took a job at a jira feature factory working on an aging, ossified code base. Literally, it was using the same tech I was using 10 years ago, almost exactly, except it was new back then.

I spent most of my time writing design documents, doing code reviews, and shepherding my relatively small changes through review. Something I could've banged out in a week would take months due to all the review and processes.

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

#528

Post by whitesilhouette »

ornornor wrote: post #386
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…

> It's not much work and can be done in 2-3 hours. I bet it’s much more work than that. It’s maybe 2–3h for you, who has reviewed dozens of submissions, have designed the problem, and know what the actual solution is. For the rest of us, it takes trial and error, implementing, polishing (because of course you want to show your absolute best code when being judged solely on your code) and it’s probably actually taking…

It's 2-3 hours for a guy having a 2-3 years of experience (which is what I'm looking for). And yes, I get those attempted by the guys in my team before sending it out. And yes, most of the time, I end up flushing out a few bits of the question before actually sending it out based on their suggestions.

In reality though, the time spent by the guys varies. I always ask them how much time did they spend on the question after selection. The mileage varies from 30 mins to 4 days (because they had office work/weekend trips and attempted the question only when they were absolutely free). No, the hiring HR makes it specifically clear to not try to give a polished code during the initial call and only work 2-3 hours on it.

I see where you're coming from, lengthy problem solving questions are definitely not worth anybody's free time. I've seen problems that can take 1-2 weeks to solve. But for me 2-3 (or even going by your maths of 4x3... 12) hours... is definitely worth your free time... Because 1. that's the amount time you spent while giving your 4 other interview rounds in 4 other companies paying ¼th the salary. 2. Or for a similar company paying an equivalent salary that takes 4 rounds of interviews spread across 4 different days (counting your commute time as well).

Implement array.flatten can be Googled in under a minute. That beats the purpose of a test. I'd rather take a telephonic round and be over with it. The core idea behind my shift was to ensure candidates can't cheat. (And I hate video calls because a lot of them end up having connectivity issues during the interview, especially during the difficult questions).

> I don't read any further and bail. Yes. This. You're the kind of guy I don't want my time wasted with. There are a lot of intelligent candidates who'd have definitely aced a telephonic round (or even this written test for that matter) but bail out at the sight of "implement a...". In my experience, you're the kind of a guy suffering from Dunning-Kruger syndrome. The good work is there, but the headaches that such candidates cause on the other 90% of the times makes it not worth my time.

We can argue this to the world's end but in the end what matters is the demand and supply market forces. You can call my process a waste of your time. I'm sure you'll end up getting a better job the next day. And on the other side of this coin, even I'll end up getting a better candidate than you. In my experience, all the candidates that I've hired in this format have been marvelous, so I'm gonna stick to this.... At least until I keep getting great candidates.

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

#529

Post by whitesilhouette »

vsareto wrote: post #410
dahfizz wrote: post #400

Earlier quoted context omitted.

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

Well, if they made me stand in line for 2-3 hours, then decided not to give me the food that I paid for because I'm not a culture fit for the grocery store, then yeah probably.

And do you ask payment for the comp-off against the time-off that you had to take to visit for the interview.

And do you ask payment for the gas spent while driving to come attend the interview.

And do you ask compensation for your intelligent views presented during the interview when they asked you a technical problem related to their real life scenario and your answer ended up solving that saving them millions.

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

#530

Post by icedchai »

cphoover wrote: post #234
pelario wrote: post #225

Earlier quoted context omitted.

I suspect you have not read enough code.

In my professional experience there is a lot of poorly writtem, convoluted spaghetti code, that is extremely hard to follow. Im not sure why people seem think reading code is easier than writing code... this is often not the case.

And OO spaghetti ("lasagna") can be the worst. Class hierarchies 6 levels deep. Some methods overridden. Needless abstract classes with single implementations. "Logic" spread out all over the code base.
Post reply on HN