How I changed my job after 10 years

A checklist for preparing for a senior developer role

Let’s start at the very beginning. A very good place to start. I am a Computer Science graduate from IIT Bombay. From there I went to MSR to do Program Analysis. After a year of research I realized that engineering is what I am better at and enjoy doing. I moved to sort of a dream company for most young operating system enthusiasts — VMware. This was August 2008.

Come October 2018. My current team is VMware’s own baby about a year old and growing up fast. It is such a favorite that even VMware’s CEO Pat Gelsinger hasn’t stop gushing about it even after a year. Of the four major components of this product I owned one (let’s call it UW) and worked extensively on the component that runs in the guest. I designed, architect-ed and wrote UW from scratch. I had great team mates who helped with all this and were an absolute joy to work with. Why then oh why did I leave a product meant to be VMware’s next billion dollar business, an almost guaranteed career path to success and great teammates? (I almost forgot to mention VMware’s stock price has been around it all time high price for the last few months and looking up).

My top reason is that I felt I was stagnating. Being “too comfortable” is a good place to be in but not great. I was in a large company with little or no risks, a bubble I could easily spend another 10 years … comfortably.

Starting trouble

Before I could do anything I had to first answer some basic questions.

A. What do I want from my job?

B. Where am I headed 5 years from now?

Without answering these I didn’t really know where to apply. Some things I was absolutely clear about —

1. I want to be an individual contributor . I enjoy writing code, I am reasonably good at it and I can get paid for it.
2. I want to work for a product company.
3. I wasn’t looking to relocate. Remote working was fine.

I am based out of Pune, India. A much smaller tech place when compared to Bangalore or even Hyderabad. My primary technical skills are kernel programming and problem solving. I am most proficient in ‘C’ followed by python. Given these constraints and based on answers to A and B, I saw very few options. VMware seemed to be at the top of the ladder for my areas of interest and it looked like the only place to go was down.

This was my lack of knowledge. I had been making some of the classic mistakes — not being in touch with what’s going on outside my work/company technology. Only a tiny network to learn about new work or startups in my area of interests. Not generating conditions for randomness in my sources of knowledge to stumble upon something completely new or unknown. I wasn’t attending any meetups or part of any interest groups. Because I didn’t need to… up until now.

It’s not that I have been completely off the radar. On LinkedIn I regularly have inMails from HRs from various MNCs but none that I have taken seriously so far, for various reasons.

As it happened, I got a call from an HR who was working at a company that was looking to start a team in Pune. The same call a year earlier and I would have turned it down politely, not this time. A friend of mine works for a remote-only global company. I had always liked what I heard of it and looked like a good opportunity. These were my two starting points (and ending points). I made my resume and sent it the two places.

How to crack the broken interview process

It dawned on me the torture of preparing and giving interviews. My last interview was 12 years ago when I was in grad school. I always felt being sincere at my work, good fundamentals should be enough to sail through any interview. I was WRONG. These are necessary but not sufficient conditions. Even within a specific area say filesystems or storage or kernel the problem space is so vast that it is impossible to cover it. Because each project/team works in a subspace it likely going to be different from the one that your are working in. This means that what is in your primary cache is worthless and what is sitting on your tape drive needs to be paged in. Why?

First, because you only have about a min or two to respond with a potential solution and another 10 mins to optimize and propose a perfect solution to _any_ question.

It isn’t that the interviewers are unreasonable but if a person has been working day in and out on a specific problem, the potential solutions/data structures seem obvious. The interviewer gives the interviewee some benefit of doubt and thinks ‘if I can give this answer in a minute, a good candidate should be able to do so in 10 minutes. That’s 10x the time — that is fair.’ Anything longer can translate into “slow at solving” or “has forgotten basics” or “not thinking hard enough” kind of feedback.

This is only the starting of what all is wrong with an interview. I think a lot of us know this but no company or group seems to be trying anything new but I digress.

Second, a crucial reason to revise is because of the setting. It is so completely unnatural and different from what one does on the actual job. For any meaningful problem that needs to be solved in reality you will be giving time and space, where time > 10 mins and space to think aloud, discuss, investigate how other people have gone about solving similar problems. Agreed, to do any of this you should have some fundamentals to begin with but are the interviews really testing that? To add to all this there is the exam-like environment. (For folks that interview every year or so this probably isn’t a big deal but after 10–12 years it is!).

Third, to keep our minds uncluttered, we start to remember only the “what” or “rules of thumb” so that it is easier and faster to take decisions. The “why” gets pushed out and is retrieved only when needed. Interviews are one place where their attendance is mandatory.

Here is a checklist of how to prepare based on what I experienced —

1. Write down, yes I mean actually _write_ down a paragraph describing your current work. Try to be as precise and crisp. If possible, avoid explaining too much about the product or using company specific jargon. Focus on the kinds of problems you are solving. A lot of interviewers use this to judge both your involvement in past work and communication skills.
2. Write down 2–3 specific problems that you solved. Explain why they are interesting problems and what was good + bad about the final solutions. Mention patents that you have filed, if relevant to the discussion.
3. A list of fundamentals in your general area. For systems, kernel they are things like address spaces, virtual memory, workings of system calls, interrupts etc. Make sure you are able to answer it in as much detail as possible. (This is assuming you also understand all of it).
4. A list on the specific area you have worked on. For me, it was SCSI basics, host-side storage stack workings etc. One thing I realized only later was because I worked on a proprietary OS software, I should have worked more on explaining the details in Linux terms.
5. Research on the company/team that you are going to be interviewed with. Which problem subspace do they work in? What kinds of problems are they dealing with? This gives you a hint on what data structures and algorithms to focus on. I found the “interviews” section on glassdoor useful for this. They give a flavour of both the kind of questions that are asked and the kind of problems that interests the teams there. Then, a general search on each problem will give you more questions.
6. Solve coding problems, more the better of course. There is a lot of ground to cover in here but usually knowing the fundamental data structures is enough. Use the cues gathered in 5 to focus on relevant algorithms. Revise basics of your preferred programming language. Some companies give an online programming test before the actual rounds.
7. If possible, speak to the manager that heads the team you are being interviewed for before the actual rounds. Understand what kind of role they are looking to fill. If the company and team excites you then apply and leave it to them to find a fitting role for you.
8. Nothing helps more than giving an actually interview. The deadline forces you to prepare and the interview gives you a taste of reality. Apply to companies that interest you but not necessarily your dream jobs for such “practice”. Basically, be prepared to fail here.
9. An interview is to judge the team/company as much as it for the team to judge you. Use this time to gauge the culture, work life, happiness quotient, how the product is doing from an engineer’s point of view etc. I always had a list of questions to ask the interviewer and would keep it handy. I did meet interviewers who were uninterested to answer my questions and that left me with me a negative feeling.

So, how does this story end. Of the two places I had applied to — one place never got back (the friend who referred me did follow up and said the hiring manager is interested and then nothing happened. Later my friend told me they are talking to some other candidates first). I guess they found a better candidate, well in this case a better resume because I was never a candidate. It was a reminder that I probably need a better personal brand.

At the second place, I gave two phone screens. First one went well and the second went okay-ish. Under any other setting I would have answered the question asked in the second phone screen without batting an eyelash. But in the interview I took the slow path. I didn’t hear back from the HR for a week. I sent an email asking for feedback, nothing. After a month I sent an angry email saying how disappointing I found the experience. The HR finally called, of course not apologetic. I don’t remember much of that conversation but to hear words like “back-burner” is unbecoming of an HR.

Recall my limited network. So, after this I basically had nowhere to go. I did look at remote positions for many places but openings for kernel programmers were zero. I did feel a bit like Elaine from Seinfeld, in a mental sense.

Then I met two friends Navin Kabra and Amit Paranjape — probably the two most well-networked people of Pune tech circles. I told them what I was looking for. They suggested about half a dozen places in Pune, most of which I had no idea existed. They connected me to people at places I was interested in. I met with four of those and accepted the offer made by one of the them. I am headed to join a startup working in the NVMe space. This is a huge shift in terms of mindset, risk, culture and processes. But more on that once we get there.

Among other things, I plan to use this change as a trigger to start doing the things I wasn’t doing — build a better personal brand. I hope to post on how that exercise is going in a few weeks time.