After months of interviewing and preparation, I was lucky enough to receive employment opportunities at two highly desired companies - Amazon and Google. I've tossed together some of my general and technical reflections on the process, which might benefit those who are curious or are going through this themselves.

Process and Timeline

This is a general outline of the process. There's some minor idiosyncracies between the two companies, but the general flow was the same:

1. Intial Recruiter Contact
2. Recruiter Phone Screen
3. Technical Screening
4. Onsite Interview
5. Team Matching & Offer

General Thoughts

Between both companies, there are some common experiences and thoughts that I had while interviewing. The first is making sure you're well rested, and bringing a sleeping aid if you can stand them. It doesn't matter how much you prep, a bad night of sleep can ruin it.

If you're given one, take advantage of the "off-record" lunch to ask some more touchy questions like work/life balance, support responsibilities, stress levels, etc.

Another thing that I think are often understated in most other advice articles are soft skills. Make sure to smile and be friendly. Try to be confident, even though inside you're probably a mess of nerves.

The last general thought I had was to be prepared with intelligent questions for them! Don't be the person at the end who's like "nah, no questions for you, bye!"

Technical Tips & Thoughts

Firstly, I can't overstate the importance of talking out loud. This is at the top of the list for a reason. You've heard it already I'm sure, but make sure to explain your thought process out loud.

As far as technical skills, there's a few that are must-haves in my experience. You need to know big O complexity, no way around it. That includes both evaluating algorithms, comparing different complexities and knowing common algorithm's complexities. As far as algorithmic knowledge, aside from basic data structures, you should probably be comfortable with dynamic programming, graph traversal and BST's.

It's also important, but perhaps not critical, to know your favorite language and common APIs. If you forget during an interview, just be honest. There was one point I couldn't remember the API for Java's StringBuilder and just said so. I couldn't remember if there was a delete function, and the contract, but I just pretended there was and the interviewer was OK with that.

The last technical tip I have is to abstract simple functions and implement them later. For instance, if you need to do something like lookup a value from a hashset, do some math on it and then do something with the value, stub out a method like retrieveValueAndCalculate(key). You can then continue on with the core algorithm and actually write out that implementation later. Or, better yet, buy yourself some more time and ask the interviewer "so this method is pretty simple, we just get the key and do X to it. Do you think it's worth writing the code for it?"

Coding Interview Walkthrough

• Ask lots of questions, and present multiple solutions. My general flow was to first ask as many questions about size limits, overflow, input validations, etc. that I could think of. Next, start spitballing as many possible solutions as you can think of, their big O complexities and their trade-offs. Don't spend more than 5-10 minutes on this before settling on whatever you think is best. In general, I think it's better to favor runtime over space. It doesn't hurt to ask the interviewer "hey, this one seems like a pretty decent solution, and I'd like to move forward with that unless you think there's something better I'm missing?"
• Next thing is just iterate through the algorithm, writing the steps down in short-form. For instance: step one, check if null and in right range. Step two, iterate through until N. Step three.....etc. I got direct, positive feedback for doing this, and it helps solidify the algorithm when it comes time to start writing the actual code.
• Next, write compilable code! One thing I could have definitely done better at is writing small, and being thoughtful about variable names. There won't be enough board space, and you will eat into your time if you name a variable countOfTotalValues and have to rewrite it multiple times.
• Once done, walk through some quick input if you have time and self-reflect. "So, given the input X, Y, Z, we'd do this and that and...yep, looks like the correct output. If this was production code, I'd want to write some tests for input A, B, C. I'd also probably extract this portion to a helper function to make it more readable, and this section might need a comment explaining it, since it's not really intuitive."
• If you have time, the interviewer will likely ask follow up questions and throw a few wrenches. In my experience, I didn't often have time to write code for these but just discuss the approach and how it might change.

Closing Thoughts

The interview process at these larger software companies is pretty intense, and requires tons of upfront preparation. Trying to study, let alone find time to interview, while working fulltime was pretty difficult to manage. And at the end of the day, there's so much luck that goes into this process: luck that you get agreeable interviewers, luck that you are at full health and performance the day of your interview, luck that you even get your foot in the door to begin with. So....good luck!