←back to thread

191 points foxfired | 1 comments | | HN request time: 0s | source
Show context
stephenpontes ◴[] No.45110797[source]
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.

replies(3): >>45111168 #>>45111494 #>>45111507 #
1. TheDong ◴[] No.45111494[source]
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.