Confluent Onsite | India

confluent logo
confluent
Senior Software 2Remote, India7.5 years
July 20, 20259 reads

Summary

I interviewed for a Senior Software 2 position at Confluent, experiencing a phone screen, two DSA onsite rounds, and two system design onsite rounds, but ultimately received a rejection due to system design feedback.

Full Experience

Recruiter reached out on linkedin.

Phone:

  • Given a list of doc and a query string, return which documents contain the query string in it.

Input:

[][]string{
{"this", "is", "world"}, 
{"world", "is", "great"}, 
{"leetcode", "is", "bad"} 
}

query("World") --> should return [0,1] (make sure your search is case insensitve)

follow up:

Search the document where given phrase is present

query("word is") --> should return [1] since it is only present in doc 1

Onsite 1:

  • Sudoku validation
  • Sudoku completion

Onsite 2:

  • Design a queue that support enqueue, dequeue and getRandom() operations.
  • Follow up included concurrency.
    What will happen if multiple threads are working together?
    What are the solutions available to support multiple threads?
  • Write method to compare two given queues.
    Again, follow ups were about support concurrency in this method.
  • Write UTs for the enqueue, dequeue and getRandom(). They just wanted to get idea about UT techniques.

I was asked to run the code (interviewer provided the test cases) in phone screen and 1st onsite. Wasn't asked to run code in 2nd DSA.

Onsite 3: System design

  • Create an aggregator that allows podcasts to be registeres and users to subscribe/unsubscribe different podacasts.
  • I was asked to write APIs required for it and different HTTP status code that our API can support.
  • Make sure you know when to return what http status codes.
    http://en.wikipedia.org/wiki/List_of_HTTP_status_codes

Just go through all the status codes.

  • Discussion included what kind of DB should be used. SQL vs NoSQL etc.

Onsite 4: System design

  • Create a temp email service with TTL of 5 hours per email
  • How to generate unique emails that are not too long.
    My suggestion is to use a redis counter that starts from 1 Billion and then increment it by 1 when a new email is created. The number is not a appropriate email-id so it should be base62 encoded which will convert it into alpha-numeric string. To make it more secure and unpredictable, the service can pick a random adjective from a huge list (5k english words) and append the counter string to it.
  • What kind of DB to store the create the emails?
  • How will access be denied once the email id expires?
  • Discuss Data archival once the emails are expired.

Verdict: Reject. System design feedback was not great.

Interviewers were good and helpful.

Interview Questions (8)

Q1
Document Search with Keyword
Data Structures & Algorithms

Given a list of doc and a query string, return which documents contain the query string in it.

Input:

[][]string{
{"this", "is", "world"}, 
{"world", "is", "great"}, 
{"leetcode", "is", "bad"} 
}

query("World") --> should return [0,1] (make sure your search is case insensitve)

follow up:

Search the document where given phrase is present

query("word is") --> should return [1] since it is only present in doc 1

Q2
Sudoku Validation
Data Structures & Algorithms

Sudoku validation

Q3
Sudoku Completion
Data Structures & Algorithms

Sudoku completion

Q4
Design Queue with Enqueue, Dequeue, GetRandom
Data Structures & Algorithms

Design a queue that support enqueue, dequeue and getRandom() operations.

Follow up included concurrency.
What will happen if multiple threads are working together?
What are the solutions available to support multiple threads?

Q5
Compare Two Queues with Concurrency
Data Structures & Algorithms

Write method to compare two given queues.

Again, follow ups were about support concurrency in this method.

Q6
Write Unit Tests for Queue Operations
Other

Write UTs for the enqueue, dequeue and getRandom(). They just wanted to get idea about UT techniques.

Q7
Design Podcast Aggregator
System DesignHard

Create an aggregator that allows podcasts to be registeres and users to subscribe/unsubscribe different podacasts.

I was asked to write APIs required for it and different HTTP status code that our API can support.

Make sure you know when to return what http status codes.
http://en.wikipedia.org/wiki/List_of_HTTP_status_codes

Just go through all the status codes.

Discussion included what kind of DB should be used. SQL vs NoSQL etc.

Q8
Design Temporary Email Service with TTL
System DesignHard

Create a temp email service with TTL of 5 hours per email.

How to generate unique emails that are not too long.

What kind of DB to store the create the emails?

How will access be denied once the email id expires?

Discuss Data archival once the emails are expired.

Discussion (0)

Share your thoughts and ask questions

Join the Discussion

Sign in with Google to share your thoughts and ask questions

No comments yet

Be the first to share your thoughts and start the discussion!