5 min read

Original article: My Interview Experience: Atlassian (Rejected) .

I had started applying for Atlassian to all Senior positions and even tried referral. Normally I would suggest that one should by referral. It is really hard to get the resume selected if we apply through their job portal. My resume got selected after lot of trial through portal. Atlassian folks are really great, the recruiter explained me very well what they will be expecting in each rounds and how can I prepare. They give a top level overview, obviously not in depth around type of question.

In this whole process I could go appear through initial 2 rounds. I was rejected in second round. Why am in writing this blog ? My primary motivation in writing this blog is, that while I gave interview I was naive that I couldn’t gather what is expected and what would be better approach for such question and I am still open to learn how to approach such questions. After the feedback shared for round 2, I went into introspect mode and gave lot of thought, connected with different folks to get understanding of what is that I missed. I will elaborate this further in blog

Overall process For senior roles they have total 5 rounds.

1. Browser Coding round In this round I was asked a PageTree problem. It was similar to way we have side bar in confluence showing different pages and nested pages if there are any. — Main page | — Page1 | — Page2 | — Page3 | — Page4(Nested within page3)

Something of above kind and some actions also possible on them like collapse/expand. This round did go well for me Clarifying questions I had asked

1. Do we need to work on CSS while solving the problem statement or we can work on that later

2. Its simple problem statement and hence we will consider that its responsive and can be for the moment using just relative fonts, no additional things right away

3. Can I follow TDD approach ?

4. Upon click only 1 level of page below should open ?

I had solved this problem in react by creating a component which we can call recursively based on whether a page has children or not. I followed TDD completely and explained kept on discussing through each thing and what methods I was using with explanation to them. I got stuck in one position where I had written a piece of code twice which interviewer helped me correct.

I couldn’t solve all the things but it was a positive feedback for this round.

Round 2 Before this round I had did fair bit of research and I got to know after reading lot of interviews and seeing videos that the question set is very limited and questions keep on repeating. Now this can be a boon as well curse also. I had already practiced this problem statement the night before the interview. The problem statement is related to implementation of feature toggle.

We are given a function which kind of mimics like a fetch call and resolvesa object as response. This object has key value pairs , the keys being toggle key and value being boolean. There is another function getFeatureState which would return true/false resolved value as promise.

getFeatureState().then((val) =>{

if(val){

//. do some action

}else{

// do some action

}

})

I asked few clarifying questions

1. We are just assuming it simple feature toggle not associating/classifying it as release toggle/ experiment toggle etc
2. Is caching expected and is yes we can definitely go for it after basic implementation

I did not ask any more clarifying question because I had practised this (a dummy React project)earlier and it kind of turned off my critical thinking process. Ideally I should have been confident that I can implement it quickly and should have focused more on other things. Also one big mistake Idid was because I had practised in React and somehow I thought that i should show something with an working example visually and along with TDD. I went ahead and asked if I can do in React and interviewer was fine with that. Usually folks don’t say NO, they let you be comfortable with what you say and it’s is in a way good, but from actual problem statement point of view it was not good here. After lot of introspection and talking with folks I got to understand where I went wrong. Somethings which I should have done :

1. Ask around error handling mechanism , is there chance of API failing ?
2. Why was the getFeatureState function a promise?
3. Considering point 2 , show should be the UX? What is reason for promise can be also introspected from DX point of view.
4. If while calling function there is typo for the key then what should happen , how should we resolve this since we would get undefined for searching that key’s value in object.
5. How should we initialise feature toggle? When should we do that and if before initialization someone calls the getFeatureState function then what value should we resolve ? Initialisation here is subject to type of toggle, like is it for static frontend or something which is user based.
6. Rather than doing problem statement in React which again needs some kind of boiler plate at last , I should have implemented in vanilla JS. Vanilla JS I would have just needed 2 files at max. I could have tried a Object oriented way approach, singleton pattern if needed (we want to lock down object after initialisation). Above way would also explore it to be extended as library and not limited to a particular code base.
7. Different caching mechanism can be explored based on what kind of toggle it is.

This round result was not on my side, but after introspection i got to learn lot of things. Primarily its not about the solution, but what all points we explore around solution and look at it from all possible ways.

Folks do let me know if you have some points for any of above two problem statements which i might have missed and can explore. I will try to put solution after some days in another blog.

Thanks for taking time and reading blog. This is my first blog so please excuse me for mistakes in writing. Please feel free to share feedback on how can I improve on writing blog better.