Hacker News Reader

>Take home exercises provide little to no signal, and screen out people who have families (who wouldn’t bother with a 4 hour take home exercise after work). I don’t want to see how you Google, I want to see how you think.

I tend to think that's very possibly true of developers (especially if they haven't worked in open source) but I wouldn't generalize that some combination of pointing to samples of past work and/or a take home isn't valid for a late-stage interview/demo in general. Jobs that involve a lot of writing or presenting, for example, probably require some demonstration of ability whether pre-existing or created for the purpose.

I'd also say that one mistake along this line was taking one such sample and assuming that it was close enough and could be upleveled with a bit of work.

I helped my friend from university get a job by helping him do their take-home exercise. I didn't write the code for him but I walked him through pretty much every single step. I'm not proud of that but my friend needed a job and I was in a position to help him get it. My principles are not nearly as important as that job was to him.

If you let people cheat they will cheat.

Yes, people can cheat. In my example, you can mitigate by having them also do a live presentation and ask probing questions about what they've written if that's part of the job.

The coding equivalent would be asking them why they took some specific approach or used a particular algorithm. I'm not sure about my feelings with respect to coding takehomes but there are circumstances where someone doesn't have an openly viewable body of work where takehomes can make sense.

There's a difference between live coding round and leetcode rounds where you need to perfectly write code for as medium or hard leetcode question in 20 minutes.

1) that’s not what most companies do

2) if you have thousands of applicants for a position, and probably a dozen stand out by passing a really tough bar, wouldn’t you want to find those dozen?

> 2) if you have thousands of applicants for a position, and probably a dozen stand out by passing a really tough bar, wouldn’t you want to find those dozen?

It's a reasonable assumption, but you might not. If the role doesn't actually require those skills you might hire someone who's going to get fed up and leave in 3 months or (worse) who invests time in making their job more interesting instead of solving your actual business problems.

Good points. Most FAANG/MANGO companies in India do leetcode. And I know Amazon still does leetcode in US/Europe.

So, yeah, you are right. Live coding is very good, which is what I do, but too many people confuse live coding with just leet coding.

The question is, however, whether this is a good proxy for one's future colleague and employee.

I have no idea what could be a better option (well, maybe preparing some small feature to work on together), but it often turns out that good problem solvers are not really great at doing the job, for reasons that have nothing to do with the hard skills.

Totally valid critique.

Hiring is really hard. You only get a few hours to decide whether someone will be a good engineer and colleague for several years.

By the nature of the constraints alone, anything you do will be extrapolation, and a guesstimate at best.

> It’s not perfect, but I won’t hire anyone that can’t pass a live coding round

I'd like to add two points to this:

First, I like that you said "live coding" rather than leet code. The floor for live coding should be super low, with a high ceiling and lots of flexibility. That allows you to say, nope, they didn't pass the floor level, easy binary decision, no hire. Pick a fun toy to build in 90 minutes and the high ceiling + flexibility will yield tons of signal from applicants.

Second, I see live coding sessions like this as a positive sign from potential employers. It lets me know that my future colleagues will have some baseline level of competence. If you've worked on a team that didn't do live coding, and you've had to carry water for someone who can't actually do the day-to-day technical "hard skill" work of software engineering, you probably feel the same way. Never again.

Absolutely agreed.

I start with a simple problem with several answers of varying difficulty and literally instruct the candidates to code the first correct solution they can think of.

Nested for loops, brute force, it’s absolutely fine.

I just want to see you translate what’s in your head to code. I want to see you structure code, use data structures, etc. Then we will talk through optimizations, refactoring, testing, edge cases, etc later.

You want even the under qualified candidates to feel like they got some pieces right and had a fair shot.

As you start probing deeper, the top candidates stand out. They answer your questions about the differences between data structures, how you would test this piece, how you would monitor that piece in production, how you could parallelize it, etc.

> I won’t hire anyone that can’t pass a live coding round.

Excellent - please be sure to mention this in the job description so I can know to never apply to where you work.

Don’t worry: it doesn’t sound like that will be something you’ll have to be concerned with.

This idea that “I’m special - I’m too good for a live coding round” is definitely not an attitude I want on my team. It’s highly entitled.

> This idea that “I’m special - I’m too good for a live coding round” is definitely not an attitude I want on my team. It’s highly entitled.

The irony.