Databricks Software Engineer Interview Experience — Passed the Phone Screen, Tripped Up by an Unusual System Programming Onsite Round

I got rejected.

Overall the interviewers were all pretty nice, the whole process moved fast, and HR replied quickly too (feels like the grind-heavy companies all reply fast). It's just that they kept using the word "smart" — coworkers are all smart, they only hire smart people. I just wanted nice coworkers; "smart" doesn't really appeal to me at all, it actually made me feel some pressure. It felt like Databricks has a pretty high proportion of Chinese employees.

Phone screen: findOptimalPath, plus a follow-up on not restricting the mode of transportation, plus complexity analysis. Interviewed in the morning, got notified in the afternoon that I'd passed, and talked to HR about the onsite that same day.

Scheduled the onsite for about two weeks later — four rounds in one day: 2 coding + 1 BQ + System Programming.
Coding 1: House Robber, plus a variant where you can't rob both the first and last house at the same time.
Coding 2: Delete Interval, plus how to handle streaming data.
BQ: brief intros from both sides, then have you ever run into conflicts, then the project you're most proud of — they dug into that one for half an hour, asked very detailed questions.
System Programming: I'm guessing this is where I blew it. The level I was interviewing for was the one below senior — IC4 or IC2? Based on other people's interview reports, it seems like anything below senior usually gets System Programming, which is concurrency pseudocode. But honestly I'd rather they'd asked system design instead. It was so non-standard... but maybe that's just the trend now. This was the first concurrency/distributed-systems interview I'd ever had. They gave me a code link to write in — there's a cacheFile class with a method that fetches a file remotely, taking filename and size as input. Then there's an API client you can call directly, with offset and length as input (I forget the exact details), and they ask how the client should read/write efficiently. Something about handling per-request offsets. I hadn't seen this particular report before the interview, so I'd prepared a bunch of stuff about data writers and basically none of it turned out to be useful (kind of similar, but also pretty different). When I saw the problem I was a bit lost, and I definitely didn't answer it well. If anyone has ideas, feel free to share.

You could tell something was off — before this, HR had been updating me the same day or the next day, so when I waited two or three days I basically knew it was a fail. In the end it took two weeks after the onsite for them to tell me I didn't pass, and they didn't share feedback.