Location Canada
BS.C Comp Sci
9 YOE - fairly large companies, non faang

Recruiter - was very nice and helpful. He gave me a lot of resources and instructed me to attend a facebook organized workshop detailing the interview proccess and what they like to see.

Study - I did about 20-25 questions on LC all medium/hard

Interview:

The person doing it was very nice and friendly. I felt he gave good hints and only when it seemed i struggled with something.

First question was

Implement a shell function to move directories, ie:

if user is in /home/user and they type /../../var/www/..

What's the final result...? ie-- /var

I had not seen it, used a stack approach. Was asked a followup question to handle if the user inputs something like /..../ (more than 2 periods)

Got that part done as well.

Second question:

Given an m x n matrix, print the diagonals.

Never seen this before, the diagonals all went one way and i solved it using a recursive approach, i wrote most of the code and got stuck for a solid 7-10 min on something incredibly silly. A few hints from the interviewer made me realize i made a mistake in my thinking and was trying to solve a problem that didnt actually exist...

I was not asked about space/time complexity. I completely forgot to mention it, but both were super straight forward problems and required no optimisation.

Received an email the following day to proceed to next steps.

My 2 cents:

I've conducted interviews for the last 3 companies I worked for. For one, i made final decision on hiring. They were no where near FAANG caliber, much easier. But the same idea..

• knowing the answer to the question is not a good thing, imo. The point of the interview is to determine your problem solving skills, how you deal with pressure, how well you communicate etc.. if you can regurgitate the code and solution it shows you can memorize and nothing else.
• not knowing the problem is good:
  • You have to understand it and come up with an approach. This requires back and forth, it shows you can extract information and ask relevant questions.
  • Your approach will almost always be flawed for hard questions, you have a hard time limit. That's the point.
  • You should hit a snag and be able to talk and figure your way out of it.
  • Hopefully you produce working code in the end.
  • This is what they actually want to see..
• practice, it's good, the mindset is different. If you know the problem, say you do (they'll know if you lie..), get it done quick and a good interviewer should ask you a follow-up on it that challenges you and tests how well you understood the code you regurgitated. If you solve all problems from memory because you've done it, the interviewer will have little to judge you on.
• the goal of practice is to determine the "class" of problem. If you can read it and say "This is a DP problem" .. or "this requires a heap" then you are in a good spot.

Will i pass the virtual onsite.. probably not :). I have little time to study, so we'll see how lucky i get on the questions. I will post a follow up..