Skip to content

Notes.md

Latest commit

 

History

History
184 lines (148 loc) · 11.3 KB

Notes.md

File metadata and controls

184 lines (148 loc) · 11.3 KB

This is a note of the various things related to competitive programming / doing interviews that I've gathered so far.

Things to do

Useful resources

LeetCode & co.

System Design

Interview

Helpful point

For prep i used 3 paid resources.

  • Coding ninjas (Started here, and i would still start here, considering the 24*7 doubt support )
  • Algoexpert ( Good question set)
  • LC Premium (Used for assessments)

See also buildyourownx GitHub profile which is great.

Ref: My Salary For the past 7 years. From 3.5 LPA , to 4L per month (Excluding Stocks) : r/developersIndia

By Davis

Further notes:

I used educative.io

But this has most topics from there

I think this is the best way:

  1. for concepts, go through topics here https://github.com/CatalanCabbage/notes/tree/master/system-design
  2. Read externally about each topic, etc etc
  3. Then search and read/watch on yt - netflix architecture, url shortener architecture, etc etc

IMO, there are only a few "kinds" of use cases

Like video streaming, ticket booking, social media etc

For each one watch/read Netflix architecture, bookMyShow architecture, Insta architecture and so on

Most Interview questions will fall into those buckets, so you'll have a high level idea of best approach to take

Then is the part where you dive in.

E.g. In social media, they will pick one specific part - caching, or consistency, etc

At that point, you would have learnt the concepts alone in depth right (first step)

You can use that knowledge to compare and discuss the best approach in that part

Use that and resources like these to get a lay of the building blocks, learn from whatever sources your want

https://github.com/donnemartin/system-design-primer?tab=readme-ov-file

https://github.com/ashishps1/awesome-system-design-resources?tab=readme-ov-file

Even more notes:

We just spin the context of our experience to match the expectations and fill the knowledge gaps if needed before the interview 👀

All you need is LC, system design and a load of bullshit 😂

...

Beyond the usual stuff, it's mostly luck. I try to look at the company/team to try and figure it out, also have a few questions about the product ready

And try asking the HR exactly what we can expect (with options so it's easy for them to pick - like am I expected to know xyz, or will it be xyz etc)

HR's interests are aligned with ours since they want to get people through the interviews and hire people

...

"What do you use to find relevant companies?" - LinkedIn - but these days I love the HN who's hiring thread. I've heard good things about wellfound too.

Helpful advice about changing lifestyle

A good twitter thread that deeply resonates with me: Akshaya Sivaraman on Twitter: "How did I go from a busily scheduled life to one with substantial unstructured time?

Misc. notes

Hashtable / HashMap

  • Initial capacity and load factor affect the performance of hash table / map.
  • It is open: in the case of a "hash collision", a single bucket stores multiple entries.
  • Iterators returned by "collection view methods" are fail-fast: i.e., they throw ConcurrentModificationException if they detect a concurrent modification of the underlying hashtable. This is not fool-proof / guaranteed. So, implementations should not depend on the same.
  • Hashtable is synchronized. HashMap is not. For thread safe usage, a ConcurrentHashMap is recommended.

References

Solving algorithmic problems

7 Steps to Solve Algorithm Problems

  1. Listen - Listen carefully to the problem. Every detail is necessary to solve that problem.
  2. Example - Come up with a good example. Make examples larger and avoid special cases.
  3. Come up with a brute-force algorithm - It's better to start off with a slow and terrible algorithm than to start of with nothing at all. Don't code the brute-force algorithm. Just state the brute-force algorithm and it's runtime and then go into optimizing it.
  4. Optimize
  5. Walk through your algorithm - Don't code prematurely. Take a step back and verify that the algorithm is correct.
  6. Start coding - For whiteboard: write the line straight, use space wisely; Whiteboard or computer: coding style matters, consistent coding style, naming is important for good style (ask the interviewer if you could abbreviate them the next time), MODULARIZE
  7. Start testing - analyse, double check things that look weird/risky, small test first, special cases next and if time permits large test cases. Remember: Think as you test. Don't go through the code like a bot. Test your code and not the algorithm!. When you find a bug, don't panic! Give some thought about fixing the bug.

3 techniques to solving algorithm problems

  1. B.U.D - Bottleneck, Unnecessary, Duplicates - walk through the brute force (to identity bottlenecks, unnecessary and duplicated code)
  2. Space-time tradeoffs - you can almost always save some time by trading off some space. Think about Hash tables.
  3. Do it yourself - use a large generic example and try to solve it yourself. You'll identify some nice ways to optimize when solving the problem for a large test case.

Activity log

  • 18/Sep/2024 - Continue working on the optimal solution for the Two sum problem.
  • 17/Sep/2024 - Worked on the Two sum problem. Completed the brute-force solution. Was working on optimizing the solution and was reading up on HashMap / HashTable a bit.
  • 02/Sep/2025 - Completed Cassidoo's Count battleships problem. Keeping track in Goodtime.

Places to look for openings