Earlier this year, I started to look for a job and one of my friends recommended this post written by Bharath, a former Uber ML engineer who also had to find a job earlier-er this year but in a much more stressful situation, i.e., within 60 days. The blog post was amazing. I basically followed the author’s process with some adjustments for myself, a human-robot interaction researcher who just finished grad school. In this post, I’ll talk about my job search experience and my adopted process based on Bharath’s process.

On identifying which role/company to apply

For a fresh-out-of-school, human-robot interaction researcher with some experience in software engineering work in the industry, the biggest challenge was people didn’t know what was I good at or what I wanted to do. A part of it was due to the nature of the human-robot interaction or robotics research field that has a wide range of subfields. Another part of it was me; I had the roles I wanted to take in mind but I was not sure whether I will be good at it so the companies will hire me for the role. One of my mentors recommended ikigai for career-related decision making and it helped me take the first pass on identifying which companies to apply. After that, I decided to apply to a wide range of roles (e.g., Software Development Engineer, Applied Researcher, Product Engineer, etc.) across a wide range of companies (e.g., ~5 people startups to BigCos) to find the right role by interacting with companies.

I started by following “The Process” in the “Reach out to everyone” section in Bharath’s blog. I made a list of companies, reached out to people related to a target company, iterated those two steps until I had a list of ~20 companies that would talk to me. I reached out to over 50 people–seniors, juniors, friends, friends of the family, any who would talk to me about a role similar to the ones I identified earlier. The reaching out process was laborious and sometimes humiliating but it was extremely important in retrospect as it turns out some very interesting roles that were not public were found this way.

Sometimes the “speaking with a hiring manager” step naturally happened and I’ve used Bharath’s notes for preparing myself for those meetings. Whenever I get to talk to a hiring manager or an employee at the team I want to join, I tried to ask as many questions as possible about the role, e.g., a list of selected questions from related articles like this and this to really visualize what I would be doing in my 1st year and after. I also asked some questions about the interview process and interview tips to tailor my preparation to a particular company, if needed. For example, smaller companies’ interviews were less structured while big companies’ interviews’ were highly structured, e.g., for Amazon, see this. After talking to a hiring manager, I was able to gauge 1. how interested the company was in hiring me and 2. what they were looking for (e.g., robotics application building, robotics user interface design, evaluating interactive robot systems, etc). I was also able to feel out whether I have the experiences and skills they were looking for. This was extremely useful for narrowing down the list because I was able to ask myself how much effort do I want to put in trying to convince a company why they need me or how quickly I can learn the missing skills. After this step, the number of companies in my list reduced to ~10. I followed up with a recruiter or hiring manager to start the first step of the interview process, which usually was a coding interview.

Preparing for coding interviews

Coding interviews always scare me. Following Bharath’s process, I started solving a couple of leetcode problems every week, was being very selective with which leetcode problems to work on, and studied patterns and categories of coding problems to identify my weakest patterns and categories. Even after such preparation, I choked during the first couple of coding interviews but was much more comfortable in later coding interviews. For my coding interviews, most companies used a shared coding platform like CoderPad and others asked me to share my desktop screen to see how I code in my own environment; some, usually smaller companies, gave me “homework” or a tiny project to work on. I liked live-coding interviews with a shared coding platform because it saved my time the most.

Preparing for system design interviews

Bharath said system design interviews were his favorite. For me, system design interviews were the most difficult. First, the existing system design interview guidelines (like this (free) and this (paid)) were not tailored to the robotics problems, and second, I’ve learned that system design interview experiences varied a lot across the companies. I also had a hard time finding a friend or peer who would act as an interviewer to help me with the preparation. I started by creating robotics system design questions based on existing example system design questions with solutions. Here are other questions I’ve considered:

  • Design an object detector for a mobile manipulator robot for pick-up tasks
  • Design a collaborative robot manipulator for an assembly task
  • Design a teleoperation interface for a mobile robot

However, based on my interview experiences, some system design questions I’ve asked required having good intuitions on robotics (or robotics perception or motion planning) algorithms to be able to discuss the trade-offs of using different approaches and practical implications for building robotics systems. Or an ability to map the questions that seem not-so-related to a robotics problem to a robotics system design problem and discuss the approaches and trade-offs or related issues the interviewers are looking for. Based on post-interview feedback, the interviewers seemed to look for the interviewee’s ability to clearly communicate to gather requirements, identify a problem, propose multiple approaches, discuss trade-offs, and making calculated decisions–ideally while demonstrating experiences in related, industry-standard tools and frameworks.

Preparing for core concept interviews

For me, a very few interviews involved asking about core (robotics) concepts; probably because I only made/pursued a very few research positions. Here I followed Bharath’s process and created a basic ML & robotics concepts list for myself. For each algorithm, I asked the following four questions:

  • What is it?
  • How does it work? (time/space complexity?)
  • When do you use it?
  • What are the limitations? Practical considerations?
  • Anything else? (personal experiences and findings, etc.)

Preparing for behavioral interviews

Bharath’s notes helped prepare behavioral interviews. One strategy I like to emphasize is tailoring stories for an interviewer or company. Tell stories about technical success stories to engineers, research success stories to researchers, leadership success stories to managers.

Closing notes

I want to re-emphasize the importance of sourcing many interview opportunities. My peers recommended doing this as one may not know whether a role is interesting until talking to people in the team (i.e., reading job descriptions are not enough). Another important factor in hindsight is timing. I considered job searching in May and June and I could not get any interviews. I got lucky and was able to delay the search for about 2 months and there were a day and night difference. Timing is something one may not have control over, but if you do, talk to many people (and use other resources) to see how many opportunities are/will be there in your job search time frame.