Interviewing 2 Years in: What Worked
I’m almost pee-my-pants excited to announce that next week I’ll be joining the team at Braintree and Venmo to work on their JavaScript SDK.
Now that my job search is over, I want to share the lessons I learned from interviewing as a software engineer 2 years into my career. Most of these are not new (or specific to being 2 years into your career), but these points are what specifically helped me the most.
1. Take debrief notes
The first lesson I learned was: take notes directly after every interview.
Over the course of my job search, I filled up 2 notebooks with two kinds of notes: general algorithm and data structure refreshers, and debrief thoughts I scribbled down after my on-site interviews. The debrief notes mostly consisted of writing down the questions I was asked, what answer I gave, and any corrections the interviewer gave me when I asked about the question after the interview.
Taking debrief notes was the single most useful thing I did in my interview preparation. It made any further preparation much more focused and effective, and it kept my morale up after rejections by offering specific actionable things to improve upon for the next one.
2. Security is always in question
In other words: even if it’s an algorithm question, you always have to be vigilant about security.
I was asked an algorithm question using browser JavaScript, but an unrelated (but included) piece of code opened the chance for a XSS vulnerability. I was too deep in algorithm mode to notice it.
3. Write down your interviewers' names
- Bring a notebook to your on-site interview
- Most times a recruiter will meet you in the morning and will be carrying a list of all your interviewers' names
- Ask to see that list and copy it into your notebook
Being able to know the name of my next interviewer so I could go up and greet them already knowing their name was a huge confidence booster and helped set the tone of the interview off on the right foot.
4. Don’t sweat the esoteric stuff
This was my first time interviewing at “the big companies,” the ones whose interviews you read articles about. To my surprise, the breadth of technical knowledge required in these interviews wasn’t as encycolpedic as I had expected. To attempt to sum up my experience in this regard: companies, for the most part, were looking for elegant solutions to variations on well known problems.
Concentrating deeply in an SF cafe for an entire afternoon trying to memorize how to delete a node from a Red-Black tree, in hindsight, was a big waste of time. Most of the esoteric material I covered in my nervous conquest to know everything possible before my interview had very little measurable benefit. Gayle Laakmann McDowell, author of Cracking the Coding Interview (mentioned below) brings up this exact point in a conference talk.
I was more helped by the side project I was working on at the time, which, incidentally, featured an algorithm that showed up in one of my interviews.
It’s been said already but I can’t stress this enough: working on technically challenging side projects outside the scope of your day job is extremely helpful for growing in a way that is rewarded in technical interviews. Not only does it prepare you better than rote memorization or challenge solving, it has the added benefit of giving you something to be extremely passionate about sharing with your interviewer.
5. You can reverse!
Finally, a small realization that helped me a lot: your technical interview answer does not have to be in one swift intellectual blow.
If you’re going down the wrong path, you can say “hey, this doesn’t look like it’s going the right way, I’m going to back up and try this a different way”. Not only was I not penalized for doing this, the company this was at specifically said that doing that was one of the main reasons I made it to the next round of interviews.
Resources consulted
- Cracking the Coding Interview
- This book is what informed most of my preparation. It was invaluable in guiding my entire approach to interviewing.
- CLRS
- Very useful for reviewing the basics, although tempting to dive into deeper, more esoteric stuff as mentioned above.
- The Algorithm Design Manual
- Bought based on a message board recommendation - the 2nd half is a glossary detailing all kinds of problems you might run into and what algorithm or data structure to use to solve it.
Time spent preparing
Between January and March 2014, spent most Saturday and Sunday afternoons in a coffee shop practicing and studying.
Preparation methods
- Coded data structures and algorithms from scratch in C++ (as suggested by Cracking the Coding Interview)
- Worked on side projects (as mentioned above)
- Practiced problems on other offices' whiteboards
- Topcoder
Reasons for leaving Bloodhound
Working at a small startup (Bloodhound) gave me a breadth of knowledge I don’t think could have been acquired in a larger company. The choice between a startup and a bigger company seems similar to the choice of a big university versus a small college. You grow in different ways at each, and to have an optimal experience I wish I could have done both.
Why I chose Braintree
Working at Braintree presents a couple unique opportunities that really appeal to me:
-
I’ll be working on a product marketed toward developers. This means that the code that I write will have to stand the scruitiny of the general public and developers far more skilled than I.
-
Venmo places a large emphasis on community involvement and giving back in the form of open source and giving educational talks at conferences.
That’s all! Let me know in the comments if anything could be clarified. Big thanks to Elva Fan for proofreading.