Skip to content

TheFenrisLycaon/DSA-C--

Repository files navigation

Interview Preperations

Data Structures

Go to wikipedia and read the whole page of each of these a few times, then write your own (for real, actually write the code and play with this stuff - that is the most important part)

  • Array
  • Linked List
  • Stack/Queue
  • Trees (Tree, Binary Tree, Binary Search Tree, Red-Black Tree, etc. Learn as many as you can)
  • Heap
  • Hash Table (this is really important - understand all of the different collision mitigation mechanisms, understand what amortized constant-time means)
  • Directed/Undirected/Weighted Graphs
  • Trie (pronounced "tree")
  • Linked Hash Map (this is very specific, but comes up a LOT in interviews)

You should know the Big-O for insert, delete, lookup, etc. for each of these. Know how the mechanics work. It isn't a good interview questions, but you should be able to code every single one of these. Then, prepare real-world examples of when you'd want to use each of these and explain why it's the best choice. Data Structures come up in technical interviews in two way. The first is in coding questions where you're expected to use the right one at the right time. The second is on a comparison question - not connected to code - "why would you use X over Y in situation Z."

Algorithms

Again, make sure you actually code these for real when practicing. Simply reading code someone else wrote will not cut it. Open up your favorite IDE and start typing. This is critical because often times you actually have a gap in your knowledge, but your scumbag brain convinces you it's ok (this happens without you even realizing it). The only way to find these gaps is by writing code. Know all of the Big-O for this and how it's derived.

You don't have to go crazy here, but review a couple of:

  • Sorting algorithms (both comparison sorting and non-comparison sorting)
  • Tree traversals (just memorize all of these inorder, preorder, postorder, level order)
  • Traversals - Dijkstra's, A*, BFS, DFS (know the difference between DFS and BFS when would you use one over the other and why - hint, is usually matters when you don't have to search the whole space. Also make sure that you can code recursively and using your own stack/queue)
  • All the prefix-tree searches

Great, you're about 60% done now. Now you need to practice applying this knowledge. Find a source of interview questions (random websites, glassdoor.com, cracking the coding interview, etc.) Code answers to those questions. I strongly recommend forcing yourself to pretend you're in an interview setting. Most of these questions should be solvable in ~10-15 minutes, some will be more like 20-25. Time yourself. Before you write a single line of code, organize your thoughts and figure out the entire solution, then start coding. The coding part should be boring and straightforward. In the actual interview, do the same thing. Before you write a single line of code, make sure that you validate with the interviewer that your approach is a good one. Practice practice practice this stuff.

Fill Gaps

This is where you get to be honest with yourself. That long list of things you don't know that you keep telling yourself is ok because the stuff you don't know isn't actually important....well, it is. Even if it isn't, your interviewer might think it is and it's better to have a job than be right. Here's a list off the top of my head that I hear people say isn't important (but you really should know).

Bits and Bytes

  • How all that bitshifting stuff works ?
  • What big and little endian are ?
  • Do a couple practice questions, even simple one.
  • Try something like..."write a method to determine if the bit-wise representation of an integer is a palindrome."

How the internet works

  • This applies more to companies....yeah....it applies to everything these days.
  • How sockets work ?
  • Qhat TCP/IP is ?
  • What HTTP actually is?
  • Networking layers and What's responsible for what.
  • You don't need to know all of the details of the protocols, but you should know some of them and that they exist.
  • This sounds daunting, it should only take a couple of hours.

Databases

  • Learn some basic SQL and data modeling if the job you're applying for uses databases.

Learn a bit about testing

  • Write some code and test it.
  • What's TDD ?

Whatever else you can think of

  • A good mental exercise is to imagine yourself in an interview..."man, I hope they don't ask me about X."
  • Figure out what X is and read about it.

Books and Sites

Daily Code

HackerRank Interview Kit

GLM Cracking the Codeing Interview