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".
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'm not sure how you could have confused what was posted, to be interpreted that way.
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.
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.