Software Development
Prepared for NL Glean Interview
— Final-Year Software Engineering Guide
Student, HUIB Cameroon
This guide covers everything typically asked in a general software developer interview: data structures &
algorithms, OOP & design principles, databases, web/backend development, system design fundamentals,
version control & testing, common questions with model answers, and a final revision cheat sheet.
1. Data Structures & Algorithms
Core Data Structures
• Arrays & Strings: fixed-size contiguous memory, O(1) index access, O(n) insert/delete in the middle.
• Linked Lists: singly/doubly linked, O(1) insert/delete at a known node, O(n) search — good for frequent
inserts.
• Stacks & Queues: LIFO / FIFO — used in undo systems, BFS, parsing/balancing brackets.
• Hash Maps / Sets: O(1) average lookup, insert, delete; know collision handling (chaining vs open
addressing).
• Trees: binary trees, binary search trees (BST), balanced trees (AVL, Red-Black — conceptually), tries.
• Heaps / Priority Queues: O(log n) insert/extract-min or max; used for scheduling, top-k problems, Dijkstra's
algorithm.
• Graphs: adjacency list vs matrix; directed/undirected, weighted/unweighted.
Core Algorithms
• Sorting: quicksort & mergesort (O(n log n) average), when each is preferred (mergesort is stable, quicksort
usually faster in practice); insertion sort for small/near-sorted data.
• Searching: binary search (O(log n)) — always check the array is sorted first.
• Graph traversal: BFS (shortest path, unweighted, queue-based) and DFS (connectivity, cycle detection,
stack/recursion-based).
• Shortest path: Dijkstra's algorithm (non-negative weights), Bellman-Ford (handles negative weights).
• Dynamic Programming: identify overlapping subproblems + optimal substructure; classic examples —
Fibonacci, knapsack, longest common subsequence, coin change, edit distance.
• Greedy algorithms: make the locally optimal choice at each step (e.g. activity selection, Huffman coding) —
know when greedy fails vs. DP is required.
• Two-pointer & sliding window: common for array/string subarray problems in O(n).
• Recursion & backtracking: permutations, combinations, N-Queens, Sudoku-style search problems.
Complexity Analysis
• Always state time AND space complexity after solving a problem — interviewers expect this unprompted.
• Know the common complexity classes: O(1), O(log n), O(n), O(n log n), O(n²), O(2^n) — and where each
typically shows up.
• Be able to explain amortized complexity (e.g. dynamic array resizing gives amortized O(1) append).
2. Object-Oriented Programming & Design Principles
OOP Pillars
• Encapsulation: bundling data and methods, restricting direct access to internal state.
• Abstraction: exposing only what's necessary, hiding implementation detail behind an interface.
• Inheritance: sharing behavior across a class hierarchy — know the tradeoff of tight coupling vs. reuse.
• Polymorphism: same interface, different underlying implementation (method overriding/overloading).
Design Principles & Patterns
• SOLID principles: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation,
Dependency Inversion.
• DRY (Don't Repeat Yourself) and KISS (Keep It Simple).
• Common design patterns: Singleton, Factory, Observer, Strategy, Decorator — know one real scenario for
each, don't just memorize definitions.
• Composition over inheritance — a frequently asked "why" question.
3. Databases
• SQL fundamentals: SELECT/JOIN types (inner, left, right, full), GROUP BY, indexes, primary/foreign keys.
• Normalization: 1NF/2NF/3NF — reducing redundancy; know when denormalization is a valid tradeoff for
read performance.
• Indexes: speed up reads (O(log n) lookup via B-tree) but slow down writes and use extra storage.
• Transactions & ACID: Atomicity, Consistency, Isolation, Durability.
• SQL vs NoSQL: relational (structured, joins, strong consistency) vs document/key-value/wide-column
stores (flexible schema, horizontal scaling) — know when to pick each.
• N+1 query problem and how to avoid it (eager loading / joins).
4. Web & Backend Development
HTTP & APIs
• HTTP methods: GET, POST, PUT, PATCH, DELETE — and idempotency (GET/PUT/DELETE are
idempotent, POST is not).
• Status codes: 2xx success, 3xx redirect, 4xx client error, 5xx server error — know
200/201/301/400/401/403/404/500.
• REST principles: statelessness, resource-based URLs, standard verbs.
• Authentication vs Authorization: who you are vs what you're allowed to do; know API keys, JWT, OAuth
basics.
Backend Concepts
• MVC pattern: Model (data), View (presentation), Controller (request handling/business logic).
• Caching: in-memory (e.g. Redis) to reduce database load; cache invalidation is famously one of the
hardest problems in CS.
• Load balancing & horizontal vs vertical scaling.
• Rate limiting and why APIs need it.
• Synchronous vs asynchronous processing; message queues for decoupling services.
5. System Design Fundamentals
• Clarify requirements first: functional (what it does) and non-functional (scale, latency, availability) before
designing anything.
• Estimate scale: rough numbers for users, requests/sec, storage — shows you think about real constraints.
• High-level components: client → load balancer → application servers → cache → database → (optionally)
message queue/background workers.
• CAP theorem: a distributed system can only guarantee two of Consistency, Availability, Partition tolerance
at once.
• Database scaling: read replicas, sharding, indexing.
• Common practice prompts: design a URL shortener, design a rate limiter, design a notification system,
design a simple chat app — practice explaining tradeoffs out loud, not just drawing boxes.
6. Version Control, Testing & Practices
• Git basics: branch, merge, rebase, resolving merge conflicts, pull requests/code review workflow.
• Git branching strategies: feature branches, trunk-based development — know pros/cons.
• Testing pyramid: unit tests (fast, isolated) > integration tests > end-to-end tests (fewer, slower, broader
coverage).
• Test-Driven Development (TDD): write a failing test, write minimal code to pass it, refactor.
• CI/CD basics: automated build/test/deploy pipeline, why it reduces integration risk.
• Code review etiquette: what good reviewers look for (correctness, readability, edge cases) — you may be
asked to review a snippet live.
7. Common Interview Questions & Model Answers
What's the difference between a stack and a queue?
A stack is LIFO (last-in, first-out) — used for undo operations and function call stacks. A queue is FIFO (first-in,
first-out) — used for task scheduling and BFS traversal.
Explain time complexity vs space complexity.
Time complexity measures how the runtime grows as input size grows; space complexity measures how much
extra memory an algorithm needs beyond the input. An algorithm can trade one for the other — e.g. memoization
uses extra space to reduce time.
What happens when you type a URL into a browser and hit enter?
DNS resolves the domain to an IP address, the browser opens a TCP connection (TLS handshake if HTTPS),
sends an HTTP request, the server processes it and returns a response, and the browser parses the
HTML/CSS/JS to render the page.
What is a race condition, and how do you prevent one?
A race condition occurs when multiple threads/processes access shared data concurrently and the outcome
depends on timing. Prevent it with locks/mutexes, atomic operations, or by avoiding shared mutable state
altogether (e.g. message passing).
How would you optimize a slow SQL query?
Check the query plan (EXPLAIN), add appropriate indexes on filtered/joined columns, avoid SELECT *, reduce
N+1 queries, and consider denormalization or caching if reads dominate.
What's the difference between processes and threads?
A process has its own isolated memory space; a thread shares memory with other threads in the same process.
Threads are lighter-weight but require careful synchronization to avoid race conditions.
How do you approach debugging a production issue you can't reproduce locally?
Check logs and monitoring/metrics first, try to narrow down the conditions (input, load, timing), add more granular
logging if needed, and reproduce with a similar dataset/environment before attempting a fix.
Behavioral
• Tell me about yourself — lead with your degree, your practical project experience, and what kind of
engineer you're becoming.
• Describe a challenging bug you fixed — pick one specific, technical story with a clear before/after.
• Tell me about a time you disagreed with a teammate — focus on how it was resolved constructively.
• Why do you want to work here? — research the company's product/stack beforehand and connect it to
your interests.
• How do you stay up to date with technology? — mention specific habits (docs, communities, personal
projects).
8. Quick Revision Cheat Sheet
Complexity Quick Reference
Structure/Operation Average Time Notes
Array index access O(1) Contiguous memory
Array insert/delete (middle) O(n) Shifting required
Hash map lookup/insert O(1) Worst case O(n) with collisions
BST search/insert (balanced) O(log n) Degrades to O(n) if unbalanced
Binary search O(log n) Requires sorted data
Merge sort / Quicksort O(n log n) Mergesort stable, guaranteed
BFS / DFS O(V + E) V = vertices, E = edges
Final Checklist Before Your Interview
• Practice explaining your reasoning out loud, not just silently coding.
• Always clarify requirements/edge cases before jumping into a solution.
• State time/space complexity after every coding answer.
• Prepare 2-3 strong personal project or challenge stories to reuse across behavioral questions.
• Prepare 2-3 thoughtful questions to ask the interviewer at the end.
Recommended Last-Minute Resources
• LeetCode: 50-60 easy/medium problems — arrays, hashing, trees, graphs, DP.
• "Cracking the Coding Interview" for structured practice and behavioral framing.
• "Grokking the System Design Interview" for design-round practice.
• Mock interviews: Pramp or [Link].
Good luck! Focus on clear communication of your thought process — interviewers usually care more about how you reason through
a problem than whether you get the optimal answer instantly.