This was a practice interview at the start of my job search. They started off with a "most impactful project" question, and I just answered it off the cuff — I hadn't prepped for behavioral questions.
Then: write a set, but at first they only let me use Java. I used to write Java, but algorithm interviews these days want you to write so much code that I've been prepping everything in Python. This set problem also actually had a fair amount of code to write out in full, so I gritted my teeth and asked to use Python instead — but the interviewer seemed to not understand Python at all (a lead whose level was honestly a bit too low). They also told me not to write a hash function. So I just wrote the loop/list version — a list with a fixed length that could grow and shrink depending on the amount of data — and talked through the time complexity, and how you could improve it by hashing the value into an index.
Then with twenty minutes left, out of nowhere the interviewer asked a second question, about streaming batch processing. I didn't expect there to even be a second question — I guess because I'd already covered hashing on the set problem and even brought up multithreading, I figured there was nothing left to ask. Switching to a completely different problem threw me off and cost me some time to reorient. I wrote some pseudocode, then used a thread pool to process writes to the DB in parallel. After I finished the code, they asked whether this even counted as batch processing — turns out the DB already had its own batch-processing API, and the real point of the question was caching combined with multithreading. I thought I was being tested on multithreaded read/write handling — my fault for not asking — and I didn't have time left to change the code, so I just talked through the approach. In the end, the interviewer failed me anyway.
Discussion
Loading comments…