On leaving my last job

I worked at Apple on the Swift team from July 2019 to Sept 2021. In terms of my career as a Software Engineer, this was the Year 0 - 2.25 period.

As of the date of publishing this post, it’s been almost exactly 3 years since I left. In the time since, I almost never really felt like writing this kind of blog post, under the assumption that publicly sharing negative things about a past employer would only hurt my future job prospects.

That changed recently, when someone asked me why I left my previous job at Apple, I ended up talking about it much more candidly, and ended up giving a much fuller answer than I’d given people in the past. I ended up talking for over an hour and getting somewhat emotional.

After that conversation, and reflecting on the fact that I’ve been approached for job-hunting and career advice a few times over the past couple of years, I felt that I ought to share some of my experiences with other people, especially junior people just entering the workforce.

Since this post is about incidents which influenced my decision to leave, the experiences in going to mention in this post are going to be negative. However, I want to make it clear that it does not reflect the majority of my time on Swift team.

The code was complex, and sometimes I struggled making even seemingly small changes, but my mentors generally had patience with me, and spent time guiding me in their various areas of expertise, despite having a lot on their plates. Most of my day-to-day interactions with my colleagues went well, and I learned a lot. I was promoted from ICT2 (~Junior) to ICT3 (~Mid-level) around the 9 month mark, which I was told was faster than typical for new grads.

To this day, I miss the Swift team lunches, where I’d get to hear about wild stories related to tracking down bugs, demystifying benchmarks and uncovering runtime horrors being performed in apps with millions, if not hundreds of millions of downloads.

With that said, here is the set of experiences during my time at Apple that influenced my decision to leave.

Some of these memories are admittedly hazy; I’ve tried to reflect that in the wording where applicable. Some of them involve emails which are locked behind Apple servers; I never forwarded any of the emails mentioned to my personal email account, or took photos of them, to avoid running afoul of Apple’s strict corporate security policies. If you’re looking for evidence or both sides of the situations, you can stop reading here.

The Job Offer

When I received the job offer from Apple, I felt a huge sigh of relief. I had been looking for a job for around ~9 months then, while grinding away at finishing up my Master’s degree at a snail’s pace having lost the drive to continue doing research.

At the same time, I was a bit worried about the exact employment agreements. This would be my first time signing long-term employment agreements, and I was concerned about whether I would own the IP for side-projects that I did in my spare time, whether any clauses would prevent me from working at other tech companies in the future, and so on.

I conveyed this to the recruiter ahead of time, after I’d received a verbal Yes but before I’d been sent the contract over email, telling him that I’d like to discuss the contract with a lawyer before signing it.

I also requested that the recruiter communicate with me over email instead of over phone so that I had some time to think over any questions and to avoid having to do repeat calls. Also, the building I used to sit in would sometimes have poor reception.

The recruiter ignored my requests to communicate over email. Later, when he sent me the final contract, it was near EOD Friday, and he sent it with a 3 calendar day limit for a signing bonus for $10K USD. Even in 2019, I think a $10K USD signing bonus would’ve been considered fairly measly for a Software Engineer position at a big tech company in Silicon Valley. However, given that I’d mostly worked on a teaching assistant’s salary for the past 2 years, and my first paycheck (being a few months out) hadn’t really mentally registered, the signing bonus felt like a princely sum right in front of me.

I managed to get an appointment for a local lawyer on Monday and had them review the contract. The lawyer expressed that he typically only did this kind of review for much higher up positions. He asked me to follow-up with the recruiter to clarify certain clauses in the contracts. He couldn’t give me clear answers in terms of open source/clarity of IP assignment etc. I didn’t feel terribly confident that the lawyer understood my questions and had my best interests in mind, and there weren’t that many lawyers near me since I was living in a collegetown. I paid around $500 USD for about 1.5 hours of work. For context, this was equivalent to more than 1 week of my post-tax salary as a teaching assistant.

I managed to convince myself that all my future colleagues in engineering seemed like good people based on what I’d seen online (in their GitHub PRs, Swift forum discussions and Twitter threads) and I should sign the contract based on that, even though I really disliked the recruiter’s tactics.

A few months after joining, I ended up discussing this experience with a colleague who joined around the same time as me, and they mentioned that they went through a very similar thought process after having had a fairly negative experience with the recruiter. Based on this conversation, I wrote up an email to my manager and skip manager describing what had happened, and I believe my colleague did the same, since we thought it’d be in the department’s best interests to have the recruiter create a better experience for prospective hires.

I never received any information for what happened after that. The recruiter continued working there; I left the company before him.

Open Source

One of the common memes about joining Apple as a Software Engineer is that your OSS activity goes dark. At the time, I was keen on working on OSS, which is one of the reasons I had applied for the job opening on the Swift team.

During my interview loop, when I was having lunch with the hiring manager and a senior engineer, I asked as to whether it’d be possible for me to contribute to other non-Apple OSS projects or create my own, in my free time and using my own equipment. The answer I got was that there was a process for getting approvals, which may be somewhat lengthy, and they didn’t know anyone who has gone through it.

At the time, I figured that I would be willing to wait for a few months or even a year or so if that meant I could hack on my own OSS projects or contribute to other ones I was interested in.

Fast forward to me joining and inquiring about the process, it turned out that the process for OSS side-project approval seemingly only existed in name, and there were already several much more senior people who’d been waiting for approvals for multiple years, with their requests stuck in limbo. There was an Open Source Program Office which was formed some time after I joined (a few months after perhaps?), and there was hope that it might help speed things up, but that ideal never materialized during my time at Apple.Based on what I heard from a former colleague currently still working at Apple, the situation hadn’t changed as of late 2023, when I last chatted with them.

After this experience, when I was performing my next job hunt, I explicitly asked for concrete examples of engineers hacking on OSS side-projects.

It was only when I filed my first OSS issue post-Apple did I realize the weight that had been lifted off my shoulders.

To give an example of this “weight”, once, when I was at Apple, I had been hacking on some code in a different language on the weekend, and hit a compiler bug. At the time, encountering compiler bugs was fairly routine for me, so my brain immediately switched to creating a minimal reproducer. A short while later, I found that someone had already filed a GitHub issue for seemingly the same bug with a much larger example, and it hadn’t been minimized yet, so I posted the minimal reproducer in a comment.

An hour or so later, I realized that may have technically violated policy and thought I might be potentially fired if this were discovered.For background, due to my visa situation, and how long my first job hunt had taken, I was somewhat fearful of being fired during my time at Apple.

So I immediately deleted the comment.

Post-Apple, I had flashbacks to that moment the first few times I was commenting on random issues or opening new ones. Oh yeah, I could just do that without stressing out.

Some people say that you only realize the value of something after you’ve lost it. Based on this experience, I feel that isn’t entirely true, I think there’s an argument to be made that you can have a similar realization after regaining what you lost, especially if the loss was gradual but the regaining was well-defined.

As I’ve come to realize the value of feeling unencumbered for myself, I think I’m unlikely to take up a job at a company with similarly restrictive policies at any point in the future.

Benchmarking

At one point, there was an email thread in our team on benchmarking and improving compiler performance, and I expressed disagreement with a highly experienced colleague who I normally didn’t interact with that much.

The disagreement was centered around what exactly should be benchmarked and how. The colleague said that we should use end-to-end performance for an Xcode user as the north star (e.g. latency from entering a key stroke to seeing updated error/warning squiggles in the editor), whereas I was saying that we should focus on the performance of the compiler itself. I believe two of the reasons I cited at the time were that (1) our team had ownership of Swift, not Xcode, and (2) that trying to include Xcode as part of the benchmarks would introduce a lot more complexity and potentially more noise. (An important bit of context here is that, at least at the time, just building Xcode from source was very slow and resource-intensive on the pre-Apple Silicon Macs we had at the time, and sometimes you’d get hard-to-debug build errors if you didn’t set up everything just right.)

During the discussion, I cited some research talks and/or papers (I forget which exactly) from a particular researcher discussing benchmarking. IIRC, the point I was trying to make was that benchmarking time properly would be a huge undertaking; random allocation decisions and alignment changes could affect benchmarks to a large extent, and it’d be hard to untangle those from noise given the tooling that we had at hand, and that we should focus on instruction counts instead since those would be more stable and allow for measuring small improvements, even though they were less directly correlated with a better end-user experience.

Not too long after my final reply, I received a calendar invite for a 1:1 from the colleague above without any explicit agenda.

When I joined the meeting, he started by asking about my background, such as what I had learnt in university, and how I got interested in compilers. Then he started asking me some questions related to compilers and runtimes, as well as some questions related to how certain things worked. I tried to respond to the best of my ability, but I was confused by the direction the conversation was going in, as he seemed to be annoyed when I answered something other than “I don’t know about that” and kept asking more follow-up questions when I did say “I don’t know about that.”

He then asked some historical questions around whether he knew who had developed some widely used systems and I said I didn’t know. This went on for a bit until he said he had played a key role working on these various systems. He then asked me, based on that, who in my opinion knew more about topics like benchmarking, him or the researcher I’d mentioned. At this point, I was feeling quite humiliated; I had not made any personal comments in the email thread to imply anything one way or the other, and had focused on the problem at hand. Swallowing back my discomfort, I answered “you.” This went on for a few more times. I listened as I was berated at with glaring eyes and a voice seething with anger. I was on the verge of tears. At the end, I mustered an apology that I didn’t believe in.

After the call, I cried by myself for a while. Then I wrote up an email describing the full interaction as best as I remembered it and saved it as a draft. I’m not sure now, but I think at some point, I updated the original email thread stating that I had discussed the point of disagreement with the colleague, cleared up some misunderstandings and agreed with his viewpoint.

Later, in my next 1:1 meeting with my manager, who had been on the email thread, I asked him to read the discussion and asked him what he thought about my communication style and if there were any problems there. He said it seemed like a normal technical discussion and that I had made my points in a reasonable way.

I then revealed my conversation with the colleague and asked my manager if I should send him the draft I’d saved. He said that if I felt comfortable sharing that, then yes, I should forward that, and he would send it to my skip manager, again, if I was okay with that. I said OK to both and sent the email. I don’t remember much of what happened after, I think I got some kind of consolation response from my skip manager stating that he would talk to the colleague about it.

I never received any information for what happened after that. The colleague continued working there; I left the company before him. I never received a single “Sorry”, let alone a longer apology.

For a few months, I tried to be extra careful when having back-and-forths with other senior people, even though I’d never had any such negative interactions with them.

During the rest of my tenure at Apple, I avoided responding to any of this colleague’s points in email threads, and avoided choosing to work on projects with him. I learned that some of my peers (i.e. younger team members) had also occasionally had quite negative interactions with him, without specifics.

Partnering with HBCUs

A common occurrence in Silicon Valley tech companies is that engineering departments tend to be mostly male and mostly white, and Apple wasn’t any exception in my time there. For the Swift team, we tended to get many applicants via job postings shared on Twitter (including my own application).

At the time, and I’m guessing now still, universities with compiler courses tended to have majority white, majority male CS student demographics. Knowledge about compilers was not a pre-requisite for internships and entry-level job openings, but given the number of applicants with knowledge about and interest in compilers, it was hard for other applicants to stand out.

Having growing awareness around Diversity, Equity and Inclusion (DEI), and noticing the homogeneity inside Apple’s developer tools department, I assumed that I could make a dent if I got support from a bunch of other people and put in the work to attract candidates from diverse backgrounds.

Also, at the time Apple did have partnerships with some Historically Black Colleges and Universities (HBCUs), which were handled by another org in the company. Additionally, recruitment technically fell under yet another org.

At first, I assumed that given the repeated mentions of DEI in the company, there would be keen interest in helping improve the diversity of our applicant pool, such as by getting our (publicly visible) internship and job openings explicitly in front of students at HBCUs. Since Swift was an open source project, Google Summer of Code and Outreachy also presented good opportunities; these programs didn’t seem to have that much awareness outside of students at certain groups of universities.

And in a way, the point about interest was true; there were several people in my department who were keen on supporting an effort to do that.Of course, there were also 1-2 people who came in with the typical strawmen arguments around “not lowering the bar” but I and my supporting colleagues emphasized that any interview processes would be the same, regardless of which university the candidate was from.

However, trying to get meaningful support from the org handling the HBCU partnerships and the one handling recruitment was like pulling teeth, except that with pulling teeth one can resort to force, whereas with this effort, having even both my manager and skip manager present on the email threads didn’t seem to help much.

From the recruitment org, our main point-of-contact was the aforementioned recruiter (from “The Job Offer”) who handled recruitment for our department more generally. He was not cooperative at all. When we wrote the equivalent of “we’d like to do X and Y to increase the diversity of our candidate pool”, he interpreted that as “you’re saying that I’m not bringing enough candidates from different backgrounds.”

In the context of recruitment, especially for university students or around particular events around Google Summer of Code, time is of the utmost importance. I spent a fair bit of time writing emails, sending reminders and setting up a few meetings, but it didn’t really end up going anywhere.

Exasperated by the lack of urgency and tired of waiting, I ended up cold-emailing Computer Science professors at several HBCUs to see if they’d be interested in having us give talks about open source and Swift.

I prepared a talk and gave it virtually at two different HBCUs, with some of my colleagues and about 30 students in attendance. However, we didn’t really have any concrete follow-ups except for connecting with students on LinkedIn.

The whole experience left me quite jaded in terms of trying to effect change outside my core job responsibilities. It also left me questioning whether it even made sense to try to engage with people in other orgs unless it was absolutely necessary.

During this time, I rewatched Dan Na’s talk Pushing through Friction a few times, probably looking for validation that I’d been doing the “right thing”. In hindsight, I just wish I’d had the awareness that while I thought I was pushing through friction, I was actually just pushing uphill.

A small example: when I joined Sourcegraph, there was a potential future project idea that I thought might need extra care around legal terms. Being able to flag that in our legal team’s Slack channel, get input on the concerns, and have a 1:1 with our Head of Legal soon after, was a mind-blowing moment.

Now, of course, Apple is about ~3 orders of magnitude larger than Sourcegraph, and I am under no delusion that what works in the context of a much smaller company would work in the context of a much larger company.

I suppose the overall message of this point is that it is important to understand what contexts you can thrive in, and what contexts you are not well-suited to. Organizational size, culture and incentive structures can potentially have a much bigger impact on your day-to-day than you might realize, especially if you’re junior or fresh out of college.

Unfortunately, I don’t really see any good way to actually figure this out apart from actually working at different companies.

Pay Intransparency

Around the 1.75~2 year mark, my conversations with my manager were largely centered around status updates and technical issues. I had read some resources giving advice on taking charge of your own career trajectory, and one of the points was that you should ask your manager what you should be doing to get to the next level. One specific bit of advice was asking what it would take to receive a specific number in salary, to help ground the discussion.

IIRC, when I had asked my manager for feedback in a generic way, I hadn’t really gotten anything terribly substantive. So following that advice, I asked my manager whether I could receive a 10% salary increase in the next review cycle (after a few months) based on the work I’d done so far, and if not, what work I would need to do to get to that level.

My manager said he would get back to me later since he wasn’t too sure. During one of our subsequent 1:1s he said that I should continue working on the projects I had planned. He said that such large salary increases were reserved for promotions, and that typical salary increases for good performance were around 6%-8%. Since I had been promoted out-of-cycle just about a year back, it would be unprecedented for me to be promoted from ICT3 (Mid-level) to ICT4 (Senior) so soon; I needed to show consistent performance at this level over a longer period of time.

I had learned about companies having salary band structures, so I asked him if he could share those with me. He said he couldn’t share those, only managers had access to them.

At the time, I thought that was reasonable, and I was happy with his answers.

After I decided to leave, I learned that a colleague who had been doing similar work as me and had joined about a year later than me, and was at the same ICT3 level as me, had a base salary that was around 15%-20% higher than mine (their starting equity grant was also higher than my initial + refresher grants combined).

This simultaneously felt like a slap to the face as well as evaporated any lingering doubts I had at the time on whether leaving Apple was the right move. I didn’t care about the monetary difference; it felt like a betrayal of trust that I had in my manager.

During these past few years, the US has made some strides in the form of salary transparency laws enacted in many different states, including California. I’m glad to see that and I hope more places follow suit.That said, some places have even fewer protections for workers. I currently live in Taiwan, and here, employers sometimes have wording in the employment contracts that forbids employees from discussing salaries. This kind of clause would be illegal in the US. For places like Taiwan, a good first step would be making that kind of wording illegal, before moving on towards greater salary transparency.

If you’re reading this, please don’t make the same mistakes that I did. Yes, discussing pay can sometimes be awkward. But if you truly believe in equal pay for equal work, it’s important to do your part in it. If you, the reader, are one of my current or former colleagues, I’d be happy to swap pay information.

I hope in the future there is some non-profit managing anonymized compensation data across companies and countries. It is a bit unfortunate that TripleByte went the way it did, I was hopeful it might at least function as an “open” data dump.

Remote Work

The straw that broke the camel’s back ended up being Apple’s hybrid/return-to-office policy.

In terms of my living situation, I was still based in Sunnyvale in the South Bay Area through the pandemic, since it was not clear when return-to-office would be announced, and I wasn’t sure if I might need to go to the office to get some hardware at short notice for debugging some issue.

Around the 2 year mark, it was pretty clear to me that I wanted to live in a more urban area long term. However, I did not want to waste my time with a long commute, and I couldn’t have both – if I’d moved to San Francisco/Oakland/Berkeley, I’d likely have a 1hr+ commute both ways, for at least 3 days a week under the hybrid policy.

When I’d joined the Swift team, we already had team members who were remote, so much of our collaboration happened online anyways, and most meetings tended to have 1 or more attendees join via video call.

Teams more distant in the org chart were often in other buildings, so even if everyone in the meeting was in Cupertino, chances were that the meeting still had a video call component.

What I’d heard at the time, was that the remote work policy had been more flexible until a few years before I joined, after which it essentially become almost impossible to get new approvals. Given that, plus the context I was operating in, plus seeing so many other companies allow more flexible remote work policies, it felt silly at the time to hear comments like “our successes during the pandemic were based on the relationships we built in-person before the pandemic” as well as “I’m excited to see work with all of together back in the office soon” from people higher up the org chart.

The other thing that bothered me on principle was the “grandfathering policy” – people who were remote before the pandemic were not being asked to follow the hybrid policy. My current employer Sourcegraph has also done a similar thing but with pay; Sourcegraph recently switched to location-based pay from location-independent pay, but the pay for people who joined before the switch remains unaffected.

From a logical perspective, I get why companies do this – you want to de-risk good people from leaving. However, I feel that if you were running a company with fairness as a core principle, then you would use equity/option grants (or equivalent) for rewarding impact and not factor in tancillary aspects like tenure and location for base salary, policy effects (PTO, RTO etc.) and so on.Of course, I understand that legal requirements in different jurisdictions are different, and so it might not be possible to have the exact same policies for literally everyone depending on the jurisdictions the people live in.

Anyways, with the hybrid RTO policy, I ended up deciding to leave and looking for all-remote jobs and office-based jobs with offices in more urban areas like SF and NYC. I ended up joining Sourcegraph, which has largely been all-remote, and I’m glad to have been able to move to Taipei and experience living in a place very different from the places I’ve lived in before, as well as being able to travel to many different countries.Not to mention, I also no longer need to worry about the precarity of the H1B visa, or the decade+ long queue for permanent residency in the US for Indian passport holders.

After joining Sourcegraph and participating in the more async and writing-based culture, I realized that in my frustration earlier, I’d missed the partial truth in those statements around RTO at Apple. A lot of important discussions, especially those involving multiple teams, happened in meetings instead of asynchronously (via RFCs or similar), which when combined with the general culture around secrecy and need-to-know meant that often the most effective way to learn about the details about something was to make sure you were attending the right meetings. However, in mixed meetings where some people are remote and others are sitting in the same conference room, remote people can easily end being somewhat second-class, unless explicit care is taken to ensure otherwise.

Over the past few years, I’ve become more aware of the upsides and downsides of remote work, and would probably not rule out working in-person some time in the future. At least, the part about intentionality and the recurring processes that are required to make remote work tick have become much more clearer to me now.

Closing thoughts

I’m afraid I don’t really have much of a conclusion section here.

I don’t want to give platitudes like “you need to stand up for yourself” or “you need to figure out what you want to do” or “just quit your job” because well, even if you’re fortunate to land a good job, you’ll probably have struggles at some point or the other, and many things will be outside of your control.

I suppose maybe one takeaway could be that maybe its valuable to reflect on what is/is not under your control, and look into changing things which are under your control if that might help improve your overall quality of life. But when stated like that, it seems obvious, even banal.

So yeah, that’s it. Good luck out there.