Comment by khyryk | Hacker News Reader

Comment by khyryk | Hacker News Reader

Parent Full thread

"Code review this" or "debug this" or "refactor this" are things that an actual developer doesn't need to do special preparation for as they probably do it almost every day, unlike LC, and should provide a signal more relevant to the job of coding that the candidate is smart and capable of doing good work. Having a bit of code to work with can also take away some stress by reducing the emphasis of typing a complete solution from scratch -- there are many LC interviews where if someone isn't typing right away, they have no hope of solving the problem in their 20-25 minutes of time even if they fully understand the problem and the correct solution.

Take homes can get a bit out of hand because candidates can choose to spend too much time (12 hours on something that "should" take 2 hours) out of desperation (or perhaps simply not having a life) if the primary criterion is the completeness of the solution. I think it works best if the solution or partial solution is used as something to have a conversation about in the next interview. For instance, the applicant can explain their lack of unit tests by providing their reasoning for relying more heavily or entirely on integration tests as the system relies too heavily on an external service.

The challenge with code review/debug/refactor interviews is that they rely on the candidate being familiar with the "this". The original intention of LC interviews was to remove domain specificity from the "this". Prior to LC interviews, candidates would get asked about their familiarity with things like ISO standards, random libraries, or other weird behaviors best learned through memorization. This can be mitigated with candidate prep and/or problem selection, but it's worth keeping an eye on.

For take-homes, I don't think the candidate spending 12 hours on something that should take 2 is necessarily a negative signal - but it's also something that should be considered. If the candidate spent 12 hours ensuring the solution was perfect, then it's probable that they are just thorough - which is a good thing more often than not. You do end up in a quirky situation of judging candidates by how much time they are willing to dedicate to your take-home interview though.

Anecdotally, for the few take-homes that I've done - I've always gone a bit overboard out of pride. Granted, this is also how I approach a lot of coding tasks.. so I guess you get what you test for?

Domain specificity can be mitigated by matching the interview problem(s) with the tech stack that's being hired for. Doing a refactoring of some basic Java code that's not going crazy with annotation processing would be quite reasonable for a job ad seeking to hire someone to do Java development; the same problem can be replicated in Python, JavaScript, etc. to accommodate different skill sets. I wouldn't expect this style of an interview to determine whether one understands the specific gotchas of Django Models if the company is seeking an average developer to do average work for average pay.

The 12 hour vs 2 hour thing is to allow for a degree of normalization, similarly to how it's unclear about what's being considered when 1 applicant spends 3 hours on a LC medium and another spends 30 minutes. Spending an extreme amount of time on take-homes confounds simple pride with someone who's otherwise a bad fit skills-wise but can eventually make up for it with an input of time, something that might not be appreciated after an offer is accepted. Too often companies will refuse to speak further with candidates if even 1 out of 20 test scenarios are not covered just because someone else chose to spend their entire weekend on the problem -- they'll be the same ones complaining about a dev shortage, no doubt.

> Doing a refactoring of some basic Java code that's not going crazy with annotation processing would be quite reasonable for a job ad seeking to hire someone to do Java development

This goes back to the days where job ads would request N years of X experience. The big takeaway from the last ~10 years is that this type of requirement is unnecessary. As an engineer who knows the fundamentals, it's relatively straightforward to pick up a new tech stack.

I wouldn't want to pass on someone who spent the last 5 years working in C because we have a java stack.

Reply on news.ycombinator.com