I'd looked at this company before and thought about applying, but I never really believed I'd pass an interview here, so I went in with a "just try it" mindset. The whole interview was really contradictory.
You'd think a technical interview would be short and to the point, but the interviewer was very impatient the whole way through. He gave only a very brief, shallow rundown of himself and what his team does — clearly not interested in talking much. He had me introduce myself; I felt out the room and gave a rough overview, and sure enough he had no interest in listening. He didn't ask follow-up questions, didn't try to learn more about me. He was basically about to yawn. Then he quickly cut me off and said we're mainly here for a technical interview, which translated basically meant "stop wasting time and get to the problem." So you'd think that meant he'd hand me something concise and clear — but no, he absolutely did not give me a concise, clear algorithm question. Instead he pasted in an essay-length, super long problem description.
It took me most of the time just to read through it. Roughly: say we're building an app that lets customers submit the times they want to host a party. Each party has a time window and a corresponding party ID, and from that party ID you can also look up the party's location info — state, town, county, neighborhood. The problem specified that whenever a customer submits, the app stores this using two classes: one is PartyWindow, which stores the party's ID and the time it's held; the other is GeoData, which stores the party's location info and ID.
The first part asked me to write a method that returns each neighborhood's earliest and latest party start time. Basically: take all the data the user submitted, join the time info and the location info together using the party ID, group everything by neighborhood, then sort to find the earliest and latest times.
The second part said: you've now returned a hashmap with each neighborhood's earliest/latest party times — now group those neighborhood times by town, and find how many hours of "gap" time there are, where a gap is a stretch of time in that town with no party happening at all.
Honestly the problem itself wasn't hard. For the first part I just went with gut feeling, wrote the code, didn't even debug it, ran it, and it passed all the test cases on the first try. The second part wasn't really hard either, but I genuinely didn't have time to finish it. Most of my time went into reading and figuring out what the question was even asking.
By the end of the interview I noticed he apparently didn't know that in Java, a Deque can be used as a Stack.
The problem he gave was so long-winded and roundabout that even now, writing this report, I can't manage to summarize it concisely. Maybe my writing just isn't good enough.
At the end he seemed too lazy to even let me ask questions — he only remembered to ask, as a formality, if there was anything else I wanted to say. I asked a couple of questions about the role and the company culture, and he gave perfunctory answers, no more than two sentences each.
Sure enough, I got the rejection email the next day. Honestly, I feel like that's about right. During the interview he kept mentioning that no matter what position you're in there, it's mainly just writing code, because their resources are very limited — basically everyone is just cranking out code nonstop. I get the feeling working at this company would be miserable. Whatever, doesn't matter.
Discussion
Loading comments…