Hacker News Reader

Comment by adam_arthur | Hacker News Reader

The best coding interviews for 90% of tech jobs are ones that are heavy on coding and light on theory. Very few jobs are particularly well served by somebody with strong theoretical foundations, while most are well served by somebody who can pump out high quality code quickly.

Yet most companies interview as if they are inventing novel storage/processing mechanisms. Theory is important to understand which tools to leverage when, of course, but not to the extent that it's typically prioritized in the typical interview.

I've had plenty of people crush the theory portion of the interview and be poor performers on the job (slow coding, low volume output), but I've never had somebody crush the coding portion (implement very fast and proficiently), and perform poorly on the job

View on HN

Not for nothing but we have plenty of slow coders that are “low volume” but some of the most diligent and edge case counting engineer’s I’ve ever met. Even then, if the business doesn’t depend on everyone working like a banshee, my team may as well take their time.

Even as their manager it’s not my job to lead a death march.

Most growth companies have an endless bucket of work.

Somebody who produces 2x at same quality of work is worth 2x the other person, fairly objectively.

It's common to find people who produce up to 10x the average. Anyone in a startup or growth oriented company is smart to optimize for these people.

The most proficient and fast coders often write higher quality code too, in my experience.

People who over index on comp sci theory often are lacking in theory underlying good code. But it's not mutually exclusive. Just that if you have to optimize for one, coding proficiency matters much more for startup or growth type companies.

Exception might be like an AI/ML based startup with a lot of theoretical challenges. Most companies much more business/rule oriented though

I think the ideal is to have both in some proportion: like 10% slow coders dedicated to maintaining the structure of the application. And 90% people who can churn out features quickly

I agree but I would say: The ratio varies depending on the kind of product and especially on where you want to be on the spectrum of speed, security, safety, time to client...

How do you actually measure 2x or 10x workload while keeping quality the same?

It's _very_ easy to measure how fast it takes a ticket to go from "in progress" to "done" but measuring whether code has bugs, or leads to downtime or is just impossible to parse is a different problem.

If you never need code to be readable or documented I can write it quite quickly. If you want something other humans can have a hope of maintaining, that might take a bit.

It's pretty easy to tell when you're managing a team and familiar with the code. You can't quantify it explicitly, but it can be quite clear.

In my experience the top 20% of employees do 80% of the work

> In my experience the top 20% of employees do 80% of the work

That would make them 16x as productive compared to the bottom 80% who does 20% of the work. So 10x seems to be roughly the same thing as the 80/20 rule.

I think everyone who has been in tech for 7 years has a short list of people they’d want on their 4-person tech team and a longer list of people they wouldn’t.

That I can’t tell you to two decimal places exactly how much better the first list is than the second doesn’t mean I can’t tell who’s on which list with high fidelity/repeatability.

But those are people you've actually worked with day to day, right? They've had the long form of the interview with you and passed.

I know a bunch of people like that, but I've only worked with so many people. A startup would exhaust their friends pretty fast and be back to interviewing strangers.

I love creating these lists in my head. Sometimes when I do a good job, I imagine myself on someone else's good list. Often when I am struggling with something I worry someone is visualizing me on their bad list.

Over time it has made me question if my short list is as good as I think it is. Maybe I am biased and only observed good/bad work for people on either list. Also people change over time and take on new responsibilities that change their work.

I am 100% certain that I am a member of the “naughty” list for some ex-colleagues and the “nice” list for other ex-colleagues. ;)

It's 10x the worst not average developer so it becomes 2x the average.

Besides a 10x developer cannot be uncovered through a leetcode test or a coding test. A 10x developer pushes back on requirements, bridges gaps.. identifies issues early.. it's about making things happen not typing faster or knowing the stack well

It's definitely 10x the average. But exact numbers are going to be subject to debate.

The worst are net negative productivity

"have an endless bucket of work"

A long time ago I managed a developer who was a genius at finding and fixing bugs - so I thought I would reward him by writing a new module we needed from scratch. He could not do it - when faced with a complex mess of existing code he was perfectly happy and could dive in and fix stuff, faced with a blank sheet of paper he froze and didn't know where to start.

Developers are people and all people are different - we all have our strengths and weaknesses.

I've found that coding interviews just prove that you can write rushed, crappy code to solve a problem.

I mean that's what we do, right?

some people can't even do that.

> Crappy code

Being able to come up with an algorithm in a reasonable time doesn’t make it crappy. No wonder you can’t pass those.

> I've had plenty of people crush the theory portion of the interview and be poor performers on the job (slow coding, low volume output)

I think the reason for that observation relates to why these interview tests are generally a waste of time.

Based on the tests that I've seen, they are 'recall lots of useless information' tests. That means it's actually possible to study for these interview tests (if you have the desire) and if you can ace the test by just spending time memorizing answers.

However, 'slow coding' has very little to do with coding and everything to do with problem solving. You only learn how to problem solve through lived experience and many people never learn that skill.

These interview tests generally fail only because they're not actually testing for the skills needed to do the job.

Anything that anyone can find in a couple of seconds on a search engine is probably not worth an interview question. And that's valid for the interviewer as well don't ask something that you could find by looking at the resume.

This. I don't get why it's so hard to create this type of interviews...

> slow coding

What does that even mean?

You have a task to implement a new product feature and it takes you 1 week instead of 1 day.

In an interview context, I've seen cases where somebody fully understands the logic underlying the solution, yet it takes them 30m to write it, while another person can do it in 5m or less.

Essentially how long it takes to translate from mental understanding to working code

> Essentially how long it takes to translate from mental understanding to working cod

Congrats, you just invented whiteboard interview.

Whiteboard interview has nothing to do with coding proficiency. Writing pseudo code of an algorithm by hand does not tell you much at all about how proficient somebody is as a coder.

Coding is the act of writing code, not ideating an algorithmic solution. Its almost completely orthogonal to computer science problem solving.

The principles of high quality code (from a design perspective) are also completely orthogonal to runtime complexity of an algorithm.

Reply on news.ycombinator.com