How to Prepare for the Silicon Valley Interview - Part 3

written in hiring, interview, interview-series, interviewing, job, silicon, tips, valley

This is the third and final post of the Interviewing in Silicon Valley series. In this last piece I talk about how to make the most of your on-site, how to handle rejection and how to compare competing offers.

Low-risk interviews

I have to confess; at first I was terrified about doing interviews. It had been almost 5 years since the last time I was interviewed back in Argentina. Fortunately, my friend Luketua1 was there to give me a great piece of advice: ”just commit to one and do it, what do you have to loose?”. And it worked! I discovered that one of the fastest ways of overcoming fear is facing it head on (the second ride on a rollercoaster is not as scary as the first one, right?).

So, take that first step! Pick a company you find interesting, but it’s not your first choice and schedule an interview. Even if you completely screw it up, you will at least have the experience of having gone through it, so the next time won’t be as bad. As a bonus, you’ll get a sense of which topics you need to focus your practice on. Just close your eyes and take the leap, you’ve got nothing to lose.

Scheduling the on-sites

On-sites take time, they last from 4 to 6 hours. And you end up exhausted after one so forget about catching up on any work you were supposed to be doing in that time. That’s why, more often than not, you’ll need to get the day off (or at least half-day off) for the on-site.

You’ll want to schedule your “first-choice” round of on-sites close in time for 3 reason:

  1. You have a hard deadline for when to finish your practice.
  2. You might get rejected in some of your options. Having to start the process from the beginning in another company by then could mean waiting a whole month until the next on-site.
  3. Having competing offers will help you in the compensation negotiations.

I’ve heard some people schedule all the on-sites for one week and then take the whole week off. I didn’t do it this way but it sounds like a solid approach. Specially if you know that the process timeline is similar in all the companies you’re interviewing for.

Final piece of advice: In my experience, it’s better to be transparent with the recruiters and let them know you’re interviewing for other roles. They can help you accommodate your schedule and manage the hiring manager expectations.

The on-site routine

The day of the on-site you’ll probably have a lot on your mind, so it’s better if you just follow the same simple routine. This is what I came up with after many on-sites:

Mindfulness is something I’ve just recently discovered. I was introduced to it through the book Waking Up and have started practicing meditation using the Headspace app. I usually did a 15/20 minutes meditation before the on-site and found that it helped me relax before going in.

Your perception is not predictive of performance

This is something I heard first at this Silicon Valley Code Camp talk. If you start to feel the interview is going south, don’t panic! Just keep going. It might be that you were given a hard question, in which case you might not be expected to arrive at an optimal solution in the given time (and in any case, all other candidates will probably struggle through the same question). Or maybe you sense your interviewer is impatient or annoyed. Don’t assume it’s because of your performance, maybe he’s having a bad day, or that’s just his personality. The point is, you just don’t know. Here it is in Gayle’s own words (the whole talk is really worth it):

Of course, I learned this the hard way. On one of my on-sites I was struggling with an exercise that looked trivial to me. I ended up arriving at a solution with some help from the interviewer, only to give the wrong answer when asked about the time complexity. To make things worst I was not able to come up with any good improvements to my solution. I was sweating bullets and had to fight the urge of escaping from the interview. Imagine my surprise when, on my way home, I received an email saying that I made it to the next step of the process. Bottomline: You don’t know how you’re doing. Just keep going.

Interviews are a two-way street

One of the best things I learned about interviews is this: interviews are a two-way street, you’re evaluating the company as much as they’re evaluating you. Interviews are your best chance to learn about the company, the role, the culture and your future teammates, so don’t squander it!

By the end of the interview you’ll be ask if you have any questions. I always say yes, and follow with one of this:

  • How do you prioritize tasks? How do you make decisions? How do you handle interruptions? (Ask about hot bugs, devops, CI/CD, etc.)
  • What do you like the most about working for this company?
  • What’s one thing the team should improve on?
  • What’s on the roadmap for the team?
  • What are some of the challenges I’ll be facing in this role?

One more thing: don’t play it safe. If there’s something that is a deal-breaker for your just be direct and ask about it. After all, you’re better off knowing things in advance, and you give the interviewer a chance to clarify on the issue. For example I asked one company why they were using an outdated stack and another one about the recent articles regarding its toxic culture. As long as you’re polite about it nobody is going to get pissed off. If anything it will show that you really care and you are comfortable speaking your mind.

Rejections

You will get rejected. Everyone is at some point. Rejections are just part of the interview process. If you’re not being rejected, you’re probably not interviewing enough.

The golden rule to handle rejections is: don’t take it personally. Doing bad in an interview says little about your abilities as a software developer. Maybe there was a candidate that was a better fit. Maybe you had a bad day. Maybe you should practice more graph related questions. The first 2 you can do nothing about, but the third one you can. Which leads to the second rule of rejections:Always ask for feedback. The best thing you can do is learn from your mistakes.

Once I was applying for this startup that made me do a take-home exercise. I spent the best part of my weekend working on it. First I solved the problem, then I tested the code, then I refactored everything nicely into easy to read functions, then I added some more tests and even documented them using ASCII graphs (for real). When I sent my submission on Sunday I was honestly hoping the company would be so impressed they would realize there was no need for an on-site. Two days later I got an email: “…we have decided to move forward with another candidate…” 😢. So, with my ego hurt, I decided to answer back asking what I did wrong, and they nicely enough responded back pointing out my mistakes. Turns out my code performance sucked! In an effort to make the code super readable I had utterly destroyed performance. Needless to say I never made the same mistake again.

The follow-up

The obvious thing to do after an interview is to follow-up with a thank you email. Now, the smart thing to do is to follow-up with questions. During the interview you’ll get a glimpse of what the company is working on, you’ll learn about what technologies they use, and how their systems are designed. Naturally, you’ll have lots of questions that you didn’t get to ask during the interview, either because of time constraints or because they didn’t occur to you at the time (if you don’t, then maybe you’re not really that interested in what the company is doing). Now is the time to ask! Make sure to include them in your follow-up email along with any other comment that comes to mind.

Pro-tip: Use Google alerts to set notifications for new content about the company, so you’ll always know what they’re up to. This way I learned that the CEO of one of the companies I was applying for, was a guest in a podcast and got to ask him about some of the topics he talked about afterward.

The offer

This is how an offer might be structured:

To compare competing offers you’ll want to get the yearly compensation so:

If you want to be thorough (and you should be), you should also consider the vesting period (4 years with a one year cliff seems the most common) as well as financial benefits such as matching 401k and employee stock option plans.

Startup offers are trickier to evaluate because of the risk factor involved. If you’re applying for a startup, and your offer includes equity I strongly suggest you read this guide to learn how to understand and compare equity compensation.

Finally, there are a number of things you should consider, other than compensation, when evaluating an offer. I’d say that some of this things are equally or more important that compensation.

  • Who are you going to be working with?
  • Do you find the problems challenging and exciting?
  • What kind of things you’ll learn at this role?
  • What’s the company’s culture?
  • How is the company doing and what’s its growth projection?
  • How this role will look on your resume?
  • How are the offices? And how long is the commute?
  • What kind of benefits and perks does the company offer?

Bonus track: Advice potpourri

Before you go a snack size list of random advice

  • Smile!
  • Keep a playful attitude. Approach the interview as a game or challenge. Try to enjoy the process (I swear it’s possible, specially the times you’re killing it).
  • The interview is not over until the interviewer says so. Until then, keep solving, improving and testing your solution.
  • You don’t have to answer how much you’re making in your current job. In some states (CA included) it’s even illegal to ask.
  • Don’t give up! Companies always let you re-apply after some time. I know a guy that got accepted at Google on his 4th attempt.

Ok, I guess that’s the end of the Interviewing Series. If you made it here you deserve a cookie 🍪. Hope you found something useful, and thanks for reading!

Special thanks to: @rcruzjo, @patriciob, @pgveiga and @luketua for helping me edit and improve this series.


  1. Check his blog: [Codex Transforma][3]


Comments