Roshan Bhandari
Team Lead · Software Engineer · DevOps
Available for Projects
The most commonly asked software development interview questions in Nepal — covering OOP, data structures, databases, system design, APIs, and behavioral questions with clear answers.
Software development interviews in Nepal follow a fairly consistent pattern across companies — from Kathmandu agencies to product companies like Leapfrog, CloudFactory, F1Soft, Fusemachines, and the growing number of international remote-hiring teams.
The questions below are drawn from real interview reports, community discussions in Nepali developer groups, and the patterns that consistently appear across technical hiring in Nepal. They are grouped by category so you can prepare systematically rather than randomly.
Each answer here is a starting point — interviewers want to see that you understand the concept well enough to discuss it, not that you have memorised a definition.
OOP questions appear in almost every interview in Nepal, regardless of the tech stack.
Encapsulation — bundling data and methods that operate on that data into a
single unit (class), and restricting direct access to internal state.
Abstraction — hiding complex implementation details and exposing only the
necessary interface.
Inheritance — a class can inherit properties and methods from a parent class,
enabling code reuse.
Polymorphism — the ability of different classes to be treated as instances of
the same interface, with different implementations for the same method.
An abstract class can have both implemented methods and abstract methods. It can hold state (instance variables). A class can only extend one abstract class.
An interface defines a contract — it traditionally contains only method signatures (no implementations, though modern PHP and Java allow default methods). A class can implement multiple interfaces.
Use an abstract class when sharing common behaviour across closely related classes. Use an interface when defining a contract that unrelated classes should fulfil.
Cohesion refers to how closely related the responsibilities within a single module are. High cohesion is desirable — a class or function should do one thing well.
Coupling refers to how dependent modules are on each other. Low coupling is desirable — modules should be as independent as possible, making them easier to change or replace without affecting others.
Good software aims for high cohesion and low coupling.
S — Single Responsibility: A class should have only one reason to change.
O — Open/Closed: Open for extension, closed for modification.
L — Liskov Substitution: Subtypes must be substitutable for their base types.
I — Interface Segregation: Clients should not be forced to depend on interfaces they do not use.
D — Dependency Inversion: Depend on abstractions, not concrete implementations.
A design pattern is a reusable solution to a commonly occurring problem in software design. Commonly used patterns:
These questions are common at product companies and during coding tests. Leapfrog, Fusemachines, and companies with a remote-hiring pipeline typically include a DSA round.
An array stores elements in contiguous memory, allowing O(1) access by index but O(n) insertion/deletion at arbitrary positions.
A linked list stores elements as nodes with pointers to the next node. Access by index is O(n), but insertion and deletion at known positions are O(1). Use arrays when you need fast random access; use linked lists when you need frequent insertions and deletions.
A stack is Last In, First Out (LIFO) — the last element added is the first removed. Operations: push (add), pop (remove top). Used in function call stacks, undo operations, expression parsing.
A queue is First In, First Out (FIFO) — the first element added is the first removed. Operations: enqueue (add), dequeue (remove front). Used in task scheduling, print queues, BFS traversal.
Average case: O(1) for insert, delete, and lookup. Worst case: O(n) when all keys hash to the same bucket (collision). A good hash function and load factor management keep performance close to O(1) in practice.
BFS (Breadth-First Search) explores all neighbours at the current depth before moving deeper. Uses a queue. Finds the shortest path in unweighted graphs.
DFS (Depth-First Search) explores as deep as possible before backtracking. Uses a stack (or recursion). Useful for cycle detection, topological sorting, maze solving.
Big O notation describes the upper bound of an algorithm's time or space complexity as input size grows. O(n) means time grows linearly with input size — doubling the input doubles the time. O(n²) means time grows quadratically — doubling the input quadruples the time. A nested loop iterating over the same array is a classic O(n²) pattern.
Recursion is when a function calls itself to solve a smaller version of the same problem. A base case is the condition that stops the recursion — without it, the function calls itself infinitely and causes a stack overflow. Classic examples: factorial, Fibonacci, tree traversal.
Binary search works on a sorted array by repeatedly halving the search space. Compare the target to the middle element: if equal, return it; if the target is smaller, search the left half; if larger, search the right half. Time complexity is O(log n) — far faster than linear search O(n) for large arrays.
Database questions are asked in almost every Nepali tech interview. Companies expect practical knowledge, not just definitions.
SQL databases (MySQL, PostgreSQL) are relational — data is stored in tables with defined schemas and relationships. ACID transactions guarantee consistency. Best for structured data with complex queries and relationships.
NoSQL databases (MongoDB, Redis, Cassandra) store data in flexible formats (documents, key-value, column-family, graph). Better for unstructured data, horizontal scaling, and high-write workloads. Trade consistency guarantees for flexibility and scale.
An index is a data structure (typically a B-tree) that allows the database to find rows matching a query without scanning the entire table. A query on an indexed column runs in O(log n) instead of O(n). The trade-off: indexes speed up reads but slow down writes because the index must be updated on every INSERT, UPDATE, and DELETE.
INNER JOIN — returns only rows that have matching values in both tables.
LEFT JOIN — returns all rows from the left table and matching rows from the
right; unmatched right-side rows return NULL.
RIGHT JOIN — the reverse: all rows from the right table, matched rows from the left.
Normalisation is the process of organising a database to reduce redundancy and dependency.
1NF (First Normal Form): Each column contains atomic (indivisible) values;
no repeating groups.
2NF: Meets 1NF; every non-key attribute is fully dependent on the entire
primary key (eliminates partial dependency).
3NF: Meets 2NF; no non-key attribute depends on another non-key attribute
(eliminates transitive dependency).
DELETE — removes specific rows (with a WHERE clause), logged row-by-row,
can be rolled back.
TRUNCATE — removes all rows instantly without logging individual rows,
faster than DELETE, cannot be rolled back in most databases.
DROP — removes the entire table structure and all its data permanently.
The N+1 problem occurs when loading a list of N records triggers one additional query for
each record — for example, loading 100 users and then fetching each user's profile in a
loop causes 101 queries instead of 2. In Laravel, this is solved with eager loading
(with()). In general, it is solved by JOINs or batched queries.
Atomicity — a transaction either fully completes or fully rolls back.
Consistency — a transaction brings the database from one valid state to another.
Isolation — concurrent transactions do not affect each other's intermediate state.
Durability — a committed transaction persists even after a system failure.
Senior and mid-level interviews at Nepali product companies and remote-hiring teams often include system design questions.
Core components: a REST API to accept a long URL and return a short code, a database to store the mapping (short code → long URL), and a redirect handler. Key decisions: how to generate the short code (base62 encoding of an auto-incremented ID is simple and collision-free), caching hot URLs in Redis to avoid database hits on every redirect, and handling custom aliases as a separate database lookup. For scale: add read replicas and a CDN for global redirect performance.
Vertical scaling — adding more resources (CPU, RAM, storage) to a single server. Simple but has a physical ceiling and a single point of failure.
Horizontal scaling — adding more servers and distributing load between them. More complex (requires load balancers, shared sessions, distributed data) but theoretically unlimited. Modern cloud architecture favours horizontal scaling.
REST (Representational State Transfer) is an architectural style for APIs. A RESTful API: uses HTTP methods semantically (GET for reads, POST for creates, PUT/PATCH for updates, DELETE for deletion), is stateless (each request contains all context needed), addresses resources via URLs, and returns standard HTTP status codes. Good REST APIs are predictable, consistent, and versioned.
Authentication — verifying who you are (login with username and password,
JWT token validation).
Authorisation — verifying what you are allowed to do (does this user have
permission to access this resource?). Authentication always comes first.
Caching stores the result of an expensive operation so it can be reused without re-computing. Use it when the same data is read frequently and changes infrequently — database query results, API responses, rendered HTML fragments. Redis is the most common caching layer in Nepal's tech stack. Key concerns: cache invalidation (when to expire stale data) and cache stampede (many requests hitting the database simultaneously after a cache miss).
A message queue (RabbitMQ, AWS SQS, Redis queues) decouples a producer of work from its consumer. Use it when: processing should happen asynchronously (sending emails, generating reports), you need to handle traffic spikes without dropping requests, or work must be retried on failure. In Laravel, queues are a first-class feature — interviewers at Laravel shops will ask about this specifically.
Critical for the majority of interviews in Nepal, which are predominantly web development roles.
GET — retrieves data; parameters in the URL; should be idempotent and safe
(no side effects); can be cached and bookmarked.
POST — submits data; parameters in the request body; not idempotent; used
for creating resources, form submissions, anything that changes server state.
CORS (Cross-Origin Resource Sharing) is a browser security mechanism that blocks JavaScript
running on one domain from making requests to a different domain unless the server explicitly
allows it via HTTP headers (Access-Control-Allow-Origin). It exists to prevent
malicious scripts on one site from silently reading data from another site where the user is
logged in. On the server side, you configure which origins, methods, and headers are permitted.
Session-based — the server stores session state (in memory or database); the client holds only a session ID in a cookie. Stateful — the server must look up the session on every request. Simpler to implement; requires sticky sessions or shared session store for horizontal scaling.
Token-based (JWT) — the server issues a signed token containing the user's claims. The client sends this token with every request. Stateless — the server validates the signature without a database lookup. Works well for APIs and distributed systems.
SQL injection occurs when user input is concatenated directly into a SQL query, allowing an attacker to alter the query's logic — for example, bypassing a login check or dumping database contents. Prevention: always use parameterised queries or prepared statements. Never build SQL strings by concatenating user input. ORMs like Eloquent use prepared statements by default, but raw query usage requires care.
Synchronous — code executes line by line; each operation waits for the
previous one to complete before proceeding.
Asynchronous — an operation can be started and the program continues without
waiting for it to finish; a callback, promise, or async/await handles the result when ready.
Async is critical for I/O-heavy operations (database queries, API calls, file reads) so
the thread is not blocked while waiting.
MVC (Model-View-Controller) separates application concerns:
In Laravel, a request hits a route, the route dispatches to a controller method, the controller interacts with models, and returns a view or JSON response.
Dependency injection means providing a class's dependencies from outside rather than having the class create them itself. This makes code easier to test (you can inject mock dependencies), easier to change (swap implementations without touching the class), and respects the Dependency Inversion SOLID principle. Laravel's service container resolves dependencies automatically via constructor injection.
git merge — creates a new merge commit that combines two branches, preserving the full history of both. The branch history shows a fork and a merge point.
git rebase — rewrites the commit history of one branch to appear as if it branched off the latest point of another. Produces a linear history but rewrites commits. Never rebase commits that have been pushed to a shared branch.
Continuous Integration (CI) — developers frequently merge code into a shared branch; automated tests run on every merge to catch problems early.
Continuous Delivery/Deployment (CD) — the process of automatically deploying passing builds to staging (Continuous Delivery) or production (Continuous Deployment). Tools like GitHub Actions, GitLab CI, and Jenkins automate these pipelines. CI/CD reduces deployment risk by making releases smaller, more frequent, and automated.
Docker packages an application and all its dependencies into a container — a lightweight, isolated environment that runs consistently across any machine. "Works on my machine" problems disappear because the container includes the exact same OS libraries, runtime, and configuration everywhere. In Nepal's tech industry, Docker usage has grown significantly as companies move toward containerised deployments on AWS, Azure, or their own servers.
A process is an independent program in execution with its own memory space. Processes are isolated — one process crashing does not directly affect others.
A thread is a unit of execution within a process. Threads within the same process share memory. They are faster to create than processes but require careful synchronisation to avoid race conditions.
Unit testing — tests individual functions or methods in isolation, with dependencies mocked. Fast, precise, forms the base of the testing pyramid.
Integration testing — tests how multiple components work together (e.g., a controller calling a real database). Slower than unit tests but catches problems that mocking hides.
End-to-end (E2E) testing — simulates a real user interacting with the full application in a browser (tools: Cypress, Playwright). Slowest, most brittle, but gives the highest confidence that the system works from the user's perspective.
TDD is a development practice where you write the test before the code. The cycle: write a failing test → write the minimum code to make it pass → refactor. Benefits: forces clear thinking about requirements, produces naturally testable code, and builds a safety net for future changes. In practice, many developers use TDD selectively for complex logic rather than applying it universally.
Black box testing — testing without knowledge of the internal implementation. Input goes in, output comes out; the tester validates the output against requirements. Used by QA engineers and end-to-end tests.
White box testing — testing with knowledge of the internal code. Tests are written to cover specific code paths, branches, and conditions. Used for unit and integration tests written by developers.
The OWASP Top 10 is a standard list of the most critical web application security risks. Key ones every developer should know:
Cross-Site Scripting (XSS) occurs when an attacker injects malicious scripts into a page
that is then executed in other users' browsers — allowing cookie theft, session hijacking,
or UI spoofing. Prevention: always escape user-supplied content before rendering it in HTML
(most templating engines like Blade do this by default with {{ }}). Use a
Content Security Policy (CSP) header as a second layer of defence.
Hashing is one-way — you cannot reverse a hash to get the original value. Used for storing passwords (bcrypt, Argon2). To verify a password, you hash the input and compare hashes.
Encryption is two-way — you can decrypt ciphertext back to plaintext using a key. Used for data that needs to be retrieved later (sensitive fields, messages in transit via TLS). Never use encryption for passwords — if the key is compromised, all passwords are exposed.
Waterfall is a linear, phase-by-phase model: requirements → design → build → test → deploy. Each phase completes before the next begins. Works when requirements are fully defined upfront and unlikely to change.
Agile is iterative — software is built and delivered in short cycles (sprints, typically 2 weeks). Requirements evolve based on feedback. Teams are cross-functional and self-organising. Most Nepali product companies and international clients use some form of Agile (Scrum or Kanban).
Technical debt is the accumulated cost of taking shortcuts or making suboptimal design decisions in code. Like financial debt, it compounds — the longer it is not addressed, the harder and more expensive it becomes to change the code. Common causes: skipping tests to meet a deadline, writing procedural code instead of modular code, choosing the quick fix over the correct fix. Interviewers ask this to assess whether you think long-term about code quality.
Good answer framework: First, gather all available information — error logs, user reports, error monitoring tools (Sentry, Bugsnag). Add detailed logging around the suspected area. Review recent changes (git blame, git log) that might have introduced the issue. Try to reproduce in a staging environment with production-like data. If it appears intermittent, look for race conditions, timing-dependent code, or environmental differences between servers. The ability to reason through this systematically signals engineering maturity.
Code review is the practice of having peers examine code before it is merged. Benefits: catches bugs before they reach production, spreads knowledge of the codebase across the team, enforces coding standards, and often produces better solutions through discussion. Good code reviewers focus on correctness, readability, security, and performance — not personal style preferences. In remote teams serving European or US companies, code review culture is taken seriously and interviewers will ask about your experience with it.
A library is code you call. You are in control — you import the library and call its functions when you need them (example: Lodash in JavaScript, Guzzle in PHP).
A framework calls your code. You fill in the blanks within a structure the framework defines — it controls the flow, and you implement the specific parts (example: Laravel, React, Django). This is sometimes called "Inversion of Control."
Nepali companies — especially those with international clients or remote-first cultures — are increasingly asking structured behavioural questions. These are evaluated as seriously as technical ones.
Use the STAR method: Situation (what was the context), Task (what were you responsible for), Action (what specifically did you do), Result (what was the measurable outcome). Be specific — name technologies, metrics, team size. Avoid vague answers like "I worked on a lot of projects." Interviewers want to understand your contribution and the impact it had.
Strong answers show you can disagree constructively: present your reasoning with data or evidence, actively listen to the other perspective, look for common ground, and ultimately support the team's decision once it is made even if it is not your preference. What interviewers are screening against: developers who cannot work in a team, or conversely, developers who never push back and blindly execute poor decisions.
Interviewers ask this to assess ambition, self-awareness, and whether your goals align with the company's trajectory. Honest, specific answers are better than formulaic ones. If you want to grow into a technical lead role, say so. If you want to specialise deeply in a particular area — distributed systems, ML infrastructure, DevOps — say that. Companies that invest in people want to know those people are thinking about their growth, not just their next paycheck.
Most Nepali tech interviews follow a three-stage pattern: an initial screening call, a technical assessment (take-home or live coding), and a final interview that mixes technical depth with team fit. Agencies tend to focus more on portfolio and practical ability; product companies add system design and DSA rounds for mid-senior roles.
For remote-hiring companies — particularly European clients who hire through platforms like Toptal or via direct LinkedIn outreach — expect more rigorous technical assessments and a greater emphasis on communication skills during the interview itself.
The best preparation is building and shipping real things, then being able to talk about the decisions you made and why. No amount of memorising definitions substitutes for the credibility that comes from practical experience with the concepts these questions are probing.