The Silicon Valley Interview

So I’ve been dead for awhile, but mostly because if I’m not working, I’ve been interviewing for new positions at companies I really like. I’ve actually accepted one of the jobs I was offered, but I think what’s really important is to talk about what it was like interviewing for some of the top names in tech in the Bay Area and what you should expect when you’re interviewing for them too, because it is literally nothing like what I have experienced before.

The Usual Interview Style: PHX

I’ve been in the Phoenix tech scene for ages, so I’m pretty used to breezing through interviews for decent tech companies here in the valley of the sun. They usually consist of four rounds.

  1. Phone Screen to make sure you’re not a rapist/serial killer/liar
  2. Technical Interview of the most basic stuff (Do you know what Javascript is? Do you even know what a computer is?)
  3. Culture Fit Interview
  4. Offer


It’s probably the most low stress series of events in job hunting history. I don’t know if this is due to the fact that Phoenix has a shortage of tech workers, or we’re just generally chill people who are trying to make cool things and live our lives. I love Phoenix Interviews, and because of this I was a little spoiled in my offerings. However, on a whim, I tried for the bay area.

The Usual Interview Style: SF


Culture Fit Interviews make me wonder what culture these people are from

If you were a tree, what tree would you be?


One of the many weird culture fit questions that I was asked by HR people while I was interviewing to see if I worked well on their team. SPOILER: I said I was a pine tree There seems to be a lot more to being a culture fit on these high paced development teams in the bay area than just “Are you chill? Are you a murderer?” I guess that’s the luxury of having a lot of applicants for few positions. I had read up on the infamous Google brainteasers however in the initial interviews I was asked very strange metaphysical questions by interviewers one after another.

What kind of cereal are you most like?

I felt like I was back in PHI333: Intro to Existentialism all over again. I tried to answer everything as best I could. I generally think I’m a good person to get along with, but am I a tasty cereal? Am I a good tree? I hope so.

Who would you invite to lunch, alive or dead?


I feel like a lot of these questions are asked on those tumblr ask memes. Good thing I never do those.

Anyways, I want to get into the bulk of this blog post, which is the technical interviews and screening.

Whiteboard Style Interviews and You


Everyone on twitter that lives in SF is no stranger to these whiteboard style interviews, but I was, and I feel like a lot of my blog readers might be too. So I’ll go in depth into this style of interview and why I was lucky enough to know about it before hand. All of my interviews were structured around this type of interview style.

A whiteboard style interview is a lot of gross sobbing as you realize you will have to write all your code out, by hand, and explain yourself, on a whiteboard or a trendy glass window like an episode of Criminal Minds or something. You will have to know basic algorithms, problem solving, without having syntax highlighting, or google. In fact, the only thing you’ll have on your side is Jesus (maybe).

One interview was six hours of whiteboarding. For real.

How to prepare for this

Rote memorization helped. I am completely self taught as far as programming goes. So I didn’t know a lot of sorting algorithms had names, and I didn’t know Fizzbuzz was a thing. I really have never needed to do recursive fibonacci sequences while I was writing a wordpress plugin. A lot of these things are easy concepts that people learned in their CS classes, but since I had never stepped foot in a CS classroom and tested out of the only one I needed. I was on the losing side of all this business.

Some links I used to study (religiously):

I just went through the code and wrote it over and over again until I had it memorized, grab a whiteboard, and be able to explain to your cats, and your mom, each step of the code. I broke it down even further by laying it all out in logical steps.

  1. What is the goal of this code?
  2. What steps need to be taken to achieve that goal?
  3. What needs to be done to achieve step 1, step 2, etc?
  4. What tools can be used?
  5. Can this be made faster?

In the interviews (and when I practiced at home) writing these out first not only helped establish my thinking, but showed my thought process to the interviewer before I had to do the hard part: writing the code. When I wrote the code, I’d try and write out pseudo code first for each step, and then rewrote it again as real code before I moved on. Double checking everything once I was done.

Technical Interviews: Pushing the limits

I was given a lot of things I didn’t know how to do when I interviewed for companies. These were things I knew I didn’t know, and I knew the interviewer also knew I didn’t know. This is about when I have an existential crisis and lay on the floor of my living room and listen to Death Cab For Cutie and think about going into food service. However, I asked one of them after why they did this to me, and if they hated me, or if I had done them any wrong and they were very poignant in their answer.

“We want to see how you react to something you don’t know.”


These aren’t questions that I was supposed to be able to solve, not by a long shot. Why would a front end developer need to be able to write cron jobs for Telnet? Why would a front end developer need to know how to write shell scripts period? My first instinct was my bff The Imposter Syndrome: “Maybe all developers secretly know how to write shell scripts to pull CSVs from switches.” My second instinct was: “How can I solve this with my very limited knowledge of network and CSVs?” I think every developer can give kind of a 10,000ft view of a problem. Once you start talking it out, you can probably fiddle your way through the rest of it. Make every problem a conversation you’d have with a senior developer on your same team. Don’t think you’re in this interview alone. When in doubt, talk it out!

If I wasn’t being asked how I would reorganize a 500 server data center over the phone, I was given coding challenges to compete in my own time. Use all your resources, and I mean all of them, to complete these. Stackoverflow isn’t cheating.

Things I took away from SF Style Interviews

There was some ridiculous blog post that I posted on here about being a “Full Stack Employee” and I want to talk about that from a programming standpoint. A lot of these companies don’t have any clue where the lines blur for a Front End and Back End Developer, and in that note, a lot of these companies don’t know that there is a huge difference between Developer and Engineer. Because of this there was a lot of discrepancy between what the job posting asked for and what the job interviews actually were looking for. I came into interviews with a strong background in Javascript, CSS/SASS, HTML, etc. However, I was asked why I didn’t know a lot of backend languages, or architecture. I felt like I was vastly under qualified for jobs that I thought I was very well qualified for. This is not only frustrating for me, but I know it’s frustrating for the companies. We’re both wasting our time if you’re posting for developers and you’re looking for engineers, or if you’re looking for Full Stack and you only ask for Front End.

In the end, I did choose a Bay Area company to work for, and I’m moving away from Phoenix mostly to see if I can cut it in Silicon Valley. The culture is vastly different from Phoenix, and I will miss the tech culture that has brewed here in the desert. In Phoenix there is a lot of working together with no egos and no bullshit. I feel like in tech, we’re more open and collaborative because we’re a smaller community and we have strength in numbers. I hope San Francisco is the same way, and maybe I’ll report back once I know better.


NOTE: I will be resuming regular blog posts once I finish moving!