Tech Industry
Yesterday
677
[India] What's your NW, age and Total YOE
Tech Industry
2d
38563
I'm rejecting any interview that is LC
India
Yesterday
968
Why do Indian-Americans(Indians who were born in the Us) rarely marry Indians who came to the US for education/ work?
Tech Industry
Yesterday
22816
Elon Musk had sex with SpaceX intern
Personal Finance
5h
1183
NVIDIA Fall?
What do you think? ================== prompt: answer a facebook's leveling interview question like how an L6 software engineer would in detail, then answer it as how L3 engineer would? As an L6 software engineer at Facebook, I would approach an interview question like "Design a system that can handle a high number of concurrent users and efficiently retrieve their information from a large data set" by taking the following steps: Understand the problem and constraints: In this case, the problem is to handle a high number of concurrent users and efficiently retrieve their information from a large data set. The constraints could be time and space complexity, the need for scalability and reliability, etc. Devise a high-level solution: One possible high-level solution could be to use a distributed system with a load balancer to distribute the incoming requests among multiple servers. A data store such as a NoSQL database, like Cassandra or HBase, can be used to store the user information. An in-memory cache, like Memcached or Redis, can be used to store frequently accessed data for quick retrieval. Consider the trade-offs: One trade-off of this solution could be the cost and complexity of maintaining a distributed system. Another trade-off could be the need for additional caching and indexing to improve retrieval times, which would increase the memory usage. Optimize the solution: To optimize the solution, we can use techniques such as sharding and partitioning the data, and using secondary indexes to improve retrieval times. Additionally, we can use techniques such as load shedding, and backpressure to handle the high traffic and mitigate the risk of a single point of failure. Communicate the solution: Clearly communicate the solution, the design choices, and trade-offs to the interviewer, and be prepared to discuss and answer questions about it. As an L3 software engineer, I would approach the same question by understanding the problem and the constraints, then I would propose a solution that is less complex and optimized for the specific use case. For example, I would suggest a monolithic architecture with a relational database, like MySQL or PostgreSQL, to store the user information. I would also suggest an in-memory cache like Redis to improve the retrieval times. Additionally, I would consider the scalability and reliability of the solution and suggest ways to improve them. I would also communicate the solution clearly and be prepared to answer questions about the design choices and trade-offs. ============ bonus ============ A staff software engineer should be well-versed in the following system design terms and concepts before going to an interview at a top company known for their highly selective interview process: Scalability: The ability of a system to handle an increasing amount of work or load by adding more resources. Availability: The ability of a system to be accessible and perform its intended function at all times. Performance: The measure of how well a system performs its intended function, often measured by metrics such as response time and throughput. Reliability: The ability of a system to continue operating without interruption or failure. Latency: The time it takes for a request to be processed and a response to be returned. Throughput: The number of requests that a system can handle per unit of time. Load balancing: The process of distributing incoming requests among multiple servers to improve scalability and reliability. Caching: The process of temporarily storing frequently accessed data in a fast storage medium, such as memory, to improve retrieval times. Distributed systems: A system that is composed of multiple interconnected components that work together to achieve a common goal. Consistency: The ability of a distributed system to ensure that all components have the same data at the same time. Partitioning: The process of splitting a large data set into smaller, more manageable chunks called partitions. Sharding: The process of distributing partitions among multiple servers to improve scalability. Indexing: The process of creating a data structure that allows for faster data retrieval. Data replication: The process of copying data from one server to another to improve reliability and availability. Fault tolerance: The ability of a system to continue operating despite the failure of one or more of its components. Cloud computing: The delivery of computing services, including servers, storage, and databases, over the internet. Microservices: A software architecture that structures an application as a collection of loosely coupled services. API: An interface for interacting with a software system. Containerization: A way to package and distribute software applications, making them more portable and scalable. Kubernetes and Docker: Open-source technologies for container orchestration, management, and scaling. Event-driven architecture: A design pattern that allows for the processing of large numbers of events in real-time. Asynchronous communication: A method of communication in which messages are sent and received without the need for a continuous connection between the sender and receiver. Queues: A data structure that allows for the storage and processing of messages in a first-in-first-out (FIFO) order. Data modeling: The process of creating a conceptual representation of a data set and the relationships between different data elements. Data warehousing: The process of collecting, storing, and managing large amounts of data in a central location. Data lakes: A centralized repository that allows data to be stored in its raw format and be queried by multiple users. NoSQL databases: A type of database that does not use a fixed schema and is designed for high scalability and performance. ACID properties: A set of properties that ensure the consistency, availability, isolation, and durability of a database. CAP theorem: A principle that states that it is impossible for a distributed system to simultaneously provide consistency, availability, and partition tolerance. MapReduce: A programming model for processing and generating large data sets with parallel, distributed algorithms. Big Data: Extremely large data sets that may be analyzed computationally to reveal patterns, trends, and insights. Machine learning: A method of teaching computers to learn from data without being explicitly programmed. Artificial intelligence: The simulation of human intelligence processes by computers. Neural networks: A type of machine learning model that is inspired by the structure and function of the human brain. API Gateway: A service that acts as an entry point for external clients to access a microservices-based architecture. Service discovery: A technique that allows services to automatically discover and communicate with each other. Circuit breaker: A pattern used to prevent a cascading failure in a distributed system by isolating failing service instances. Serverless computing: A cloud computing execution model in which the cloud provider is responsible for allocating and managing the server resources. Cloud-Native: A set of technologies and practices that enable applications to be developed and deployed in cloud environments. Security: The set of measures to protect systems and data from unauthorized access, use, disclosure, disruption, modification, or destruction. Security protocols: A set of standard procedures for ensuring the security of communication and data. Examples include SSL/TLS, SSH, and IPSec. Authentication: The process of verifying the identity of a user or system. Authorization: The process of determining whether a user or system is allowed to access a particular resource. Encryption: The process of converting plaintext into an unreadable format to protect data from unauthorized access. Digital Signatures: A process that guarantees that the contents of a message have not been altered during transmission and verifies the identity of the sender. Penetration testing: A method of evaluating the security of a computer system or network by simulating an attack from a malicious source. Firewalls: A network security system that monitors and controls incoming and outgoing network traffic based on a set of security rules. Intrusion detection systems: A system that monitors network traffic for signs of malicious activity or policy violations. Backup and disaster recovery: A set of procedures and technologies used to protect against data loss and ensure business continuity in the event of a disaster. Cloud security: The set of technologies and practices used to secure data and applications in cloud environments. Compliance: The process of ensuring that an organization adheres to legal and regulatory requirements. Logging and monitoring: The process of collecting and analyzing log data from applications and systems to identify and troubleshoot issues and to gain insight into system behavior.
That L6 answer was actually L5. L6s distinguish themselves once you add more unusual complexity into the system. I am speaking very generic here ofcourse
give me an example of complexity
1) How is data stored? Can we minimize it for cost considerations? 2) I am forced to rely on mysql. How would you tackle it? 3) What are potential hotspotting issues? 4) How would you regionalize the setup? Is it even warranted? 5) Why microservices, if proposed? Why not monolithic architecture? Vice versa. 6) How would you roll out the system? The above question is super plain. Lots of interesting use cases will come up when solving for a particular problem.
Seasoned engineers aim for simplicity rather than complexity. Your L6 approach lacks lots of basic questions, I know lots of extremely smart folks L7+ who would've offered a monolithic approach and a simple architecture that your so called L3 would offer. Another yellow flag here is to jump to specific infrastructure components implementation at the beginning which shows lack of real world design experience. Nothing personal towards op though.
yea i agree, given no parameters, it was odd to just go to microservices
Jumping to specific infra components is more a function of interview setup than an indicator of real-world design experience. Candidates are nervous, and there are only 30 mins overall to prove their mettle and cover all major pieces. You may disincentivize this behavior by using starting with a simple problem and provide initial constraints yourself rather than saying 'design twitter'.
L6 sounds like BS.
which part? there are only so many ways you can make a system scalable.. in the end database is the bottleneck, each time you optimize it for one thing you end up hurting the other.. sharding, partitioning, N+ read dbs, caching, running averages, multiple nodes then syncing, 30 tricks with app logic... but then there is nothing to do after that. You'd have to build special hardware optimized for that use case scenario. Even then you'd hit a limit. After one point even money stops being a bottleneck and current tech and physics becomes the bottle neck.