This can only be true if your codebases are very small (e.g., at a rinse-and-repeat site mill).

For anything non-trivial, as your code grows the amount of time required to understand it will grow too -- even if you're using "standard" frameworks, etc. -- because the business logic driving your design decisions is learned with experience. For example, we have a guy at our large company who's a terrible programmer but we keep him on the team (albeit somewhat quarantined) because he's been there forever and has enough institutional knowledge to be valuable.

As your systems grow even more, there will not be off-the-shelf solutions. You'll have to sit down and do some real-life architecting and that won't be learned in 2 weeks. Even if you could perfectly document all your systems and design intentions (you can't), well documented decisions still take time to be read and "soak in".

Exactly. Add interaction with highly complex custom hardware and you're looking at more like 2 years rather than 2 weeks to get to the point where anyone can claim expert level knowledge.

I've been on both sides of this with large code bases, and I disagree. A good programmer can get into even very messy code bases quickly. Even in the worst case of ugly code there is a structure/architecture trying to keep thing understandable.

Or maybe it is easier in large code bases because the worst programmers fail? I don't know, I haven't worked with many tiny code bases.

I've been at a new company for a few months, and still find the codebase confusing/frustrating. At my previous job, I was a tech lead/architect. Here I feel like a dummy. Talent can't necessarily overcome poor documentation.

So what are you saying here? You only hire great programmers? And they all shock you in the same way? Or you hire some mediocre ones too who don't shock you that way? And how do you interview them?

We hire a mix. The good ones (there are a lot of good ones) are quickly making useful progress. The bad ones sound good and seem to be asking the right questions, but never really make progress. My boss said he knew in a week if someone was good because that is the longer it took for the team to say "he knows what he is doing, we rarely check on him", while the bad ones "He is making progress but isn't ready to be left alone". Only after a couple months are the other programmers willing to admit the guy who seems like he knows how to code can't write code.

I generally agree with this - I've had pretty solid impressions of capability after a few weeks that have largely been proven out.

The challenge I'm still facing is crafting interview questions that most effectively match those two-week impressions.

My issue with purely sticking to coding questions is that I've seen a handful of people study enough to nail those and then be completely uncreative or unmotivated beyond that. Specificity seems to be a key thing in other types of questions, to at least weed out the hopeless. You built this thing? You had that experience? Tell me the details. Tell me the details of those details. Etc.

One of the things making it hard is that the true standouts are rare enough that I've only hired a couple of them, so it's hard to find what's meaningfully shared between them that's identifiable in a single day.

I tend to disagree with this close minded judgement. Only because I’ve seen employees who I’ve written off after a few weeks become the goto brain after 6 months on the job. They exhibit a quality that can turn things around. Maybe you haven’t worked with enough really good programmers.

> So what are you saying here? You only hire great programmers?

I'm not sure how you could have confused what was posted, to be interpreted that way.

Given that he did it might be more helpful to offer a better interpretation, rather than just being dismissive.

> Given that he did

You made up a question that wasn't posted. Please re-read the thread. Please don't attribute your words to someone else. It's transparently dishonest.

I asked because the relevance was not evident to me, in a discussion of hiring processes, unless it was directly related to his own hiring process in some way.