I was referred to this role through a friend. A recruiter approached me and explained the interview process in detail. It was quite helpful, although I felt they were reading from an internal script.

The first round consisted of two back-to-back coding proficiency interviews, each lasting one hour. Each interview included 45 minutes of coding and 15 minutes for questions. The challenges weren't overly difficult, but they expected the code to be expandable. The LeetCode sections for Atlassian were not very helpful, as the requirements kept changing, which is expected for interviews at this level.

A day after the coding interviews, the recruiter contacted me, stating I had passed and had reviewed feedback from previous sessions. This aligned with my feelings, though some comments seemed a bit nitpicky.

The recruiter also mentioned what to prepare for the systems design interview. Again, the information was detailed and seemed like a precompiled info kit for them. However, the system design introduction during this call didn't quite match my later experience.

I booked the systems design interview for the following week. Two people interviewed me: one was the main interviewer, and the other was listening/shadowing.

In the system design interview, they ended up asking what I considered to be very unimportant details about the system. This, in turn, wasted time that could have been spent diving into the actual systems.

Eventually, it took them another two days to reach a conclusion, and they rejected me after the system design interview. The recruiter replied and promised a feedback session. However, they ghosted me after I provided my availability.

My takeaway is that the interviewers needed to be guided. They expect you to provide improvements independently, but when I tried to suggest improvements, they didn't want me to follow that path (I was turned down twice for considering improvements during interviews).

I don't want to be bitter about the result, as this outcome was somewhat expected. However, I do believe there's room for improvement. Given it's a senior role, the questions should be more focused on the day-to-day responsibilities of a senior position, especially in the system design portion of the interview, which I have detailed below.

Coding interviews using Python.

1. Coding: Design a rate limiter. This part was easy. I had experience writing Ethernet switch controllers in the past, so I just wrote a quick token bucket to solve it. I had written the test cases beforehand with doctest and quickly expanded the system into a rate limiter object that can create/update buckets and bucket sizes, which was an added challenge. I offered to make it aware of customers, but they didn't want me to extend it. I provided my code to the interviewer.

Feedback: I can't remember it clearly, but the interviewer did point out something I could improve. Perhaps horizontal scalability? Rate limiting is an interesting topic with many areas for improvement, and they should start a topic to ask for.

1. Coding: Count votes. This is a question tagged "Atlassian" on LeetCode, but the question is vastly different. So, LeetCode wasn't helpful here. The question was to design a system to count votes from ballots, with a maximum of 3 candidates per ballot, and return the winning candidate by points. The first-place candidate wins 3 points, and the last-place candidate wins 1 point.

Question updated: Tie-breaking strategy. They wanted a tie-breaking strategy so that the first one to win the maximum points wins. I suggested that in this case, the tally needs to run at least twice, as I need to know the maximum points first, as well as the time-series data. I expanded to multiple methods in the object to deal with the tie-breaking strategy. I implemented it; however, for some reason, the Python interpreter refused to print the correct value, even though I had traced the correct result being stored in the array from the debugger. In the end, the interviewer, to my surprise, took that as the correct result.

Feedback: I was quite anxious due to lack of sleep and interview preparation anxiety. On top of that, the minor glitch with printing results prevented me from printing the result correctly. I think I was borderline rejected but somehow got to the next round.

1. System design: Building a tagging system. This question is quite common in its kind. I tried to answer it from the perspective of a normal scalable serverless web application, using API Gateway + Lambda + DynamoDB, as this was what I was good at and I could talk about scalability, availability, and operational excellence perspectives. But instead, the interviewer asked me to come up with a detailed design of a RESTful API, rather than providing an API prototype as a language function. I wrote all the APIs required for this action, with GET/POST/DELETE/PATCH actions together with URL endpoints, payloads, URL semantics, and URL attributes. That alone took more than 15 minutes, and in total, they only had 40 minutes to discuss the rest of the architecture. I did, however, try to squeeze in as much as possible about the scalability of API Gateway, Lambda, partition key selection, and sharding in DynamoDB. I discussed key selections for different tables, like partition/sort/global secondary keys, as well as adaptive partition limits for DynamoDB.