My Interview Experience at FareHarbor (Senior Engineer, SDE3)

My current years of experience are 4 years. FareHarbor is part of Booking Holdings, so their interview process, salary, and perks are quite similar to Booking.com.

For senior roles, the recruiter conducted an in-depth 30-40 minute discussion about my experiences and their relevance to the role. For senior positions, I was expected to lead every aspect of the interview.

Round 1: Telephonic Interview (Coding) - 40min

This round was designed to assess my coding ability. It was a medium/easy level, structured coding problem where I also had to have a running code.

The problem involved processing a file containing many log lines with: timestamp, eventid, event state description, for example:

1, id1, event started
2, id1, files uploaded
3, id2, process is running
4, id1, event complete

I was asked to:

1. Find all events that are complete (an event must have started and must have completed).
2. Find all open events (events started but not completed).
3. Find all invalid events (no event start history).
4. Find top N longest running events where N is variable.

I was able to solve this successfully and run my code without issues.

Round 2: Hiring Manager and Cultural Fit - 1hr

This round involved various questions around my experience and what would be expected in the role. Some knowledge about FareHarbor's product was also beneficial.

Round 3: Coding Round 2 (Algorithmic) - 1hr

This was a LeetCode Medium problem, more algorithmic in nature. I received a variation of a BFS problem where I was asked to find the number of hops (shortest path) between point 2 from point 1 in a graph. I solved and ran it successfully. It was followed up with a discussion on what happens if we have a graph with uneven distances between points, negative distances, etc. I discussed Dijkstra's Algorithm, its time complexity, and when to choose BFS versus DFS.

Round 4: System Design - 1hr

The problem was to design a system similar to Zapier:

• A system where a user can integrate apps in a platform, and based on certain events happening in App1, trigger events in App2.
• A user can create TRIGGERS for certain EVENTS and have RULES, and based on this, perform certain automated ACTIONs on another APP.
• Activities are logged for every event (like event triggered, action performed, etc.) and made visible in a user-facing client application. The user can check the activities of that day (maybe with an access limit of once per day). Activity tracking may be eventually consistent.

The scale was quite significant: 100 million Daily Active Users (DAU), with each user having 5 events/second, leading to a massive 500 million RPS! Based on how the interview discussions went, the final design was pretty complicated, and many tradeoffs had to be considered.

Verdict

I enjoyed all the rounds and felt I performed well to my knowledge, though there might have been some scope for improvements in the System Design round. The interviewers seemed happy as well.

Unfortunately, I received a rejection email in 2 days. It stated it was a hard decision: "In the end, it really came down to the fact that we had a number of talented applicants that had qualifications and specific experiences that are very uniquely well suited to what we are looking for in the role." I'm not sure if this is a generic rejection, but I was quite disappointed with the outcome.