This role was billed as fullstack, but the interviews barely touched anything front-end related. And the final round — I got screwed over by the hiring manager.
The phone screen was on 4/17. After I finished it we just chatted. The next day HR told me I passed and moved on to the onsite (VO).
VO Coding 1
Question 1: a simple calculator that only needs to support addition and subtraction.
["+", 1, 2, 3] => 6
["-", 10, 5, 3] => 2
The follow-up was where you'd add multiplication and division support. I nailed it instantly.
Question 2: explain how a hashmap works, then what happens on a collision, and asked about complexity.
Question 3: binary tree traversal (forgot which order) — you could choose to output JSON or just console.log in place. Also nailed it instantly.
There was still a good chunk of time left, so the interviewer threw in an IQ-style puzzle — the Rabbit Hunter Puzzle, just needed to explain it, then walk through worst/best/average case in detail. I got stuck for a bit but worked it out.
Question 4: how would you debug a memory leak in a JS web app. I answered with using CDP (Chrome DevTools Protocol) to reproduce, isolate, and compare. The interviewer seemed satisfied.
We had a pretty good chat overall.
VO Coding 2
Opening behavioral question: talk about a hard problem from the last few years that you had to "dig deep" to solve, ideally related to front-end.
Question 1: Add Word + Suffix Search. The answer is supposed to be reversing the input and solving it with a trie.
The follow-up: if you hooked that search up to an API, how would you implement the front-end typeahead component? It was the classic HTTP request racing and debounce question, and they also asked how to avoid SQL injection.
Solo BQ Round
Just the standard behavioral question stuff.
The last round was a system design round with the hiring manager — the strangest round of all.
The hiring manager's attitude was bad from the start. He just said we're doing backend system design today. The question was the classic overdone TinyURL — I had it memorized cold, thought I was set. I walked through the basic design and the interviewer said, "Didn't you hear me say small scale? Why are you using a database?" I thought to myself, if you don't use a database for TinyURL, are you supposed to store it in memory or something? He said he was asking about the abstraction. At that point I already felt like I was getting screwed.
Then he asked how you'd resolve collisions. My first thought: give every identical URL the same short code.
My initial approach was the standard random base62 + Redis + DB setup, indexing both the short code and the URL. Basically, when a request comes in you check Redis and the database to see if it exists, and if it does you just return it. He insisted he wanted something simpler.
We went back and forth for a while and I said I could use MD5 or SHA1 or some other hash function, but that still has collisions and you'd have to hit the database either way, and I got stuck there. I was stuck for a long time, then he drew a diagram and said, "If there's a collision, just write it to the next slot, like hashmap collision handling, right?" I immediately said that makes the worst case O(n) — the database could have a ton of short links, you can't scan the whole database every time. He kept insisting he was talking about the concept. At that point I was speechless.
There was still a bit of time left after that, and he asked about the principle behind DB sharding — how you'd use a hash code to know which machine to route to, and how you'd migrate data when adding machines. I don't think I really answered any of it well.
The morning after the interview I followed up on my status, and HR just called to say I was rejected, and that company policy meant they couldn't give any feedback at all.
A baffling interview, a baffling hiring manager — something's seriously wrong with that guy.
Discussion
Loading comments…