The process took approximately five months.

I applied online sometime around May or June of 2019. It's a five-part process.

Initially, I was sent a Hackerrank challenge. I had read that you needed to complete two to pass, and I completed three out of five tasks and never heard back.

Fast forward to around October, I received an email apologizing for not following up. From then onwards, the process was very efficient, and contact was very regular.

Stage 2 was a phone interview. This was a fairly easy, casual discussion with a recruitment officer. They want to know a bit more about you, why you're changing roles, why you want to join Atlassian, and what you enjoy working on. Just be honest and forthcoming.

Stage 3 is where it heats up.

This is a coding challenge done as a peer programming exercise with one of their engineers. You're given about five to ten minutes at the start of the interview to go over the code. Mine was a user management service.

Along with the code comes a PDF with a series of questions that increase in difficulty. These questions are written in a simple bug report/feature request format that you need to solve. I asked my interviewer if the expectation was to finish all questions. He said he'd never had someone finish, so it seems to me that the primary intent is to understand your workflow, probe your depth of knowledge, and see how you tackle a problem.

It is extremely helpful to think out loud as much as possible. Even if you start down the wrong path, it gives the interviewer openings to question your process, which itself can be very insightful, as they may reveal things you hadn't considered.

Learn TDD. They want to see you test your code properly. I can't overstate this enough, including edge cases. In my case, considering the edge cases out loud satisfied my interviewer, and he told me I could ignore writing them in the interest of time but that it was good that I had noted those cases.

Stage 4 is what they call a project deep dive.

Describe your application in-depth. The more you can talk about it, the better. Practice this! In my case, they asked almost no questions for the first fifteen to twenty minutes and let me speak uninterrupted. Practice drawing your architecture on a whiteboard. Practice your discussion flow so that you can plan out the points you want to focus on. Speak about the areas that you feel most comfortable answering tough questions about because they will ask you to justify your choices. The more openings you can give them to ask questions about what you do know will reduce the number of questions on things you may feel less comfortable with.

Be humble. It's okay to discuss areas of application design where you made mistakes. In my case, I confessed to some poor choices around an API design but was able to justify them by acknowledging restrictions in the infrastructure to which we were deploying, as well as how I might tackle that problem differently with what I've learned since then.

Be prepared to answer questions on REST architecture, performance, memory management, bug discovery and the process of identification, testing methodology, team processes, automation, and the production environment. Basically, everything you need to consider for an end-to-end application.

Answer some technical questions. See below.

Complete a design challenge. This is pseudocode. My problem was to show an example of a basic connection pool. Things to consider are repeated method calls, concurrency, and data structures. Mentioning pitfalls in your basic design, even if you're unable to solve them there and then, is really positive and shows you've considered the issues.

Stage 5 is an assessment of behavior.

This section is primarily focused on behavior and values. You will be interviewed by one or more dev managers, one of which will be your manager if you are given an offer. In some ways, this is the hardest to prepare for. Have lots of examples of situations that demonstrate your values and constructive behavior. Even if the situation doesn't have a happy ending, be reflective in your preparation. In these cases, show how, while a mistake was made, lessons were learned.

Also, study up on Atlassian values. They are really important to the company. Find tangible examples that you can link back to these values. If you are naturally a good fit for the company, then these values will resonate with you.

In all interviews, it's positively received if you have a number of prepared questions.

One last thing, something that I really appreciated throughout the process was that after each stage, your recruitment officer reached out with feedback from your interviewers. This is incredibly valuable.

Explain your approach to breaking a monolith into microservices.

What would you change about Java?

Can you give an example of where you might come across a memory leak and how you might resolve it?

Give an example of a time where you had a conflict with a colleague and how this was resolved.

Can you tell me about a time where you had to make a big decision and how you convinced your bosses/peers that your idea was good?

Can you tell me about a time where you received negative/constructive feedback?