I applied to a job posting on a forum and the recruiter who responded was very friendly and approachable. He asked pertinent questions about my experience and scheduled an online test followed by a coding test. The online test was quite simple - boilerplate questions in Java involving code-flow, exceptions etc. The coding test was a googly, though. I have successfully interviewed with Google, Amazon and Microsoft. In all of those interviews, they make you write code and discuss it extensively. One of those interviews was a remote coding interview, so I thought I had seen it all. But I was mistaken. Atlassian interview starts by sending some zipped code about 30 mins before the scheduled interview. I was not informed of that, so I had to pick the Skype call and sheepishly told them I needed 10 mins to download and set it up in Eclipse. Once this was done, I quickly browsed through the code. It was a simple implementation of an event subscriber system and some test cases to go with it. I assumed I would be asked to improve or debug the system. In my experience, these kinds of interviews are usually grueling. You will be asked to implement a method and then critique it in terms of efficiency, design and logic. You may be asked about the algorithmic complexity (O(n) etc) and challenged to improve it. Or you may be asked questioned about the fallacy of the design or checked on whether you handle the edge-cases etc. gracefully. In Atlassian's interview, however, no such questions were asked. They asked me to fix a failing test, which pointed to a simple bug. They objected to one of my methods, asking me to check the javadoc of the API I was supposed to use. Apparently, the javadoc specified it differently from how I assumed and I went back to correct it. They asked me to change a behaviour and I promptly wrote a test case to drive it. When I had to debug a failing tests, I used some sysouts though they hinted to me about the debugger. When I was puzzled by a method in the Java library, I googled for it. End of the interview, all tests were green and I was happy. Apparently, they weren't. The recruiter called me back after a week and told me they were rejecting me because they considered me borderline. Specifically, they were unhappy about me not using the debugger and not reading the javadoc carefully. I was really surprised initially but then later, it made sense. I was used to interviews which tested for programming concepts, knowledge of algorithms and data-structures, program-design skills etc. But this was, I realized in retrospect, a test of software engineering principles. "They were testing to see if I followed software engineering best-practices". TDD check, debugger check, attention to javadoc check. Personally, I am not sure if those are the most important qualities to look out for. But I wish I had known upfront that this is what they were looking for. Which is why, I thought it'll be a good idea to write this up for someone else's benefit. I am also adding specific stuff they gave me as feedback, as interview questions below. Overall, this was a sort of weird experience, because I don't know what to take back home. For comparison, I was convinced about Amazon by a particular phone-screen interview in which a guy grilled me about computer architecture right from the command 'ls' down to the bits that move around in the microprocessor. A google interviewer tested my debugging skills by posing a problem of a server that responds late few times every day - "Now, how will you start to analyze the problem? Where can problems lie - DB, Web server? How do you zero in?". Atlassian's interview was more of a checklist of best practices. So, it should be easy to beat, right? :-) All the best