I've had the same job starting at a small startup, through growth and acquisitions, and I've been involved in hiring through the entire process.
Here's the dirty secret: startups try to be selective; but they're really desperate to hire. This is because startups are so mismanaged and risky that they have a lot of trouble getting someone competent to interview. When we were small, most people we interviewed were either incompetent or incapable of the challenge. Anyone competent got an offer.
As part of a mature organization, hiring is different. Most candidates can do the job, and actually want to work for us. (Unlike a startup, we now have good management and won't go out of business tomorrow.) Thus, we're more concerned with behavior.
My "competency test" interview has now evolved to more of a "tell me what I want to hear" interview. It's very effective, because almost all hires do the job well without wanting to perform useless refactoring because I didn't pick their favorite framework or brace style. It's also effective because I know I can communicate about higher level design topics.
I suggest, at a certain level, to just concentrate on telling your interviewers what they want to hear. This doesn't mean lying, or misrepresenting yourself. It just means that you need to understand who is in charge and play along with the same game everyone else is playing.
I'm also very clear about that when I interview a candidate. I now say something like: "This is a short interview and I try to ask questions that fit into the time. Some of the coding questions aren't real situations. The goal is to have a conversation about code, so if something is akward, just play along and do your best."