Round 0: Resume based shortlisting
The first shortlisting was done based on resumes (you can check out my resume at sarkarsoham.com). The people shortlisted for Dev had a CGPA of 8.5+ except a few(hardly 1-2) who had exceptional project sections and experience including GSOC etc. For other roles the CGPA cutoff was 8+. Since it is a company dealing with distributed databases, if you have projects around that it'd be a plus, and a lot of people(almost all) had put their Big Data projects(Kafka-Raft, a small scale Distributed system). I wanted to stand out a bit so did not upload my Big Data project, instead, I uploaded other systems projects such as building a shell(https://github.com/Sohoxic/Shellify), a project related to socket programming in C(https://github.com/Sohoxic/Connectify/), etc. Also, I had put one of my research papers related to Big Data technologies(check out in my resume Research paper section @sarkarsoham.com).
Round 1: Offline interview at Campus
This round comprised of questionnaire related to my resume, my projects especially Connectify(https://github.com/Sohoxic/Connectify/) because the interviewer was intrigued that I used C for sockets instead of python which is usually taught in college and also he worked on a project in sockets so he was interested. Then I was asked about CN OSI layers in detail, about CSMA/CA, CSMA/CD, etc. Then the interviewer moved to my second project which was building a shell. Since I had made use of make so he questioned me about makefiles and how does make work, followed by the data structure most appropriate to implement what the command make does, i.e., make determines if a target needs to be rebuilt by comparing the timestamps of the target and its dependencies. If any dependency is newer than the target, it indicates that the dependency has changed since the target was last built, necessitating a rebuild.
target: dependencies
command
He asked me to code it up using hashmaps, he gave the structure. Followed by it he asked me to use any other non linear data structure which would be a better approach to this. I knew that make builds a dependency graph from the Makefile, where nodes represent files, and edges represent dependencies between them. The graph shows the relationship between different files and their dependencies. Then I was to pseudo-code it and talk about the traversal techniques, and what happens if there's a cyclic dependency(We can check for cyclic dependency on graphs quite easily). He increased the complexity by asking me to only check for diff in the files and then only compile the parts that are being changed.
After that we talked about fragmentation and other memory management techniques in OS.
In the end he asked me if I had any questions as such and we talked about his role in the company etc. The interview went on for an hour or more.
Round 2: Offline interview - Hardcore DSA
This might vary for different roles and also on the stuff you have put in your resume, since I had more systems-related stuff he gave me a real-world example and asked me to code it up. I do not remember the exact question, but it's not a leet code question but a problem in databases that can be solved during data structures, it was a tough question but we worked through the solution together, and I made sure I understood the interviewer's question properly and asked him as many doubts in the beginning as possible and then tried not taking help during the process of me iterating through the solution. I was asked to look at all the edge cases and then constructed an n-ary tree and then serialised, deserialised it(it's hard to come to the understanding that n-ary tree would be the best fit for this, and there were a lot of other constraints). Then I had to code it up properly. Once this was over, my interviewer was really impressed with the edge cases that I took care of and how I clean-coded it(thanks to https://takeuforward.org/).
The interviewer was interested in kernels and since I had worked on that, he started asking me about the internal workings of it, followed by concurrency control, mutex, semaphores, and code it up. I was then given a scenario where there could be contention for the binary semaphore leading to the condition that semaphores were supposed to solve but is a problem now. We could use atomic variables in this case. This round was around an hour and a half.
Round 3: Offline interview - Code it Up on Laptop
This round was mainly me coding on my laptop on the text editor of my choice. I was asked to code up a logging function in C/C++ which had the following criteria:
The message was a user-defined data structure consisting of x,y,z fields of example.
The client machine should sent the log files to the server in an orderly manner.
I made use of headers along with the payload(the message). The header had the timestamp so that we can take care of the time orderly storage of the logs.
I used sockets for the communication.
Write code for parallel access to the logging function, not concurrent so semaphores won't help, and the processes shouldn't be made to wait for locks, it should be instant.
I made use of a distributed buffer for parallelism not concurrency, if n processes called the logging function at once then n process should be able to write to the distributed buffer parallely at the same time with slots in the buffer specific to the processes.
Even this was a pretty lengthy interview(can't really recall the time).
Round 4: HR round
I was told about the company and what they do, the HR congratulated and told about my joining and that they'd send a mail to the placement office that evening confirming my position. I talked about how I really wanted to work in a company such as Couchbase working with distributed systems. It felt really good to be around good devs and being interviewed by them.