Hacker News Reader

Comment by brendanw | Hacker News Reader

It would be great if companies would allow you to bypass the code challenge if you grant them read git access to a relevant project that you have ownership of.

View on HN

This is a common sentiment among applicants, but after many years of hiring people, just FYI, looking at people’s github projects is one of the lowest quality signals I get from an applicant. It takes me forever to wade through someone’s code to figure out what they did or how good they are, and when there are multiple people on the project, it’s not easy to see who’s driving or what the cooperation/conflict situation is by looking at the git history. It can also backfire in a variety of ways you might not want and not know about, so keep this in mind. Your personal project code sometimes has lots of decisions in it that don’t look particularly good to a very experienced engineer. I can’t even count how many people have sent me github links for code they’re proud of that when I study it makes me second-guess the candidate a little bit. As an interviewer, I honestly prefer to hear the candidate talk through their code so I can find out they’re learning and hopeful rather than read code that says more about today’s limitations than tomorrow’s potential.

I had to read through your comment twice to get it. My experience leads me to agree with your idea of letting people talk through their own code. That category of conversations has usually been very rich and telling, much better than one over imaginary binary tree rotation algorithms or a "design a url shortener"-ish question. My favorite part is where a skillful candidate can lead the interviewer to interesting and real problems and solutions, demonstrate ability and both get to enjoy the conversation.

On a whim I responded to a recruiter last week about a job. The first step was an online coding challenge. The company wanted a "Java developer", and I told the recruiter I have never used Java regularly, but given my experience she said it wasn't a problem. I figured the code test would be some simple filter stuff.

Instead, it was five algorithm quizzes... all in Java. I had an hour to finish it and, after spending the first fifteen minutes searching for Java standard library stuff just so I could write the code I wanted, I decided this was a waste of my time and closed the tab. This was all before I could even speak with someone who works at the company to find out if I cared to move forward.

I worked as a hiring manager for a couple of years and have had input into the hiring process for more than a decade. I've never found it difficult to screen someone out who had no place applying to begin with by taking a fifteen minute call. This at least gives them a chance to ask some questions and they don't feel like you're yanking them around.

Problem is its easy to cheat about whats yours

As if regurgitating someone else's leetcode answers is any better? Or googling or stackoverflowing answers? Or a take home challenge?

Even at the ML level, engineering is more about applying known good techniques and less about new innovative ideas.

Companies think regurgitating leetcode is better... the number of problems that can be asked is quite large. Memorizing that search space in itself takes tenacity and a good memory...of which are signs of a good employee (regardless of their current coding skill set)

I think the trick here is have people talk through what it does, how and why (as in what are the tradeoffs, what other approaches could have been taken, etc).

You can't fake this. Or to put it better, even if the code isn't yours and you can do this well, it doesn't even matter that the code isn't yours as in doing this you by definition have the skills and knowledge to reimplement it anyway.

You can absolutely fake this. There’s a huge difference between coming up with and implementing something vs understanding it enough to be convincing.

Have you actually tested this out?

Yes I've done this both as an interviewer and interviewee, it's a pretty valuable exercise I've found. Not a silver bullet, not the only thing you can do, not appropriate for every situation, but generally good.

Regarding your other point I agree with you, but if the main point is to evaluate understanding then the difference doesn't really matter. If you're testing for ability to invent concepts etc, then this might be more important to you.

Okay, but at this point it sounds pretty much the same as a traditional interview where the candidate discusses their prior experience.

Not much harder than with a take-home challenge. Either’d be tough to do convincingly.

Reply on news.ycombinator.com