[8f2ab37a-ed6c]

My thesis is that in software it takes an expert to identify another expert, and outsiders struggle with being able to tell who's full of shit. You end up with pseudo-metrics like lines of code and random inspections of the last bit of code you wrote (e.g. muskian Twitter).

An experienced engineer with many products under their belt and tons of coaching of others on their track record will easily tell if someone knows what they're doing, especially if they get to pair program together for even 30 minutes.

[neilv]

As soon as you get away from what the interview prep books cover, it's usually pretty easy to tell if someone in your own field is experienced and at least competent, just by talking with them.

(Leetcode seems to be an awful predictor of how someone will perform as a software engineer. That students are spending so much time practicing for it, rather than experimenting and building things, is awful. Some of the biggest companies they're applying to were founded by students doing the opposite of practicing for someone else's hazing rituals -- they were experimenting and building.)

[wildrhythms]

I genuinely believe a 15 minute back and forth between an engineer and an interviewee will give a better signal for hiring than any hours+ long Leetcode 'assignment'.

[midenginedcoupe]

I used to interview like this, until I hired the wrong person. They talked elequently about how to program, but just weren't very good at digging in to technical details of an existing codebase and understanding what was actually going on.

So I added an hour's pair programming on either toy problems or our existing codebase, depending what was suitable at the time. No leetcode, no months of prep for candidates, and our interview outcomes were much better.

There's a massive gulf between toxic leetcode hoop-jumping and a friendly chat.

[mianos]

While this may be true, it takes more than just engineering skill for this to work in a predictable manner. Often an engineering interviewer takes their ego into the process and it becomes a competitive game or an opportunity to show how smart they are.

I 100% agree with you but it's not as easy and scaleable as it seems.

[neilv]

Agreed, interviewer ego slipping in can be a problem.

Interviewer training can help avoid that happening accidentally.

(And Leetcode interviews don't avoid the interviewer ego problem. It's purportedly "objective", but the interviewer can easily taint it, accidentally or intentionally. The answer isn't Leetcode, but to train or reign in egos, and then you can use a real conversation.)

[sureglymop]

Leetcode also encourages people to 'roll their own' algorithms and cryptography. Even though most languages have standard libraries which cover all of it already.

[mianos]

This is the fundamental concept of filtering out bad research by peer review. Work is reviewed by people who know the field well enough to understand a paper.

Ideally we have this by code review, which should, theoretically, filter out the bullshit, but software development, as the original post in this thread says, may be overwhelmingly populated by bullshitters or people who honestly don't know their own lack of ability.

This is exaggerated by agism and completely discounting audited real experience over leetcode and small take home projects.

[fsckboy]

"lines of code" is not a pseudo metric. On large scale projects, statistical population density functions emerge, and if you need to manage such a project (like getting to the moon by X date) you can't just throw away the entire field of statistics because it says some things that you personally, anecdotally would like to dispute.

[8f2ab37a-ed6c]

What's a good example of a situation where lines of code written are a high quality signal of software developer performance?

[fsckboy]

If my company is under contract to your company for a piece of software, and the software we (a team of 100 people) deliver is a million lines of code, and you ask for changes to the software that you believe fall under the contract and we believe do not fall under the contract, in any event the scale of the change, let's say it's 200K lines of code, does offer a pretty good estimate as to how long it takes to change, how much it cost, etc. as compared to the original deliverable, and wether and now such a difference of opinion might be litigated.

It's better compared to many other measures you might think of, though it's an interesting exercise to consider what might work better.

it's not a pseudo metric.

(source: I did some work for a litigation support/consulting firm, expert witnesses for defense contracting)

[8f2ab37a-ed6c]

That's an interesting case that I hadn't thought of, or encountered myself, so thanks for sharing that!

We might be talking past each other here, so please correct me if I'm wrong, but how does the example you presented address the argument that "lines of code produced are not a useful metric for evaluating individual developer performance at hiring time"?