I had almost this exact interview experience recently with a popular AI startup. The exercise was to build a search UI over a static array of dictionary terms. It was a frontend role so I wired it up with filter and startsWith and spent more time polishing the UI and UX.

The final interview question was: “Okay, how do you make this more performant?” My answer was two-tiered:

- Short term: debounce input, cache results.

- Long term: use Algolia / Elastic, or collaborate with a backend engineer to index the data properly.

I got rejected anyway (even with a referral). Which drove home OP's point: I wasn't being judged on problem solving, but auditioning for the "senior eng" title.

With candidate interview tools and coding aids increasingly hard to detect in interviews, this gap between interview performance and delivering in the role is only going to widen. Curious how many of these "AI-assisted hires" will start hitting walls once they're outside of the interview sandbox.

In general:

- At a large tech company, a referral can help you get an interview; it rarely affects the actual hiring decision or the offer.

- As an interviewee, I might feel like I did great, but I don’t know what signal the interviewer wanted or what their bar is for that level.

My son’s school uses an adaptive test three times per year (MAP Growth). It’s designed so each student answers about 50% of the math questions correctly. Most students walk out with a similar perception of:

- how hard the test was, and

- how well they did.

Those perceptions aren’t strongly related to differences in their actual performance.

Interviews are similar. A good interviewer keeps raising the difficulty and probing until you hit an edge. Strong candidates often leave feeling 50/50. So “I crushed it” (or “that was brutal”) isn’t a reliable predictor of the outcome. What matters are the specific signals they were measuring for that role and level, which may not be obvious from the outside, especially when the exercise is intentionally simple.

Many years ago, when I interviewed at an investment bank for a structuring role, I answered all of their questions correctly, even though some of them were about things I'd never heard of (like a 'swaption'). I answered at what I thought was a reasonable pace, and only for one or two questions did I need a minute or two to work out the answer on paper. At the time, I thought I'd done well. I didn't get the job. I now know more about what they were looking for, and I'd say my performance was somewhere between 'meh' and 'good enough'. I'm sure they had better candidates.

When I interviewed at Google (back in 2014), I was asked the classic https://github.com/alex/what-happens-when question. I didn't know it was a common question, and hadn't specifically prepared for it. Nonetheless, I thought I crushed it. I explained a whole bunch of stuff about DNS, TCP, ARP, subnet masks, HTTP, TLS etc.

I said nothing about equally important things that were much less familiar to me: e.g. keyboard interrupts, parsing, rendering, ...

Luckily I passed that interview, but at the time I thought I'd covered everything important, when in reality my answer helped show the interviewer exactly where the gaps were in my understanding.

One of the worst things about the employment market in the US is that you almost never get accurate feedback about how well you actually performed. The reasons for this are of course legal (i.e. the company doesn't want potential liability in case the rejected employee uses the feedback to sue), but it is one of those things that work out against job seekers in a major way.

I mean, you know that the answer the interviewer was looking for was "use a trie/prefix-tree, want me to implement it", not "that's not my job, ask another team to setup elasticsearch".

If you're going to do coding interviews, you can say "I would use X tool", but you can't _just_ say that, you also have to say "but if I can't, I would write X algorithm, should I write it?"

Also, based on your description, you're suggesting going from entirely client-side, to having a server round-trip, to make it more performant. I could be misunderstanding the full question and context though.