How to Transition from iOS Engineer to Distributed Systems Engineer? | Hacker News Reader

How to Transition from iOS Engineer to Distributed Systems Engineer?

3 pointszffr6 comments

I have been working for about 4 years as an iOS engineer at a large company. I have gotten the chance to work on some pretty high profile things, and it seems like I would have a good career trajectory here, but I'm just not interested in working on apps anymore.

I _think_ what I'm interested in now are distributed systems. The problems that interest me are the challenges of building systems that are efficient, correct, and can scale to millions of users. I have read a bunch of papers on the theoretical side of distributed systems, and it seems like it would be fun to work on these problems.

Ideally I would like to stay at my current company because of my unvested RSUs, and my company does have some open distributed systems engineer positions. I fear that I would currently be rejected outright because I don't have any work experience building distributed systems and so I need some way to demonstrate proficiency/potential. This is challenging because my current job is far removed from distributed systems.

Here is my current plan: - Set up 1:1 chats with hiring managers to better understand what their engineers do, and what they are looking for. Also ask them what I can do to improve my application. My company encourages these type of chats.

- Work on some distributed systems side-projects. Some ideas: Implement a simple form of Raft/Paxos, build a simple distributed key value store, multi-player load balanced game. I could also simulate traffic to demonstrate how well the system scales, and could try different approaches to see the perf impact.

Any other suggestions for how I can transition into a distributed systems engineering position?

Re: side project ideas, you could work through the programming assignments for MIT's 6.824: Distributed Systems (taught by Robert Morris, of both Morris worm and Viaweb/Y Combinator fame). The assignments include auto-graded testing scripts, so you can verify your solution to the assignments.

https://pdos.csail.mit.edu/6.824/

Are you sure you’re specifically interested in Raft/Paxos/consensus algorithms? Distributed systems is more general than that. A lot of software engineers working on cloud services are basically doing distributed systems, if they are building multiple interconnected services. Where I work, our team has 10-15 services that communicate with each other, with databases, caches, and with other dependencies/consumers. This could also be considered distributed systems.

Distributed would basically mean that a good portion of the core logic of the system is executed across multiple entities. So it can be scaled by simply adding more nodes. This is a specific niche, and engineers gain experience in that specific area. Am i right?

Kind of? I mean, if you’re working on an infrastructure or platform team, and building some distributed database or data pipeline, that would be more “distributed systems”, in the strict definition of the term. However, I doubt there are very many teams working on these sorts of problems —- it’s a very specific niche.

Edit: I might have misinterpreted your comment. The actual architecture of scaling by adding more hosts is quite common, if you’re processing independent messages.

I'm more interested in the general problem of building those interconnected services, figuring out how to verify correctness, and scaling them to service the traffic they get. I think consensus might be a part of that (maybe for garbage collection?), but it's not something I'm specifically interested in.

Right. Then it might be worth applying to cloud software engineer roles in general, and be sure to ask your interviewers about what sort of architecture they work on. In your case, seems like you’ll be more keen to work on those teams that have multiple services, not those that have monoliths.

Reply on news.ycombinator.com