Atlassian | Principal | Remote [Pass]

YOE: 11+yrs

First off - Atlassian hiring folks move reeeallll slow. I told them no after 2 round of interviews. These 2 rounds took 4weeks. Usually this means my interviews didn't go well but i really doubt it (Cross verified it with other FAANG principal engineers). Feel free to judge the solution yourself though.

First round - Coding

Was given leetcode medium - Leader election and 3-4 variations of election algorithm. Was able to finish all the variations. Got a hire call in couple of days.

Second round - LLD

Typical Rate Limiter question. Asked me to code "X requests in Y seconds" and how would i make it extendable.

First off, interviewer was rudee - came late, no introduction whatsoever, assumed the interviewee is familiar with various rate limiting algorithms.

Anyway, implemented fixed time window algorithm (after choosing between token bucket or sliding time window) with appropriate interfaces.

interface RateLimiter {  
  boolean allow(int timestamp);  
}  
  
class FixedWindowRateLimiter implements RateLimiter {  
   
  FixedWindowRateLimiter(int reqCount) {}  
    
  @Override  
  boolean allow(int timestamp) {  
    // impl  
  }  
}  

The way i implemented the algorithm was a bit unusual (I'll keep that detail to myself) and i could see interviewer googling because interviewer wasn't familiar with what a specific line did. I explained that to him, also offered him that i can make this thread-safe - to which he said no.

Interviewer further asked, what if i want to extend it like rate limit based on customerId - what will i change? I told him my approach (but didn't code as i was running out of time - One might wonder why i was running out of time - HE CAME LATE!) that i would create subclasses like below:

class RateLimiterByCustomerId {  
  Map<CustomerId, RateLimiter> rateLimiter = new HashMap<>(); // concurrenthashmap to make it thread safe  
    
  RateLimiterByCustomerId(Configuration cfg) {  
    // read config and now you have per customer allowed values e.g. 10 reqs/s for c1, 5 reqs/s for c2 and so on!  
    rateLimiter.put(customerId1, new FixedWindowRateLimiter(n1));  
    rateLimiter.put(customerId2, new FixedWindowRateLimiter(n2));  
    rateLimiter.put(customerId3, new SlidingWindowRateLimiter(n3)); // different type of rate limiter supported  
  }  
}  

Similarly you can extend it by IP Adress or whatever attribute (you can even mix and match as well with these interfaces). Interviewer didn't seem convinced with this approach - I asked him what problems you see with this approach? He said "You'd create new class for every rate limiter by attribute value?" - I said - "Not by attribute value but by different attribute like IP Address or Customer Id". I didn't think he understood what i wanted to convery, only if i had time to code maybe :shrug:.

Recruiter reached out with feedback "It didn't go as well but we'll consider you for Senior engineer".

Final outcome - Took a pass as i had another offer (can't disclose details as i told recruiter) and my second round experience was very bad. No hate towards the company but clearly i was a mismatch with culture second interviewer portrayed.