Tech Interviews: This might be your next question

simplymanas

Manas Ranjan Dash

Posted on December 31, 2018

Tech Interviews: This might be your next question

Badge

A list of articles, videos, books for interview preparation....

This might be your next question…github

System Design

Log System

High Scalability blog

Systme desgin primer by donne martin

System Desgin by Shashank

Redis architecture

System Desgin Interview Question cont..

Online Movie Ticket booking

Recommedation and personalisation

Netflix Developer

System desgin case studies

System desgin for collab edit

How web works

Bloom Filter

How does HTTPS actually work?

Architecutre

Cassandra

Whatsapp Architecture

Scaling

Whatsapp

Whatsapp Scaling

Microservices

At amazon

Distributed Systems

Distributed Systems in One Lesson by Tim Berglund

CAP Theorem CAP by Shekhar Gulati

  • Consistency: Every read is guaranteed to return the most recent write or an error
  • Availability: Every request receives a non-error response from a non-failing node in a reasonable time. It is expected that the client may not receive the most recent write
  • Partition tolerance: The system continues to operate when network partition happens

Deployment

Kubrnetes

Coding

Interview Question - geekForgeek

Interview Question - DonneMartin

Interview Question - simple programmer

Interview Question - hackernoon

Interview Question - LeetCode

Data Structures and Algorithms in Java

JAVA Interview questions - interviewbit

Add Two Numbers

this is a problem

Explanation of the solution

Ultimate Guide

Datastructure

All about tree

How To Not Be Stumped By Trees

Vaidehi Joshi’s world of Datastructure

When to use linkedlist over arraylist in java

DDD (Domain Driven Design)

How to define service industries

Capability-mapping-and-context-mapping

DDD the 5 mintue master

Caching

Caching Tutorial for Web Authors and Webmasters

Security

https://www.youtube.com/watch?v=otWst36CKyM

Login system

Definitive guide for website authentication

Courses

Safari Books - Learn design pattern

Safari Books - Break away system

Safari books - Java Inteview Guide

JAVA

10 JAVA interview question Java Interview question

REST

RESTful APIs

Microsoft Dcouments on API-Design best practice

Networking

100 networking question

Design Pattern

Design Pattern - DZONE

Design Pattern - JavaTPoint

Database

Understanding nosql

Process & Standard

Clean Code

Success Stories

System Desgin

Almost Everything

Everything

Web Architecture 101

Web Architecture 101

Online Videos

5 Tips for System Design Interviews

System Design: How to design Twitter? Interview question at Facebook, Google, Microsoft

Tech Dummies - Narendra L

All about algorithms

Tech Primers

Interview Formats

For many comapnies

Some FAQ

(will continue adding to this in my git page)

FAQ#1 : Difference between JWT (Java Web Tokens) & Oauth

jwt-vs-oauth

Deep Copy vs Swallow Copy

RFC7519

JWT OAuth
its a token, JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties its a framework to dispense token
JWT is a different kind of OAuth token OAuth token is not the only token
is not a pointer to information a pointer to information
JWT contains real information, it can be large can be small as its just a pointer
JWT are self-validating" what they mean is, any holder of the JWT can open it, validate it, and then make authorization decisions based on the claims presented in it. Oauth are not
JWT supports "Federation" - anyone can generate a token, and anyone can read and validate a token . used when there is no federation
used when asynchrony is required
security. Both are bearer tokens. Both need to be protected as secrets. same
useful for self authenticating tokens
has lot more context about the user, session - including the signature. less context
better at performance as no server call requried server clal required
forced to have lower expiry times to these tokens, as they are valid till the pre-defined rules re valid

FAQ#2 : Difference between Container and VM

differences

Container VM
Shares the OS and resources A full virtualized system gets its own set of resources allocated to it, and does minimal sharing.
If you just want to isolate processes from each other and want to run a ton of them on a reasonably sized host, then Docker/LXC/runC seems to be the way to go. If you want full isolation with guaranteed resources, a full VM is the way to go
How containers works at low level? Each container runs in its own namespace but uses exactly the same kernel as all other containers. The isolation happens because kernel knows the namespace that was assigned to the process and during API calls it makes sure that process can only access resources in its own namespace. How virtualization works at low level? The net effect is that virtualization allows you to run two completely different OS on same hardware. Each guest OS goes through all the process of bootstrapping, loading kernel etc. You can have very tight security, for example, guest OS can't get full access to host OS or other guests and mess things up.
A virtual machine is a convenient way of packaging up virtual hardware, a kernel, and a user space. A container, on the other hand, packages up only the user space; there is no kernel or virtual hardware.
Sharing an entire virtual machine with other developers can be inconvenient because of a virtual machine’s size and format Containers have the advantage of providing developers, architects, quality engineering, release engineers, and systems administrators with a currency for collaboration that has the entire user space packaged and shipped in a convenient and easy to use format.

FAQ#3 : CAP Therorem

https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed

FAQ#4 : Difference between Redis and Memcache

https://stackoverflow.com/questions/10558465/memcached-vs-redis

FAQ#5 : Why Databases shouldn't be used as Message Queues

https://www.youtube.com/watch?v=9T-gNZ5bGCw

Here are possible drawbacks:

1) Polling intervals have to be set correctly. Too long makes the system is inefficient. Too short makes the database undergo heavy read load.
2) Read and write operation heavy DB. Usually, they are good at one of the two.
3) Manual delete procedures to be written to remove read messages.
4) Scaling is difficult conceptually and physically.

Same thoughts from github

interview by rockoder

Conclusion

These are just pointers where you can get some more details about a particular topic, but almost all of them required working knowledge for a deep dive and more thoughts on using the same.

All the best for your next round :)
Simplymanas

AboutMe | Blog | Github
💖 💪 🙅 🚩
simplymanas
Manas Ranjan Dash

Posted on December 31, 2018

Join Our Newsletter. No Spam, Only the good stuff.

Sign up to receive the latest update from our blog.

Related