Speaker A
I was recently affected by the layoffs made by Atlassian, and I wanted to take some time out to reflect on the time that I spent working for Atlassian. I worked there for about eight years.
Vasilios Syrakis reflects on his 8-year career at Atlassian, sharing his interview experience, technical projects, and lessons learned after being laid off.
Key Takeaways
- Interview preparation should include both technical skills and understanding company values.
- Building scalable internal tools requires a deep understanding of cloud and container orchestration.
- Troubleshooting real-world incidents is a critical skill in tech roles.
- Adapting to new technologies and frameworks is essential for long-term success.
- Anticipating and managing team conflicts can reduce workplace stress.
Summary
- Vasilios Syrakis discusses being laid off from Atlassian after eight years of work.
- He reflects on his interview process, including coding quizzes, technical interviews, and values assessment.
- He describes his first major project: building a self-service load balancer provisioning web app using Python and FastAPI.
- The video explains the architecture and technologies used, such as Kubernetes, DynamoDB, SQS, and Envoy proxies.
- He shares insights into troubleshooting real incidents and handling complex infrastructure tasks.
- Vasilios talks about the importance of anticipating technical and interpersonal challenges in large organizations.
- He emphasizes learning from mistakes and adapting to evolving technical stacks.
- The video is structured in chapters for easy navigation through different topics.
- He hopes the video inspires and helps others facing similar layoffs or technical challenges.
- Non-technical aspects of working at Atlassian, including team dynamics and stress management, are briefly touched upon.
Chapters
- 00:00Introduction and reflection on Atlassian layoffs
- 02:16Technical interview and troubleshooting exercise
- 04:38Overview of self-service provisioning app architecture
- 07:01Building the load balancer broker web app
- 09:23Technical details of FastAPI and backend components
- 11:42Envoy proxy configuration and dynamic data handling
- 15:55Infrastructure automation with EC2 and Salt Stack
- 22:23Advanced edge infrastructure and Envoy-based product
- 27:09Challenges in maintenance, team dynamics, and stress management
Full Transcript — Download SRT & Markdown
Speaker A
During that time, I built a lot of things, and I wanted to talk about what I built, mainly the things that I personally found interesting or that I'm proud of.
Speaker A
I hope that this video will be useful or helpful to someone who perhaps is or was in the same situation as me, and maybe it'll give them some inspiration in terms of how they can tackle the same things that I did or something similar.
Speaker A
And perhaps avoid some of the mistakes that I've made. I also might talk about non-technical parts of my experience at Atlassian, although most of it will be technical, and this video will be split into chapters so that you can skip to
Speaker A
sections that are more interesting to you rather than watching the video from start to finish. So I suppose to start with, I'll talk about when I was first hired, and even though it was eight years ago, I still remember the
Speaker A
interview process, which is different nowadays, and the reason why I was hired, or at least from my perspective, the reason why I was hired, and the things that I started working on during the start. So yeah, let's just start at the
Speaker A
interview process. So I was interviewed by some people that I now consider friends, and I remember having the impression while being interviewed that these individuals were quite intelligent, and that was something that was exciting for me. The interview process consisted
Speaker A
of a coding quiz on HackerRank, which I aced with full marks. Then the first technical interview was with two interviewers, and they gave me a white paper and asked me to read it while they sat out of the room for about 10
Speaker A
minutes. They came back in and then asked me questions about the white paper, asked me to basically articulate what was in the white paper, and the white paper was actually about custom domains, and the white paper was by Cloudflare.
Speaker A
They then asked me a few questions about things like microservices and architectural things like that, containers, and whatnot. And they were happy enough. I don't remember the rest, but they were happy enough with me during that stage, so I
Speaker A
continued to the second technical interview, which was a troubleshooting exercise where I was asked to essentially prompt the interviewer for information in order to troubleshoot a real incident that occurred in Atlassian. And it was a
Speaker A
application problem that led to a denial of service. So that was fun.
Speaker A
And then I think I was asked something about how latency-based DNS works, and my answer was not accurate, but perhaps acceptable. I thought about it from first principles, and I thought that, for example, Route 53 did a triangulation based on the actual latency of the client, but it is more like that they use a geolocation database in order to do latency-based routing of DNS requests, or the DNS answers, sorry. Then
Speaker A
after that was a values interview. And to be honest, I don't really remember most of the questions for the values portion, but I do remember one thing, which was when I asked the question of, I asked the interviewers to think about 12 months from now and to look back retrospectively, what is the thing that I would have had to achieve in order for you to say it was a good decision hiring this person? And then
Speaker A
they told me about an application that they needed to be built for the platform within Atlassian, and the application would facilitate self-service load balancers. Sort of similar to if you were using Amazon application load balancers or the
Speaker A
equivalent in any cloud provider, but for the internal developers of Atlassian. And it was essentially just a framework that I personally was not familiar with. And I said I could build it because I had confidence in building
Speaker A
web apps with Python at that time. And they accepted my level of confidence and decided to hire me. So that's the interview portion completed. So I joined Atlassian, and they have this classic saying or impression that when you join
Speaker A
Atlassian, you are drinking from the fire hose because there's so much information that you have to absorb in the first few weeks and months in order to just sort of get going. My first, my very first task, or at least task that
Speaker A
I gave myself, was to build the application that they had told me that they wanted. Let me just open a browser and we'll take a little looky at what I mean exactly. Let me just move my face a little bit. There's more real
Speaker A
estate. Now obviously, it's Scalar Draw is not what I care about. So they wanted me to build an open service broker. This is a web app with an API which facilitates the provisioning of resources for a platform essentially. So
Speaker A
you can see here it's sort of built to operate in a Kubernetes world where you're submitting these provisioning requests as things come up and down. And it's going to bind a resource to your pod or your cloud
Speaker A
instance or whatever it is, as you can see here. And it sort of sits in between these real resources. So you might provision something like a database, and then you'll get MySQL. So you'll get something that's SQL compatible but
Speaker A
that's abstracted away for your internal developers. Anyhow, the spec is here on GitHub. You can take a look at it. It goes into, like, for example, the catalog endpoint. And the catalog lists all of the services and plans that are
Speaker A
available on the OSB, and just metadata about them. And you might say query the service broker and then display some of the metadata in your Maybe you've got a console, a console like the Amazon console, but
Speaker A
maybe you've got something like that internally, where developers can click and provision things. In the Atlassian case, it was all through configuration files that were committed to version control, and then those would be uploaded,
Speaker A
during uploaded from a build server to deploy a service. But yeah. So, you might have, you know, other APIs like provisioning here.
Speaker A
So, put and patch for updating and deletes and blah blah blah. So, you would just basically go ahead and implement this. Or I mean, if you wanted to build your own, and that is essentially what I did. You
Speaker A
can see also there's an open API document here that has the endpoints. So, I chose to build this in Python using Flask. Oh no. In fact, what I built it with first is with a
Speaker A
library called Connection. This is a Python library which takes an open API document and then creates the API handlers for the paths for the API, for the API routes that are in that document, which is cool, but then we
Speaker A
eventually, I eventually migrated that to just pure Flask. And then eventually migrated that to FastAPI, which I believe is what it still is at the moment. Okay. So, it's the first two weeks, and my primary focus is to build
Speaker A
sort of what I promised in the interview, which is this web app that's going to be a broker for the platform, and is going to allow self-service provisioning of load balancing in Elastic. So, like I mentioned earlier, I
Speaker A
started with this library called Connection, which took an open API document, turned that into routes. But I'm going to just go with what it ended up as, which is a FastAPI app. Let's just say we've got FastAPI
Speaker A
here, and then we've got a worker, and then we have a database, which was DynamoDB. Oh, that's annoying.
Speaker A
And we would have a client making requests. That's why that's a FastAPI. The client would say, "Hey, please provision something for me." And the web worker wouldn't do it itself. It would actually send that over SQS. It would
Speaker A
drop the task details into SQS. And the worker would then handle that. So, what does a provisioning task actually look like?
Speaker A
It's something like creating DNS records somewhere, maybe cr...
Speaker A
drop the task details into SQS. And the worker would then handle that. So, what does a provisioning task actually look like?
Speaker A
It's something like creating DNS records somewhere, maybe creating a CloudFront distribution, maybe creating some API calls. And this would be the provisioning task that the worker would do asynchronously, while the web and client would wait for it to be completed
Speaker A
essentially. So, the client's polling continuously to say, "Is it ready? Is it ready?" And when it is completed, the worker writes it to the database, the web server checks the status, and then responds saying, "Yes, it's finished." Or it'll say that something went wrong
Speaker A
and there was an error. So, then we can sort of encapsulate this as the open service broker that I built.
Speaker A
Pretty straightforward. Um to be honest, there's not much more to this, but we're going to go and talk about some of the more complicated bits in just a second, and I will directly link to this as well. So, we got this
Speaker A
client requesting uh let's say "Please provision a load balancing." And that is essentially what they were asking for was some kind of load balancing somewhere in the edge infrastructure of Atlassian to allow traffic to go to their service. So,
Speaker A
that's a good uh demarcation point to start talking about the next thing that I sort of built.
Speaker A
And I built it through necessity of Essentially, I began to understand and unravel the requirements more as I went along. One of the architects had this idea to replace the load balancers at Atlassian, which were enterprise load balancers that had licensing costs, with
Speaker A
a open-source cloud-native sort of commodity proxy. And the tech that we chose for that was Envoy proxy. You may be familiar with Envoy proxy. If you're not, then it's very similar to something like Nginx, but perhaps more modern than
Speaker A
Nginx. Um you can take a look at its, you know, uh what's what's great about it if you want. You can just read through like why why choose Envoy, blah blah blah. But essentially, we wanted [clears throat] to replace the
Speaker A
enterprise load balancers we had, make them self-service, so that devs effectively didn't have to talk to us to go set up their load balancing. So, Envoy has an API that allows you to configure it dynamically. Being able to
Speaker A
reload the configuration at run time means that you can deploy a whole bunch of proxies and have them sit there running all the time.
Speaker A
And then when someone needs different configuration for their particular uh service, then they can push out a change through the provisioning task detailed here. And those changes should flow to the proxy somehow. And so now, that's a good time to talk about the Envoy
Speaker A
management server that I built, which we called the Envoy control plane. And this was it's essentially quite similar uh to this.
Speaker A
Yet again, we used a Fast API app. But this was slightly different actually. Let's go into a little bit of detail here. I'm just going to wing this because I should be able to wing it because I know it quite well. Uh this is
Speaker A
actually a I open sourced this this software and I called it Sovereign. You can actually go find that on Bitbucket.
Speaker A
It's it's a public repo at least for now. I don't know if that's going to be the case always.
Speaker A
But essentially Sovereign runs a Fast API app. And some of the things that it takes in as uh configuration are templates and context. And so the app uh polls these. Uh it's obviously got like uh say let's just say this is the
Speaker A
configuration. Okay, let's stick Now, so the templates might be particular resource types. And in Envoy, you've got stuff like clusters, routes, listeners.
Speaker A
And let's just leave it at that for the moment. You'd have these kind of templates. And so when this when this management server loads up, it'll read in these templates in the context and make these available as APIs for the uh
Speaker A
proxies. So then you can imagine let's just say we've got uh an Envoy here.
Speaker A
It is going to request these things and Sovereign is going to respond by taking the context, putting it into the templates, and rendering out different content uh as the context changes. Now, where does the context come from? Well,
Speaker A
this is part of this management server that is dynamic. So well, let's just uh let's just do a bit of flip around here.
Speaker A
Put the context the context actually comes from this database, but we are requesting it from the broker. So, the we're we're requesting data from the broker and other sources, in fact. Let's just add another source here. Let's just say we
Speaker A
have a little S3 bucket with some data, and maybe that data is changing over time. So, we take that data, it's dynamic, we feed that into the templates. The The templates have logic that spits out particular Envoy configuration, and then the proxy
Speaker A
changes over time. So, what happens is we've got a client that's making a provisioning requests to our broker. The worker is doing some provisioning tasks, and then writing the new data to the database. Then the the management server, let's say. Stop this. Let's
Speaker A
encapsulate this a little bit. The management server is then polling that data from various places and generating new configuration. That configuration hits the proxy, and then it starts doing different stuff. That is essentially the second part of what I built. So, we've
Speaker A
got a broker, we've got a management server, we've got the client, we've got the proxy. Uh why did this detach?
Speaker A
Anyway, so now we've sort of figured this stuff out. This is all at a very high level.
Speaker A
[clears throat] So, we've got this created. Now we can sort of think more about more infrastructure type things. We've got this proxy, but how do we end up with this proxy? How does that actually get provisioned? What is it? Where does it
Speaker A
live? Well, let's start with one thing, which is that these proxies, there's many many many of them, as you would expect, and they are provisioned by um they are provisioned by a CloudFormation template. This is an AWS thing that
Speaker A
allows you to essentially do infrastructure as code, and it allows you to create resources in in AWS that you would normally create via the console if you were just uh uh let's say uh basic user. So, what kind of stuff do
Speaker A
we create in here? Well, if we were to do this stuff from scratch, we'd probably have like a VPC and then we'd have uh you know, a subnet inside that VPC and maybe we'd have an internet gateway, maybe we'd have
Speaker A
uh we'd all security group, maybe we'd have a key pair, maybe an IAM role.
Speaker A
Um oh, of course we need to have the auto scaling group. Of course, that's what's going to be creating these EC2 instances.
Speaker A
And well, the auto scaling group needs an AMI, doesn't it? Well, indeed it does need an AMI. IAM role has to be attached to uh must be attached to all these. The key pair goes on on the these. Security
Speaker A
group is attached to to the this Well, it's probably attached to the auto scaling group to be fair. Well, the EC2 instances would inherit it from the from the ASG, blah blah blah. So, we've got all these like uh blocks of
Speaker A
resources and stuff like that. Cool. Let's let's put these up put these up together, blah blah blah. Cool. So, yeah, we've kind of got like a little template going on here and it's creating these proxies in many different regions.
Speaker A
Uh we might have we might have like uh an NLB in here, a layer four proxy.
Speaker A
Maybe we'd have uh bit of maybe a bit of ACM. Of course, these acronyms might mean nothing to some people, but for people that have used AWS, they would know what these things are. And they know it's not really that complicated.
Speaker A
It's like pretty basic building blocks and this is what we created uh say 2,000 proxies, uh something like 13 regions, blah blah blah. Um and we also had a little bit of route 53 records for other stuff. Now,
Speaker A
the AMI, it's not really provisioned by the the template. It's more like it's referenced by the template, isn't it?
Speaker A
So, that would bring us on to the next piece of this thing that I built, which is, well, we need to produce an AMI. We need to produce a standard image for these proxies, and it's going to include
Speaker A
all the important stuff in there. So, how do we create this image for the proxy? Well, in this case, we had uh repository that was using HashiCorp Packer and uh we had um a Salt Stack uh let's call it configuration.
Speaker A
And so, we would use Packer to um let's say we'd have the EC Oh, we'd use the EC2 provisioner. And so, we would create an EC2 in like a dev account. We'd then upload all of our Salt Stack
Speaker A
configuration. Salt Stack, by the way, is very similar to Puppet, Ansible, and Chef, in case you're not aware of what those are. It is configuration management tools, and that's a fancy way of saying that I want to run I want to
Speaker A
install packages, put files, and run services on a machine in a particular way, in a particular order, and it automates that process, makes that process declarative for you. Well, not for you, but it helps you to to make it
Speaker A
declarative. So, we created a little um created a little EC2 live running EC2 here. We dump the config on there, we do a provisioning step, and then we take the uh essentially turn this into an image, like shut it down, uh whatever, snapshot
Speaker A
it, and turn it into an image. So, that essentially would just produce this uh AMI. Now, what was included in here?
Speaker A
Let's Let's say we can just uh we can include a few things here. Let's just say we had um we had states for for Envoy. So, like let's say install, configure, uh let's say just install and configure Envoy Uh
Speaker A
logging agents, security, let's say slash hardening, network tuning, containers, tracing. Oh, let's just say let's just say observability agent there. And that can cover I can cover logging, tracing, metrics. So, that's essentially what's going on here. Produces the AMI,
Speaker A
CloudFormation template takes this AMI provisions these EC2s EC2. And they're running with all this stuff. And then when they when they get provisioned, that's something that we forgot here. There's parameters.
Speaker A
Parameters, bump that up, bump this up, make it neat. So, we've got the parameters and these at runtime would pass in secrets and keys and blah blah blah. And then these these proxies would grab the resources, be configured, and then they would be
Speaker A
running and accepting traffic. Boom, that's it. Everything's done, working. This was essentially the first two years of working at Lyft. So, now when a developer says, "I want to run my service and I want it to be I want it to be accessible on the
Speaker A
internet with all the fancy bells and whistles and routing and advanced stuff." We'd say, "Yes, no problem. Let me just get that provisioned for you." We send off the provisioning task, we write something to the database, we tell them
Speaker A
it's ready, then the management server, it's the broker says, "What's the current state of things?" Takes that data, plus other data, puts it into the templates, creates resources out of those templates, gives them to Envoy on when it requests them. And this was all
Speaker A
pre-provisioned. That's long-lived infrastructure with CloudFormation. And the CloudFormation is relying on an AMI that it can use to provision those images, those machines.
Speaker A
So, yeah, that is probably the first 24 months. So, what was next after this?
Speaker A
So, this was the foundation of our team, essentially the product that we were going forward with, um which is uh centralized load balancing managed by our team, and all of the features that we provided to our customers would live
Speaker A
in logic defined in these templates. We've now laid the foundation for the team. We've got proxy infrastructure that's reacting dynamically to services that are being deployed with different configurations over time. What was next after that point? The big thing after
Speaker A
that was taking some of the larger products and making it possible for them to use this platform component. That was one big part, and the second big part was migrating all of the microservices within Atlassian to use this. And that
Speaker A
was relatively easier because we could enforce that through the platform. Essentially, what that means is that the platform was previously providing very basic load balancing to every service.
Speaker A
And they forced a switch to where you could no longer expose your service publicly through their load balancer, which is too basic, and you had to go through our centralized load balancing infrastructure and to explicitly configure it as a way of signaling your
Speaker A
intention for that service to be publicly accessible. Whereas previously, it could have just been maybe accidental that your service was public and not very well protected. So, that was the big major push. We got products like Jira Confluence Bitbucket Status
Speaker A
Page, and many others behind this edge infrastructure. And then, what was after that? Well, now we can sort of talk more about Let's say we can talk more about the uh the Envoy-based product that we had here. So, this particular thing,
Speaker A
we've got this groundwork of being able to take basic inputs from a a developer and to turn that into templated configuration. Now, Envoy has a lot of configuration. It has a lot of stuff you can configure. Let's just look at the
Speaker A
routes, for example. Let's look at the virtual host, for example. You can configure what domains to accept traffic on. Pretty basic. You can do routing.
Speaker A
Sort of basic, but once you delve into how you can do this, it gets pretty complicated pretty quickly. You can match on different things. You can route it in different ways. You can do direct responses. do redirects, blah, blah,
Speaker A
blah. You can add and remove headers. I guess I guess you could say that's pretty standard, but you can also choose, for example, when you're configuring a route action, you can also choose to send to any cluster that's on
Speaker A
the proxy. So, then if I have a thousand devs, or a thousand services, and they each have their own cluster, and any route can send to any cluster, well, it sort of brings up this point of well, this
Speaker A
data here needs to be validating that and abstracting that, and so on and so forth. So, there was definitely a concentration of a lot of the development work around this logic here, making sure it was validated here in
Speaker A
terms of the parameters were validated such that when those parameters were run through the logic in these in these resources, that it would produce valid resources. Pretty standard, I suppose you could say. I don't know. Maybe I do
Speaker A
feel like I have the curse of knowledge. Um and that this stuff seems easier to me now because I I've done so much with it. Uh but there's a lot. There's a lot in here. And if we go into, uh for
Speaker A
example, extensions, there's a lot of extensions that can be applied to a listener or a or a cluster. For example, you might have, uh where is it? You've got, uh network filters here. You've got all kinds of network filters. And a big
Speaker A
one that we obviously used was a HTTP connection manager, where you could configure routing and how to handle proxies and web sockets and all this stuff. And then, if we go a little bit before that, there's also things like
Speaker A
external processing and external authorization. And this sort of brings us to Oh, let's say something that happened next. So, I did briefly mention that some of the big parts after building this was to migrate big products onto Let's assume that's all
Speaker A
finished. It took It took some time. It took a couple years because there were many features that needed to be built out here and and wherever else in order to support the larger products and their special cases to work on
Speaker A
what's effectively a generic multi-tenanted platform. So, let's just assume that they're all migrated. Then, we have more features that we want to add. I did sort of allude to like we have this We have this groundwork. We have this dynamic configuration. What
Speaker A
I'm trying to say is that we we created opportunity. We created opportunity to centralize logic and to handle concerns early in the chain of requests. What I mean by that is a customer, let's just make a smiley customer. And customer is
Speaker A
someone that's using our cloud products or Atlassian cloud products. They are hitting the Let's just say they're hitting an NLB first and that's then being proxied to these boys. Yes? If we can deal with the problems here before they reach a
Speaker A
service, let's say and let's give it a square. Let's call it a back-end service, you know. So, the requests are flowing in from the customer to the proxies and to the Pretty standard stuff. If we can deal with certain concerns here before
Speaker A
it reaches here, we save a lot of time, we save some money, which is and it saves the customer time. It's great for everyone, really. Um and one of those things Now, this is where the the diagram becomes
Speaker A
complicated, so let's move off to the side. Let's just copy a few of these.
Speaker A
Let's grab three things move over to the side. We've got the customer talking to the proxy and the proxy is talking to back end. Of course, the request comes back up and back out to the customer. Fine and dandy. Yes,
Speaker A
this is a this is a proxy. Whatever, there's no surprises here. Now, without with with the products that Elysium runs, there's all kinds of stuff that needs to happen like authentication for example or authorization or DDoS protection or rate limiting or
Speaker A
access logs. All this kinds of stuff that needs to happen and it's just turns out that we can deal with them here instead of on a bazillion bazillion back end services. Just imagine there are a bazillion bazillion of these. Just
Speaker A
zillions upon zillions. See Daisy. Just zillions and zillions. They're like gazillion. Now, can you imagine if a thousand dev teams needed to deal with all this stuff plus more on their own service? It would be a tremendous waste
Speaker A
of money for the company. It would slow down features. The customer wouldn't get their features when they need them and stuff is already hard enough to deliver as it is. Thus, the platform and centralized management of resources and
Speaker A
centralized implementation of these features. So, how how were some of these things implemented? Well, DDoS protection was really provided by CloudFront. That was that was spearheaded by a colleague of mine who is very smart and conscientious. And essentially, let's make this a bit more
Speaker A
accurate. Let's just say let's get rid of these. There's an NLB here. Oh, blah blah blah blah blah. And of course, it's two-way. So, that's one way that we can take care of that concern for these back end services. Great, we've solved solved
Speaker A
the concern for that. Fantastic. These others, well, access logs, what we can do is something like we can use these network filters. Yes, we use the network filters. For example, in the HCM, we have Where are the access logs? Access log.
Speaker A
Now, remember, all of this configuration is dynamic. It's all dynamic and it is created by templates which abstract away the resource configuration from the developer who wants to configure it.
Speaker A
They provide simple parameters. Those parameters are then validated and then they are fed into the template as context so that we produce the correct template. That means that they send us a little bit of JSON and we set up this whole thing for them with
Speaker A
all the access logging and blah blah blah, whatever. So, that is done, in fact, inside the proxy, natively.
Speaker A
Fantastic. Some of these things, however, a little bit more complicated. These things, we need to use a sidecar model where Envoy is talking out the side and then these are their own services running locally on the on the
Speaker A
proxy. So, these would be like containers, essentially. We've got this sidecar model and those sidecars, some of them were contributed by other teams and some of them were created by me and our team. The authentication and the authentication sidecar was created by
Speaker A
me, written, of course, in the Lord's language, Rust. Authorization was done by another team and rate limiting was done by another team. And so, they were able to contribute these sidecars, which, by the way, were set up and
Speaker A
were downloaded and configured onto the AMI by this provisioning AMI provisioning flow. Great. So, now we have a programmable proxy with sidecars that have their own separate logic from the proxy and they, too, can actually receive configuration, which is dynamic
Speaker A
over the wire locally and and make it even more program. So, we're solving all these concerns before they hit these these back ends and in very very little time. So, that was essentially that is some of the stuff I
Speaker A
worked on after migrations and blah blah blah. Yay. What I do after that? With this big blob rid of this mess. So, then we had some non-technical requirements come through. More compliance and things like that. And that effort
Speaker A
was very tedious and boring for me personally. It didn't involve building new stuff. It involved taking all of this, making sure that it was compliance for in certain ways. Very bored boring checklist ticking work. Blah blah blah.
Speaker A
So, I said earlier that I would also go over some of the non-technical things that I had to go through while working at Atlassian. Obviously, all of that stuff is sort of high-level technical stuff that I just showed. What was some
Speaker A
of the other stuff that I went through during my eight-year slog at Atlassian? The first few things to come that come to mind is that I have grown tremendously in my diplomacy skills, conflict avoidance, probably conflict resolution as well. Being able to
Speaker A
persuade, propose ideas, being able to teach, educate, and mentor. These are the non-technical things that you probably don't hear a lot about. But after Another thing is that the ability to maintain things, maintain software and systems, to see where the cracks
Speaker A
show up and to build things so that those cracks don't show up as or at least to make them show up late as possible. That's definitely something that I picked up. Let's just talk about that maintenance for a sec. I noticed
Speaker A
over the eight years that I was there, when I built these apps, these services, that there's obviously that at the very start there's the requirement to onboard people and write documentation and train people so that they understand how things work, know
Speaker A
how to contribute to them, and debug them. So that when they become when they go on call, they know where to look, what could go wrong, where do things break essentially. So, you know, that's whether that's knowing what kind of what
Speaker A
particular log messages mean, what sort of metrics to check when something is going wrong and what those metrics could allude to, how to resolve those um you know, particular expected problems if they're not automated away.
Speaker A
Um and this could be like, you know, Amazon could have an outage and the database isn't access for example. What do you do in that case? What if SQS stops working and you can't do any provisioning tasks? What how what impact
Speaker A
does that have on the services that need to provision the resources? And how do you resolve um What happens if an if a proxy receives bad configuration? What if it receives configuration that's valid, but that destroys the traffic that's flowing
Speaker A
through? How do you pick up on those? What do you check, etc. etc. So there's obviously a lot of that at the start when you build something. There's a lot of that at the start. But the thing that's more difficult is over time
Speaker A
people come and go. People get hired. People get people leave for other jobs and whatnot. And so you get you have to do that onboarding again obviously. But you should have more people that are able to do that onboarding collectively.
Speaker A
But then you sort of bring in new opinions. People look at an existing codebase and they want to change things.
Speaker A
They want to make it better, and so on and so forth. And so they do that. And change ends There's I I suppose there's this concept of churn in the codebase.
Speaker A
The area that churns, it's sort of it becomes predictable where all the churn is going to be at a certain stage. And once you notice that there is some churn, it's sort of a a smell. It is it's an indication that
Speaker A
that part of the service or project is going to keep increasing in size or complexity. And something there needs to happen. Something needs to be done to avoid that mess. It's just just how software goes, I suppose. It'll be
Speaker A
interesting with all these vibe coded apps and AI assisted apps to see how we handle that. When we have people that are not really familiar with what they've created, and the maintenance burdens appear. They don't appear at the beginning. There's just
Speaker A
not enough going through. It hasn't been around for long enough. There hasn't been enough changes. Building something is easy. Changing it and making sure that it you can still change it over time is difficult. Because as you change
Speaker A
things, it slowly becomes harder to change. Things start to get coupled, and all of a sudden when you change something in one area, it affects another, and you have to deal with the task of detangling something. And you
Speaker A
might be able to find these areas quite quickly, get an LLM to perform the detangling for you. I think that's If we can do that, that's fantastic. But I don't want to be too optimistic just in case. So, there's that on That's my
Speaker A
opinion on the maintenance side of things. The next thing I want to talk about is when I mentioned diplomacy, what I'm really trying to say is that I was exposed to different types of managers and colleagues over time. And
Speaker A
everyone has different personalities and styles of working. And because I was exposed to so many different types, I experienced conflicts with certain people. And even though I had conflicts, there's still people that I respect.
Speaker A
It's just something that happens when you when your personality doesn't mix with their personality. And that's just something that's a bit inevitable. And I think that the only thing you can really do in those situations is to try to have
Speaker A
the self-awareness and the awareness of the other person and the, I suppose, understanding of psychology and and how people work to an extent, so that you can be responsible for that difference and the potential for conflict, and to
Speaker A
handle it effective to to anticipate the conflict that's going to arise and and to do something to make the relationship work. And maybe it's impossible. I don't know. But that was definitely a source of great stress and at [clears throat]
Speaker A
times it affected my performance. And so I do think that because it affected my performance that I took it quite seriously and I learned and changed as a result. So the next time that those situations come around, I do firmly
Speaker A
believe that I'll be able to handle them quite a lot better. And then some of the other things, in fact one of the things that I found quite challenging was mentoring. And so I find it easy to help
Speaker A
people to point out areas where they need understanding and to deliver that understanding to them, to break down complex things into simple terms so that they can build a mental model of the system that they're working on. I have
Speaker A
that ability. I'm quite good at that. But mentoring is distinct from that. I had an intern in the last year and I will first say that the result of their internship was that they got the highest rating possible and it essentially
Speaker A
guarantees an offer to work at a last year. The project that they worked on was very impressive and how they approached it and and built it was very impressive.
Speaker A
And so that's why they got that excellent rating. What I found personally difficult was striking the balance between It was essentially striking the balance between how much time I give to the mentee and what that time would consist of, whether it's, you
Speaker A
know, I didn't I don't want to give them answers to problems, but I don't want them to get so stuck that they become frustrated. I have no idea if I reached that balance, but I suppose the results speak for themselves. I I but I I don't
Speaker A
I don't I'm not sure if I can attribute the results to me necessarily. The intern was helped by some of my other colleagues when in areas that I'm much weaker in. So, they effectively got subject matter experts in a few
Speaker A
different areas to contribute to their success. But then they did the majority of the legwork to actually build the thing and to test it and to make design decisions and stuff like that. And it was very successful. But I still have
Speaker A
this lingering impression of feeling that mentoring is difficult for me and that I I don't have um a good way of um figuring that out because I've never been mentored myself. So, I don't really know what to expect and what they do.
Speaker A
But I want to emphasize that that's a very specific type of mentoring that I'm not too sure about. Whereas training my colleagues, getting them to understand, working, you know, working through problems with my colleagues, that was that was essentially my bread and butter
Speaker A
during the last half of my employment. You know, jumping on uh uh call and going through stuff. Feedback that I got from my colleagues all the time was that I was always available to help and that I could boil down hard topics into
Speaker A
something that was understandable, which I'm pretty proud of. And I've been yapping for a while. I think that covers a quite a lot. If I remember more, I'll probably just make a second video. Um maybe maybe if people are interested, I
Speaker A
could actually go through and build some of these things. I could actually go through and build some of these things from scratch on stream or just a video uploaded to kind of show, I guess, essentially what I made and maybe
Speaker A
recreate and sharpen my skills a little bit more. Um maybe. I've got a lot of stuff on my to-do list, so maybe maybe not. It depends on the demand. Anyway, I'm going to cut the video from here. If
Speaker A
you listened all the way through or to portions, then thank you very much. I hope it was interesting and enlightening and whatever else. I'll catch you around.
Topics:Atlassianlayoffsinterview processtechnical interviewPythonFastAPIself-service provisioningKubernetescloud infrastructuresoftware engineering
