Interviewing Experience in SF

End of November 2022, I saw a pretty cool demo from this AI startup out of San Francisco, and as I was looking through their website, they were hiring. I do not have any AI experience at all other than playing with ChatGPT, but I figured a frontend role likely won’t require any AI experience and I could learn about AI by being surrounded by the experts. This is the first time I’ve ever applied to a job out of San Francisco and although I did not end up with an offer, I thought the experience was quite interesting and worth sharing.

Before I talk about the process, here is a little bit of background context:

• The role - Full-time Frontend Engineer, located in San Francisco, in-office
• The company - A well-funded AI startup, ex-Google founders, “let’s change the world” kinda company
• Interview Timeline - The whole process (including initial application) took approximately 3 months

So, I thought it would be useful to go through this as per the steps I went through from start to finish. I’ve also added whether that step was performed remotely or on-site and if remotely, whether or not it was done asynchronously or synchronously (e.g. video chat). Here are the full-steps if you’d like to jump ahead.

1. Application (Remote Async)
2. Screening Call (Remote Sync)
3. Take Home Assessment (Remote Async)
4. Technical Screen - Frontend (Remote Sync)
5. Technical Screen - Algorithms and Coding (On-site) x2
6. Systems Design (On-site)
7. Culture Fit (On-site)
8. Technical Screen - Frontend (Remote Sync)
9. Feedback Session (Remote Sync)
10. Final Thoughts

1. Application (Remote Async)

The application was a pretty standard form, with submit your resume, LinkedIn, portfolio, as well as a few general screening questions, e.g. Why do you want to work for us etc. So I submitted mine and waited. No confirmation of receipt, and no communication until approx. 2 weeks, when I received an email from their recruiter mentioning to book a session with their hiring manager.

2. Screening Call (Remote Sync)

The screening call was with the person who would be my manager if I was offered the role. I thought that this was really great as it allowed me to ask more specific questions around the role and what his expectations are around work-life balance and general team structure. I was also able to gauge whether or not I would be comfortable working with this person. I’ve had other screening calls before with an internal recruiter and it has generally not been a great experience as they aren’t generally able to answer specific questions about the team and what you would actually be doing in the role.

3. Take Home Assessment (Remote Async)

For the next step, I was given a choice whether to complete a HackerRank challenge or a take-home assessment building a particular product. I chose the take-home assessment as I don’t think the HackerRank challenge really showcases your skills or more importantly, how you would actually build and deploy a project.

The task provided was basically using OpenAI’s API to power a basic calendar app in any framework of my choosing. I thought they did really well in providing the scope as well as the basic repository structure for me to use. They also provided a set of functions that interacted with OpenAI’s API, so it was focused on the frontend itself. Submission itself was just a zipped folder of the repo that I emailed back to them, nice and easy.

4. Technical Screen - Frontend (Remote Sync)

The next step, was a Frontend coding interview. I thought this was an odd thing to have after the take home assessment. Especially as it was not in any way related to the take-home assessment.

I personally thought that this step was ill-prepared. The assessment, which was to create a React component that interacted with OpenAI’s API felt repetitive. But, compared to the take-home assessment, the library provided was a little more open-ended and some AI prompt design was required. For anyone who has played with ChatGPT, probably knows adjusting prompts takes some time and is an art in itself. Not something that can easily be done in a 45-min slot as part of coding other things.

The other issue was the fact that it seems like the interviewer seems quite early in their interviewing journey. For someone who has been on both sides, I think it’s a great opportunity given to him by the company to learn how to interview others. But ideally, they should have really had another person there to guide him through the interview process or had him assess a more prepared assessment.

5. Technical Screen - Algorithms and Coding (On-site) x2

The next few steps were done in a single day in their San Francisco office. The day started off with two algorithms and coding problems with 2 different interviewers, other members of the team. The first was performed on a shared IDE and the second on a combination of a whiteboard and my own IDE.

Generally speaking, I’m not a fan of these types of interviews as it doesn’t translate well into your day-to-day. But it does show how well you will work with different people in the team. Something I noticed here was that neither of the interviewers are frontend developers and so these problems were not specifically frontend problems, just general coding challenges. I did think that they did well in designing it to mimic some of the issues they may face in the Large Language Model (LLM) space that powers most AI tools like ChatGPT.

6. Systems Design (On-site)

The next on-site step is a systems design interview, where a potential feature was presented and the interviewer is acting as the product owner, customer and all other stakeholders. The interview was with the person who will be my manager if the role was offered.

I thought that this was a good interview to test out the way I thought of problems and potential ways to solve it. In saying that, I am someone who tend to think of things on my own time while having a shower, going on a hike or generally just sitting there with my cup of tea before showing a solution so it was a little nerve-wracking to do this train of thought in front of someone. I would be curious if there were more inclusive ways to perform this type of interviews whilst still getting the benefit of seeing the interviewees process.

As a side note, at this point I was a little surprised that there has been no mention of what I had built for the take-home assessment. No questions, feedback or even any acknowledgment of it.

7. Culture Fit (On-site)

The last on-site step was a culture fit assessment. At least that’s what they called it. I personally did not think it was based on my experience as an interviewer and interviewee of other culture-fit interviews I’ve had.

The interviewer was someone that is part of Business Development and Partnerships, a change from the other interviewers who were all from the development team. The questions that came were the standard, rigid questions around where I see myself in X years, what I’d like to get out of this role, or what feedback have I received in the past, etc.

My expectations for culture-fit is whether or not I shared the same values as most of the people at the company. For some companies, they have their values written down, for others, it is an unspoken set of values. This is why I think that the best culture-fit interview to do is to have a round-table style interview. Place a few people from the company to sit in a table with the interviewee and just have a chat around any topic. You can generally tell pretty quickly if this person fits the mould you’d like to shape or not. What are your thoughts around this? Does culture-fit mean a different thing in SF than elsewhere?

8. Technical Screen - Frontend (Remote Sync)

The next day, I received a phone call to see if I’d be ok to take another interview with someone they had just hired as their first frontend engineer. This explains many of the downsides of some of the interviews I’ve had. I agreed as I’d like to meet the person that I will likely be spending my time with the most if I was offered the role. Plus, it would be interesting to speak to someone with a bit more frontend knowledge.

The first part of this step was again another coding session. This time we are creating a recursive React component, an interesting challenge but nothing too complicated.

The rest of the interview turned into a conversation around the challenges that they face with the chrome extension and how it might be solved. Although this just happened naturally, I think this was a really great example of taking an actual frontend problem and discussing potential solutions that could address it. Which is what most engineers do. The coding itself is secondary to these sort of problem solving.

Although the interview went almost an hour overtime, I thought it was great and is what I would have expected the other technical screens to consist of.

9. Feedback Session (Remote Sync)

Ultimately, I did not receive the offer. I’m a little disappointed but just like anything, I try to use it as a learning experience. So like improving any product, I asked for feedback.

They agreed to a feedback session over zoom with their internal recruiter. Unfortunately, the feedback was disappointing. It was a very vague feedback that doesn’t really allow me to set up some actionable steps to take. And because the feedback session was with their internal recruiter and not any of the 6 people that performed the interviews, I wasn’t able to clarify or expand on any of this. This is probably more disappointing than the results itself, as how do you improve without feedback?

Final Thoughts

My final thoughts on this whole experience is that, it has been very interesting. I clearly need to improve somethings to be worthy of this particular role. Just need to find out what that is. Also, unsure if this many steps for a frontend engineer is normal for companies in San Francisco. It’s definitely double to what I am used to. Let me know your thoughts on this and maybe share your experience on your interview journey!