Status: CS Student, 1yr xp
Location: undisclosed
Position: New Grad SE.

This post will outline the experience I had during the interview process as well as a heavy focus on how I prepared - I hope it can help someone.

I didn't want to apply to many places at once, I wanted to focus on one company and do well in it.

There are four rounds: phone-screen, algorithms onsite, systems-design (+ senior eng discussion with hr). All 1h-1.5h

The phone screen and algorithms on site are very similar - the questions I had received are Leetcode tagged - or (mainly) variations/extensions of those tagged.

It's clear that the focus is not just your problem solving on easy/med/hard but also your ability to communicate. A good programmer could solve 'easy' but not discuss appropriately and fail.

The systems design I have not seen tagged before but they follow common themes...

For these interviews I wanted to be able to demonstrate fluency in the following:

• Fluency in problem-solving with data structures and algorithms, (distributed systems for systems interview)
• Fluency in coding (white board design for systems)
• Fluency in discussing the approach

notice the emphasis on Fluency... I will touch on all three points and how it helped me.

Coding

In the interview, you may not always need to run your code, but demonstrating coding skills is impressive and something I wanted to show.

Although I have heard that bb does prefer c++ knowledge (if you are familiar with c++ it may be preferable to use it) I opted for and advise using Python. Taking the time to learn this improved my speed in programming/fluency - often one line in python could do that of many lines in other languages, this saved me time and demonstrated fluency in the interview.

(It also means I spent more of my preparation time writing meaningful code rather than required language-specific syntax)

Time in the interview is short, I am under stress and in the ideal situation, I would want to rely on my fluency in coding rather than trying to figure out how to code an idea up. (much like a fluent speaker of a language can be far more expressive in ideas to that of a beginner).

The way I built fluency is through practice. To demonstrate coding ability, there is almost no point in doing a Leetcode exercise, understanding the approach taken but struggling to program the answer without looking at the answer.

I have suffered from the lack of programming ability and I overcame this by using (spaced) repetition, once I completed a challenge (be it 5 or 30 lines) I will delete it all and reprogram it from scratch (without any help and on multiple (>2, <10) occasions ). If I am unable to - I definitely do not have the fluency and should I be asked the same question in the real interview when under stress, I will likely underperform. Mastering the skill of coding the problem efficiently was my goal for any question I did.

Over time the number of repeats needed reduced.

For example, in the phone screen, I had an 'easy' problem (1st - tagged), a very very common problem yet still under the stress of the situation I had made an error in the code - and unless I had trained for fluency I would have likely been unable to recover as quickly as I did.

Note that I was aware of the correct approach to solving but it was my code that was initially incorrect/buggy. It's not about memorising, but coding ability.

The follow-up (2nd) question (which I hinted at during the discussion of the first solution - more on that later) was a 'medium/hard' and required utilising a hashed, ordered/double linked list and sets. I haven't programmed this before but I could imagine writing this in Java, taking many many lines but with concise use of Python, I was able to use <10 lines, hence programming the correct solution in < one minute for a 'medium/hard'.

Knowing list, set, dict and the collections were super helpful: https://docs.python.org/3/library/collections.html

I think I solved this question faster than expected by the interviewer and he asked me another (3rd -tagged) question, Rather than having a discussion then coding, we just did the former.

During any coding I did - I was sure to explain each chuck or line written.

Note: LC is not complete - you may find solutions which are not in the solutions/discussions sometimes - so spend some time to think about extensions for any problem you do.

Discussion

This is crucial - I didn't want to write code before doing all of the following:

Repeating/Confirming the problem to the interviewer.
Discussing what the inputs to the problem are - what constraints do they have?
Expected Outcome from a few examples and potentially some edge cases?

Provide solutions (more later) - Ideally More than one solution, analyse the time and space complexities, discuss which will be more appropriate.

Decide on a solution. Then program it. Getting too far into the programming then switching solutions is not a good look (but if needed, do not be afraid to explain why).

I wanted to show that I have a clear thought process and can plan ahead, but if needed I can adjust. The first being more important and the adjusting/flexibility will usually come with follow up questions/constraint change.

When proving solutions - I recommend writing them down in the comments of the code, outlining the name of the approach, time and space complexities. This demostrates a visual representation of your thought process - ensure to practise this too. I wrote many lines of block comments in interviews.

I believed the discussion would flow nicely if you propose sollutions in an order of increasing efficiency.

For Example (applying maths in a question is rare and this example illustrates how to use comment blocks):

def  sum_first(n: int):
	'''
		Compute sum  of first 'n' numbers, n>0
	
		1. List sum.  
			store/create a list of number from 1 to n and accumilate sum. 
			Time - O(n)
			Space - O(n), could be O(1) with use of generators or an iterative appraoch. 
			
		2. Mathmatical
			Description of a better appraoch - keep concise. 
			Time - O(1)
			Space - O(1)
	'''
	return n(n+1)/2

For my onsite, I had a data structures and algorithms problem, much of the time was spent discussing first a brute force (polynomial) solution and then a proposed more efficient one (linear).

At this point, I thought I was done and would move on to coding, but was hinted at by the interviewers, who also want to work with you to see how you collaborate, that a more efficient approach exists, through some further discussions and proposals a logarithmic solution had come about.

There were two coding aspects to this, both went smoothly but the discussion was thorough. I didn't need to run it due to the nature of the problem, just step through the function with imaginary inputs.

I was a bit disappointed with myself for neglecting my (high level) data structures preparation (was asked something which I knew the answer to but was unable to remember in the meeting due to no/little extended ds reading)

I remembered to also explain each line I am writing - with words not comments (comments for intricate lines only)!

Problem Solving

The solution to a data structure and algorithms problem will often involve the following ideas so I tried to be familiar with them:

Hash Maps, heaps (min/max/minmax), (Double) Linked-Lists, Sets, Stacks, Trees, Balanced Trees, Tree-Traversals, Graph-Search, Binary Search, Recussion, DP (bonus/rare: Tries)

I think the tagged questions cover many of the DS you would expect to see - these data structures and problems are seen across most companies and interviews from what I have seen.

In the end, I solved around seventy LC (mainly medium and mainly 'tagged' or mentioned in the discussion section). But this is an understatement, as each of those 70 was repeated many times, in total over 1000-2000 lines of python code were written, as I am a relative noob to LC this was crucial to build the coding fluency.

Systems Design

I had 3-4 weeks to prepare for this and I wanted to go from near noob to professional solution architect (lol), with an understanding of the following systems but particularly real-time solutions. (you can ask about what tech your interviewers in the earlier stages use).

Understanding what some key systems are, is step 0 of this preparation.

(much of the info of the core systems was found on youtube + google :/)

Some Systems:
(Apache) streaming platforms, Zookeper, Caching (redis), SQL, NO-SQL (Casandra, dynamoDB, mongo), In memory DB (Batching, write-ahead logs, snapshotting: e.g. SQLite). Messaging Queue(SQS, rabbit MQ), Publisher Subscribers (SNS), Load balancing (different levels and methods), web sockets, Spark, Horizontal & vertical Scaling, Zones, Regions.

Network: TCP, IP, UDP, multicasting,

These are some of the systems that I came across during my research and they highlight the key systems used in today's infrastructure - you will likely come across more during your research :). I was questioned on/discussed much of the above during my systems interview.

Whilst building my knowledge of the above I watched 'system design' youtube channels which go over some example of building popular systems - these are good but what I found even better was that these tech companies actually go to conferences and employees discuss the infrastructure of their company!!!

Those are some of the resources I used to build my knowledge, but I was always asking my self If I am building my fluency!

In the end, you are going to have to design a system on a whiteboard or (excalidraw.com if virtual). I needed to get used to and master this environment —> drawing services, connecting them and having spacial awareness of how everything fits together to ensure the system doesn't get too complicated or messy to read.

On paper and Excalidraw I designed various systems (be sure to master the ones on your CV first) such as Twitter, Netflix push notifications (watched their conference), batch and realtime aggregation, etc, etc. I was amazed at how many iterations (repetitions) I needed to get it "right" but also look pretty/neat - identifying bottlenecks and places of failure, trade-offs, estimations of throughput.

By practising drawing these architectures - explaining them - I began to improve.

I was given a question which related to a problem in their team - and using my developed fluency in drawing and understanding of how infrastructure is designed, I was able to use the Discussion points I mentioned before to develop and advance the solution.

This round may also involve DS/algos at some point - so be aware!

There is usually many answers to these systems and your interviewer is there to work with you to solve - they prompted me with many intricate questions about the systems that I was using to check my understanding - but I drove the conversation.

Ending

Besides building fluency and this being my core focus in the highlighted areas, there were countless times where I 'forced' my self to redesign or reprogram the same solution again and for this, I needed much will power.

I wanted the main theme of every interview to be an exhibition of my thought process. Not how to do something - I wanted to minimise the amount of time/effort on doing the grunt work (coding/drawing, making sure things are neat and interpretable) or searching my memory about what something is or how it works.

I appreciate that this method may not be for everyone, applying to one company over a three month period is not always appropriate, I have also excluded the preparation for HR interview but you can imagine that the focus is on fluency of understanding my previous experience, why bb, my goals, etc.

Often, succeeding in anything may require some form of luck (or lack of bad luck) - and may have been the case for me.

I wish you the best in your endeavours, thank you for reading.