The problem here is that for lots of big projects, there are typically only so many people who really drive the project to the completion. If you work for a big bank, you'd actually have a couple of people like you and a dozen of bystanders who lend a hand here or there, but are barely competent. They will have exactly the same resume as you, and it might even look more impressive. But their 20 years of experience in development is really just a couple of years played over 10 times.

So when hiring, I don't care if you're slow and methodical, or super fast. What I care about is that you understand basic algorithms and data structure (lists, sets, maps, trees) and can apply them to simple problems without me telling you that using a hash map here will speed up the solution tremendously, or using a heap will simplify the code. Those simple problems are also taken from most common patterns we see in our codebase, which consists of lots of geospatial data processing and analysis.

And if you need more than an hour to solve a couple of those simple problems (let's say, find duplicates between two lists), you'll definitely have a problem fitting in with the rest of the team - since everyone on the team has solved those problems and agrees that we need people with at least this basic algorithm knowledge to be able to make a significant contribution here.

These questions also a first hour of the interview, the rest goes deeply into discussion of previous projects you made, different architectural patterns, etc.