{"title":"LLD Temp","description":null,"content":"\nGiven an integer array `nums`, move all `0`'s to the end of it while maintaining the relative order of the non-zero elements.\n\n**Note** that you must do this in-place without making a copy of the array.\n\n---\n\n##### **Example 1:**\n\n\n\n\n\n##### **Example 2:**\n\n\n\n\n\n---\n\n##### **Constraints:**\n\n- **1 <= nums.length <= 10**^**4**\n- **-2**^**31**** <= nums[i] <= 2**^**31**** - 1**\n\n**Follow up:** Could you minimize the total number of operations done?\n\n```java\nclass Solution {\n public void moveZeroes(int[] nums) {\n \n }\n}\n```\n\n```python\nclass Solution:\n def moveZeroes(self, nums: List[int]) -> None:\n \"\"\"\n Do not return anything, modify nums in-place instead.\n \"\"\"\n```\n\n```cpp\nclass Solution {\npublic:\n void moveZeroes(vector& nums) {\n \n }\n};\n```\n\n```csharp\npublic class Solution {\n public void MoveZeroes(int[] nums) {\n \n }\n}\n```\n\n```javascript\n/**\n * @param {number[]} nums\n * @return {void} Do not return anything, modify nums in-place instead.\n */\nvar moveZeroes = function(nums) {\n \n};\n```\n\n```typescript\n/**\n Do not return anything, modify nums in-place instead.\n */\nfunction moveZeroes(nums: number[]): void {\n \n};\n```\n\n\n# Step 2: Identify Core Entities (3-5 minutes)\n\n\n[Video](https://stream.mux.com/KA00CMSnOJvTv9s200sxzpc02UJqx3u6SDW6uuymFTZj6I.m3u8)\n\nWith requirements locked down, shift from features to objects. What are the \"things\" in this system?\n\n### The Noun Extraction Technique\n\nA simple and effective technique is to go back to your requirements and underline every noun. These nouns are your candidate entities.\n\nFrom our Stack Overflow requirements:\n\n- **Users** ask questions and post answers\n- **Questions** have a title, body, and tags\n- **Answers** are posted in response to questions\n- **Comments** can be added to questions and answers\n- **Tags** categorize questions by topic\n- **Votes** track upvotes and downvotes\n\nThat gives us six core entities: **User, Question, Answer, Comment, Tag, and Vote**.\n\n\n```mermaid\nflowchart TB\n Client[Client]:::primary\n\n GW[API Gateway]:::orange\n\n US[User Service]:::green\n OS[Order Service]:::green\n PS[Payment Service]:::green\n IS[Inventory Service]:::green\n\n Client -->|All requests| GW\n GW -->|/api/users/**| US\n GW -->|/api/orders/**| OS\n GW -->|/api/payments/**| PS\n GW -->|/api/inventory/**| IS\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\n\n\n### Tips for Identifying Entities\n\n- **Start with 4-6 core entities: **You do not need to capture everything upfront. Start with the most obvious ones and add more as your design evolves. Over-engineering at this stage leads to unnecessarily complex class diagrams.\n- **Group related concepts.** Notice how both questions and answers can have comments and votes. This tells you there might be shared behavior you can extract later using interfaces or abstract classes.\n- **Ignore implementation details for now.** Do not worry about data types, method signatures, or database schemas at this point. You are building a mental model of the domain, not writing code.\n- **Think about relationships early.** As you list entities, start noting the connections between them. A User \"asks\" a Question. A Question \"has\" many Answers. An Answer \"receives\" Votes. These verbs hint at the relationships you will formalize in the next step. You do not need to be precise yet, just sketch the connections mentally.\n\nOne helpful trick is to write your entities first, then draw arrows between them showing how they relate. This gives the interviewer a visual anchor and gives you a roadmap for the class design ahead.\n\nYou now have a list of entities and a rough sketch of how they connect. Next: formalize these into a proper class structure.\n\n---\n\n# Step 3: Design Classes and Interfaces (20-25 minutes)\n\nThis step is the core of the interview. You will take the entities from Step 2 and turn them into a class structure with attributes, relationships, interfaces, and a clean API. This step carries the most weight in the session, so do not rush it.\n\nWe will break this into three parts: defining classes and relationships, extracting interfaces, and creating a central manager class.\n\n### 3.1 Define Classes, Attributes, and Relationships\n\nStart by converting each entity into a class with its key attributes.\n\nFor each class, ask yourself:\n\n- What data does this object hold?\n- What other objects does it reference?\n- What is the relationship type: one-to-one, one-to-many, or many-to-many?\n\nFor our Stack Overflow example:\n\n- A **User** has a name, email, and reputation score. A user can ask many questions and post many answers (one-to-many).\n- A **Question** has a title, body, creation date, and status. It belongs to one user, has many answers, many comments, many tags, and many votes.\n- An **Answer** has a body and creation date. It belongs to one user and one question, and has many comments and votes.\n- A **Comment** has a body. It belongs to one user.\n- A **Tag** has a name. Many questions can share the same tag (many-to-many).\n- A **Vote** has a vote type (upvote or downvote). It belongs to one user.\n\nWhen presenting this to the interviewer, it helps to briefly explain your relationship choices. For example: \"I am using composition here because a Question owns its Answers. If we delete a question, its answers should go with it. But Tags are shared across questions, so that is an association, not composition.\" This kind of reasoning shows you understand the difference between these relationship types.\n\n### 3.2 Define Interfaces and Core Methods\n\nNow look at your classes and find shared behavior. The verb extraction technique works well here: go through your requirements and pull out every action.\n\nUsers can **comment** on both questions and answers. Users can **vote** on both questions and answers. This shared behavior is a strong signal that you should extract interfaces.\n\n- **Commentable:** anything that can receive comments (questions and answers)\n- **Votable:** anything that can be voted on (questions and answers)\n\n#### Code Example\n\n\n```java\npublic interface Commentable {\n void addComment(Comment comment);\n List getComments();\n}\n\npublic interface Votable {\n void vote(User user, VoteType voteType);\n int getVoteCount();\n}\n\npublic enum VoteType {\n UPVOTE, DOWNVOTE\n}\n```\n\n```python\nfrom abc import ABC, abstractmethod\nfrom enum import Enum\n\nclass VoteType(Enum):\n UPVOTE = 1\n DOWNVOTE = -1\n\nclass Commentable(ABC):\n @abstractmethod\n def add_comment(self, comment: \"Comment\") -> None:\n pass\n\n @abstractmethod\n def get_comments(self) -> list[\"Comment\"]:\n pass\n\nclass Votable(ABC):\n @abstractmethod\n def vote(self, user: \"User\", vote_type: VoteType) -> None:\n pass\n\n @abstractmethod\n def get_vote_count(self) -> int:\n pass\n```\n\n```cpp\nenum class VoteType { UPVOTE, DOWNVOTE };\n\nclass Commentable {\npublic:\n virtual void addComment(Comment* comment) = 0;\n virtual std::vector getComments() const = 0;\n virtual ~Commentable() = default;\n};\n\nclass Votable {\npublic:\n virtual void vote(User* user, VoteType voteType) = 0;\n virtual int getVoteCount() const = 0;\n virtual ~Votable() = default;\n};\n```\n\n```csharp\npublic enum VoteType { Upvote, Downvote }\n\npublic interface ICommentable {\n void AddComment(Comment comment);\n List GetComments();\n}\n\npublic interface IVotable {\n void Vote(User user, VoteType voteType);\n int GetVoteCount();\n}\n```\n\n```typescript\nenum VoteType {\n UPVOTE = 1,\n DOWNVOTE = -1,\n}\n\ninterface Commentable {\n addComment(comment: Comment): void;\n getComments(): Comment[];\n}\n\ninterface Votable {\n vote(user: User, voteType: VoteType): void;\n getVoteCount(): number;\n}\n```\n\n\nWith these interfaces, `Question` and `Answer` both implement `Commentable` and `Votable`. No duplicated method signatures. If the interviewer later asks \"What if we want to add voting to comments too?\", you just have `Comment` implement `Votable` without touching existing code. That is the Open-Closed Principle at work.\n\nWhy interfaces instead of putting the methods directly on `Question` and `Answer`? Interfaces give you a contract. Any class that implements `Votable` is guaranteed to have `vote()`. This makes the system easier to extend and test. You do not need to explain all this unprompted, but being able to articulate it when asked matters.\n\n### 3.3 Define a Central Manager Class\n\nEvery LLD problem benefits from having a central class that acts as the entry point for the system. This is essentially the Facade pattern: one class that coordinates all the major operations and hides the internal complexity.\n\nFor Stack Overflow, this is the `StackOverflow` class. It is responsible for user registration, posting questions, posting answers, and searching. Think of it as the API layer that the outside world interacts with.\n\n\n```mermaid\nflowchart TD\n SO[StackOverflow Manager]:::primary\n\n SO --> UM[User Management]:::orange\n SO --> QM[Question Management]:::orange\n SO --> SM[Search & Filter]:::orange\n\n UM --> U[User]:::secondary\n QM --> Q[Question]:::secondary\n QM --> A[Answer]:::secondary\n Q --> C[Comment]:::secondary\n A --> C\n Q --> V[Vote]:::secondary\n A --> V\n Q --> T[Tag]:::purple\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef secondary fill:#38d9a9,stroke:#000,color:#000\n classDef purple fill:#9775fa,stroke:#000,color:#000\n```\n\n\nThe key methods on this manager class would include:\n\n- `createUser(name, email)` - register a new user\n- `askQuestion(user, title, body, tags)` - post a new question\n- `postAnswer(user, question, body)` - answer a question\n- `addComment(user, commentable, body)` - comment on a question or answer\n- `voteOnContent(user, votable, voteType)` - upvote or downvote\n- `searchQuestions(query)` - find questions by keyword or tag\n\nHere is a skeleton implementation of `askQuestion` to show how the classes collaborate. In an OOD interview, this level of detail is usually sufficient. You do not need fully compilable code.\n\n\n```java\npublic class StackOverflow {\n private final Map users = new HashMap<>();\n private final Map questions = new HashMap<>();\n\n public Question askQuestion(User user, String title, String body, List tagNames) {\n if (title == null || title.isBlank()) {\n throw new IllegalArgumentException(\"Question title cannot be empty\");\n }\n if (body == null || body.isBlank()) {\n throw new IllegalArgumentException(\"Question body cannot be empty\");\n }\n\n List tags = tagNames.stream()\n .map(Tag::new)\n .collect(Collectors.toList());\n\n Question question = new Question(user, title, body, tags);\n questions.put(question.getId(), question);\n user.addQuestion(question);\n\n return question;\n }\n}\n```\n\n```python\nclass StackOverflow:\n def __init__(self):\n self.users: dict[int, User] = {}\n self.questions: dict[int, Question] = {}\n\n def ask_question(self, user: User, title: str, body: str, tag_names: list[str]) -> Question:\n if not title or not title.strip():\n raise ValueError(\"Question title cannot be empty\")\n if not body or not body.strip():\n raise ValueError(\"Question body cannot be empty\")\n\n tags = [Tag(name) for name in tag_names]\n question = Question(user, title, body, tags)\n self.questions[question.id] = question\n user.add_question(question)\n\n return question\n```\n\n```cpp\nclass StackOverflow {\nprivate:\n unordered_map users;\n unordered_map questions;\n\npublic:\n Question* askQuestion(User* user, const string& title,\n const string& body, const vector& tagNames) {\n if (title.empty()) {\n throw invalid_argument(\"Question title cannot be empty\");\n }\n if (body.empty()) {\n throw invalid_argument(\"Question body cannot be empty\");\n }\n\n vector tags;\n for (const auto& name : tagNames) {\n tags.push_back(new Tag(name));\n }\n\n auto* question = new Question(user, title, body, tags);\n questions[question->getId()] = question;\n user->addQuestion(question);\n\n return question;\n }\n};\n```\n\n```csharp\npublic class StackOverflow {\n private readonly Dictionary users = new();\n private readonly Dictionary questions = new();\n\n public Question AskQuestion(User user, string title, string body, List tagNames) {\n if (string.IsNullOrWhiteSpace(title)) {\n throw new ArgumentException(\"Question title cannot be empty\");\n }\n if (string.IsNullOrWhiteSpace(body)) {\n throw new ArgumentException(\"Question body cannot be empty\");\n }\n\n var tags = tagNames.Select(name => new Tag(name)).ToList();\n var question = new Question(user, title, body, tags);\n questions[question.Id] = question;\n user.AddQuestion(question);\n\n return question;\n }\n}\n```\n\n```typescript\nclass StackOverflow {\n private users: Map = new Map();\n private questions: Map = new Map();\n\n askQuestion(user: User, title: string, body: string, tagNames: string[]): Question {\n if (!title || !title.trim()) {\n throw new Error(\"Question title cannot be empty\");\n }\n if (!body || !body.trim()) {\n throw new Error(\"Question body cannot be empty\");\n }\n\n const tags = tagNames.map(name => new Tag(name));\n const question = new Question(user, title, body, tags);\n this.questions.set(question.id, question);\n user.addQuestion(question);\n\n return question;\n }\n}\n```\n\n\nYour class structure is now on paper with clear relationships, shared interfaces, and a clean API surface. The next step is identifying where design patterns fit into this structure, if they fit at all.\n\n---\n\n# Step 4: Apply Design Patterns (5-7 minutes)\n\nDo not force patterns into your design to impress. Apply them where they solve a real problem. One or two well-placed patterns with clear reasoning beats listing five you do not actually use.\n\nFor our Stack Overflow design, three patterns are worth mentioning.\n\n### Strategy Pattern: Reputation Calculation\n\nStack Overflow's reputation rules are non-trivial: +10 for an answer upvote, +5 for a question upvote, -2 for a downvote, and so on. These rules could change. You might want a simplified scheme for a new community, or boosted rewards during a promotional event.\n\nBy extracting reputation calculation into a strategy interface, you can swap implementations without modifying the core classes.\n\n\n```java\npublic interface ReputationStrategy {\n int calculateReputationChange(VoteType voteType, boolean isQuestion);\n}\n\npublic class StandardReputationStrategy implements ReputationStrategy {\n @Override\n public int calculateReputationChange(VoteType voteType, boolean isQuestion) {\n if (voteType == VoteType.UPVOTE) {\n return isQuestion ? 5 : 10;\n }\n return -2; // downvote penalty\n }\n}\n\npublic class SimplifiedReputationStrategy implements ReputationStrategy {\n @Override\n public int calculateReputationChange(VoteType voteType, boolean isQuestion) {\n return voteType == VoteType.UPVOTE ? 1 : -1;\n }\n}\n```\n\n```python\nfrom abc import ABC, abstractmethod\n\nclass ReputationStrategy(ABC):\n @abstractmethod\n def calculate_reputation_change(self, vote_type: VoteType, is_question: bool) -> int:\n pass\n\nclass StandardReputationStrategy(ReputationStrategy):\n def calculate_reputation_change(self, vote_type: VoteType, is_question: bool) -> int:\n if vote_type == VoteType.UPVOTE:\n return 5 if is_question else 10\n return -2 # downvote penalty\n\nclass SimplifiedReputationStrategy(ReputationStrategy):\n def calculate_reputation_change(self, vote_type: VoteType, is_question: bool) -> int:\n return 1 if vote_type == VoteType.UPVOTE else -1\n```\n\n```cpp\nclass ReputationStrategy {\npublic:\n virtual int calculateReputationChange(VoteType voteType, bool isQuestion) = 0;\n virtual ~ReputationStrategy() = default;\n};\n\nclass StandardReputationStrategy : public ReputationStrategy {\npublic:\n int calculateReputationChange(VoteType voteType, bool isQuestion) override {\n if (voteType == VoteType::UPVOTE) {\n return isQuestion ? 5 : 10;\n }\n return -2; // downvote penalty\n }\n};\n\nclass SimplifiedReputationStrategy : public ReputationStrategy {\npublic:\n int calculateReputationChange(VoteType voteType, bool isQuestion) override {\n return voteType == VoteType::UPVOTE ? 1 : -1;\n }\n};\n```\n\n```csharp\npublic interface IReputationStrategy {\n int CalculateReputationChange(VoteType voteType, bool isQuestion);\n}\n\npublic class StandardReputationStrategy : IReputationStrategy {\n public int CalculateReputationChange(VoteType voteType, bool isQuestion) {\n if (voteType == VoteType.Upvote) {\n return isQuestion ? 5 : 10;\n }\n return -2; // downvote penalty\n }\n}\n\npublic class SimplifiedReputationStrategy : IReputationStrategy {\n public int CalculateReputationChange(VoteType voteType, bool isQuestion) {\n return voteType == VoteType.Upvote ? 1 : -1;\n }\n}\n```\n\n```typescript\ninterface ReputationStrategy {\n calculateReputationChange(voteType: VoteType, isQuestion: boolean): number;\n}\n\nclass StandardReputationStrategy implements ReputationStrategy {\n calculateReputationChange(voteType: VoteType, isQuestion: boolean): number {\n if (voteType === VoteType.UPVOTE) {\n return isQuestion ? 5 : 10;\n }\n return -2; // downvote penalty\n }\n}\n\nclass SimplifiedReputationStrategy implements ReputationStrategy {\n calculateReputationChange(voteType: VoteType, isQuestion: boolean): number {\n return voteType === VoteType.UPVOTE ? 1 : -1;\n }\n}\n```\n\n\nWhen explaining this, keep it simple: \"Reputation rules will probably change. With a strategy interface, I can add new rules without modifying `User` or `StackOverflow`.\"\n\n### Observer Pattern: Notifications\n\nWhen someone answers a question or comments on an answer, the question author might want to be notified. Rather than having the `StackOverflow` manager class directly call notification logic (which would violate single responsibility), you can use the Observer pattern.\n\n\n```java\npublic interface NotificationObserver {\n void notify(String message);\n}\n\npublic class EmailNotifier implements NotificationObserver {\n @Override\n public void notify(String message) {\n // send email notification\n }\n}\n\npublic class InAppNotifier implements NotificationObserver {\n @Override\n public void notify(String message) {\n // push in-app notification\n }\n}\n```\n\n```python\nfrom abc import ABC, abstractmethod\n\nclass NotificationObserver(ABC):\n @abstractmethod\n def notify(self, message: str) -> None:\n pass\n\nclass EmailNotifier(NotificationObserver):\n def notify(self, message: str) -> None:\n # send email notification\n pass\n\nclass InAppNotifier(NotificationObserver):\n def notify(self, message: str) -> None:\n # push in-app notification\n pass\n```\n\n```cpp\nclass NotificationObserver {\npublic:\n virtual void notify(const std::string& message) = 0;\n virtual ~NotificationObserver() = default;\n};\n\nclass EmailNotifier : public NotificationObserver {\npublic:\n void notify(const std::string& message) override {\n // send email notification\n }\n};\n\nclass InAppNotifier : public NotificationObserver {\npublic:\n void notify(const std::string& message) override {\n // push in-app notification\n }\n};\n```\n\n```csharp\npublic interface INotificationObserver {\n void Notify(string message);\n}\n\npublic class EmailNotifier : INotificationObserver {\n public void Notify(string message) {\n // send email notification\n }\n}\n\npublic class InAppNotifier : INotificationObserver {\n public void Notify(string message) {\n // push in-app notification\n }\n}\n```\n\n```typescript\ninterface NotificationObserver {\n notify(message: string): void;\n}\n\nclass EmailNotifier implements NotificationObserver {\n notify(message: string): void {\n // send email notification\n }\n}\n\nclass InAppNotifier implements NotificationObserver {\n notify(message: string): void {\n // push in-app notification\n }\n}\n```\n\n\nYou do not need to implement a full notification system. Simply mentioning \"I would use the Observer pattern here so that the Question class can notify subscribers when a new answer is posted\" is enough to demonstrate the concept.\n\n### How to Discuss Patterns With the Interviewer\n\nWhen applying patterns in an OOD interview, always cover three things:\n\n1. **What pattern** you are using and where it applies\n2. **Why** you chose it, meaning what problem it solves\n3. **How** it helps with extensibility or maintainability\n\nA common pattern table for LLD interviews:\n\n\n| Pattern | When to Use | Stack Overflow Example |\n|---------|-------------|----------------------|\n| **Strategy** | Behavior varies at runtime | Reputation calculation, search ranking |\n| **Observer** | Objects need to react to changes | Notifications on new answers |\n| **Factory** | Object creation logic may grow complex | Creating different question types |\n| **Facade** | Simplify a complex subsystem | The `StackOverflow` manager class |\n| **Singleton** | Only one instance should exist | The `StackOverflow` system instance |\n| **State** | Object behavior changes based on state | Question status (open, closed, duplicate) |\n\n\nDo not try to use all of these. Pick 1-2 that genuinely improve your design and explain them clearly. Clear reasoning beats pattern name-dropping.\n\n---\n\n# Step 5: Walk Through Use Cases and Edge Cases (5-10 minutes)\n\nMany candidates skip this step because they run out of time. That costs them. Walking through a use case end-to-end proves that your classes actually collaborate correctly, not just that they look good on a diagram.\n\n### Use Case 1: User Asks a Question\n\nWalk the interviewer through the flow verbally while pointing to your class diagram:\n\n1. The user calls `StackOverflow.askQuestion(user, \"How to reverse a linked list?\", body, [\"java\", \"data-structures\"])`\n2. The manager validates the input (non-empty title and body)\n3. It creates `Tag` objects for each tag name\n4. It creates a new `Question` object, passing the user, title, body, and tags\n5. The question is stored in the questions map and added to the user's question list\n6. The question is returned with a unique ID\n\n### Use Case 2: User Votes on an Answer\n\nThis flow is more interesting because it touches multiple classes:\n\n1. The user calls `StackOverflow.voteOnContent(voter, answer, VoteType.UPVOTE)`\n2. The manager delegates to `answer.vote(voter, VoteType.UPVOTE)`\n3. The vote method checks: is the voter the same as the answer's author? If yes, throw an exception (self-voting is not allowed)\n4. It checks: has this voter already voted on this answer? If yes, throw an exception (duplicate voting)\n5. A new `Vote` object is created and stored\n6. The answer's vote count is updated\n7. The reputation strategy calculates the reputation change (+10 for answer upvote)\n8. The answer author's reputation is updated\n9. If observers are registered, the answer author is notified of the upvote\n\nThe self-voting validation in code:\n\n\n```java\npublic void vote(User voter, VoteType voteType) {\n if (voter.getId() == this.author.getId()) {\n throw new IllegalArgumentException(\"Users cannot vote on their own content\");\n }\n if (votes.containsKey(voter.getId())) {\n throw new IllegalArgumentException(\"User has already voted on this content\");\n }\n\n votes.put(voter.getId(), new Vote(voter, voteType));\n updateScore();\n}\n```\n\n```python\ndef vote(self, voter: User, vote_type: VoteType) -> None:\n if voter.id == self.author.id:\n raise ValueError(\"Users cannot vote on their own content\")\n if voter.id in self.votes:\n raise ValueError(\"User has already voted on this content\")\n\n self.votes[voter.id] = Vote(voter, vote_type)\n self._update_score()\n```\n\n```cpp\nvoid vote(User* voter, VoteType voteType) override {\n if (voter->getId() == author->getId()) {\n throw std::invalid_argument(\"Users cannot vote on their own content\");\n }\n if (votes.count(voter->getId())) {\n throw std::invalid_argument(\"User has already voted on this content\");\n }\n\n votes[voter->getId()] = new Vote(voter, voteType);\n updateScore();\n}\n```\n\n```csharp\npublic void Vote(User voter, VoteType voteType) {\n if (voter.Id == Author.Id) {\n throw new InvalidOperationException(\"Users cannot vote on their own content\");\n }\n if (votes.ContainsKey(voter.Id)) {\n throw new InvalidOperationException(\"User has already voted on this content\");\n }\n\n votes[voter.Id] = new Vote(voter, voteType);\n UpdateScore();\n}\n```\n\n```typescript\nvote(voter: User, voteType: VoteType): void {\n if (voter.id === this.author.id) {\n throw new Error(\"Users cannot vote on their own content\");\n }\n if (this.votes.has(voter.id)) {\n throw new Error(\"User has already voted on this content\");\n }\n\n this.votes.set(voter.id, new Vote(voter, voteType));\n this.updateScore();\n}\n```\n\n\n### Key Edge Cases to Discuss\n\nYou do not need to handle every possible edge case in code. What matters is that you **think** about edge cases. Mention 3-4 key ones and show validation code for 1-2:\n\n- **Self-voting:** A user should not be able to upvote their own question or answer. This is a natural validation to include.\n- **Duplicate voting:** What happens if a user tries to upvote the same answer twice? You need to track who has already voted and either reject the duplicate or toggle the vote.\n- **Empty content:** Questions with blank titles, answers with no body, comments with just whitespace. These should all be rejected with clear error messages.\n- **Negative reputation:** If a user gets enough downvotes, can their reputation go below zero? Decide on a floor (Stack Overflow uses 0 as the minimum).\n- **Answering a closed question:** If a question has been marked as closed, new answers should be rejected.\n\n---\n\n# UML Knowledge: How Much Do You Need?\n\nYou don't need to be a UML expert. Here's what matters and what doesn't.\n\n#### **Must know: Class diagrams**\n\nThis is the core deliverable of an OOD interview. You should be comfortable drawing classes with attributes and methods, showing relationships (association, composition, aggregation, dependency), indicating multiplicity (1, many, 0..1), and marking interfaces and abstract classes. You don't need perfect UML arrow syntax, but you should know the difference between \"has a\" (composition/aggregation) and \"uses a\" (dependency).\n\n#### **Nice to have: Sequence diagrams**\n\nThese are useful for walking through workflows (Step 4 of the framework). A sequence diagram shows which object calls which method in what order. If you can sketch one quickly, it adds clarity to your workflow discussion. If you're not comfortable with sequence diagrams, a verbal walkthrough while pointing at your class diagram works fine.\n\n#### **Don't need: Activity diagrams, state diagrams, use case diagrams**\n\nThese have their place in software engineering, but they rarely come up in interviews. If the problem involves complex state transitions (like an order lifecycle), you can mention states verbally or draw a simple state table. You don't need formal UML state diagram notation.\n\nThis course covers UML fundamentals in the dedicated UML chapters. For OOD interview prep, focus your UML practice on class diagrams. Being able to draw a clean, readable class diagram with 8-12 classes in 10-15 minutes is the skill that matters.","pageType":"lld-interviews"}

LLD Temp

Ashish Pratap Singh

Get Premium