Say each answer aloud and swap the example for something you did. For questions that show up in every process, use the HR interview questions for freshers guide. For the coding round, talk through problems from Code Quest, which has 7,000+ coding problems when your institute provides access.
Contents
Technical/role knowledge
1. What is the difference between a process and a thread?
Start with memory, not with a line you memorised. A process has its own memory space, and a thread runs inside a process and shares that memory. Then say why it matters: threads let one program do concurrent work, and a separate process is how you isolate a failure.
A process is the running program with its own memory. Threads inside it share that memory, so they are cheaper to start and can also corrupt each other’s data. I would pick a process for isolation and threads when the work must share state.
2. How do you explain time complexity to someone who has not studied algorithms?
Describe how the work grows as the input grows, and say that constant factors are set aside so two linear approaches look similar. Contrast a single pass over a list with a loop nested inside another loop over the same list. Close by tying the class of growth to the size of data you expect, rather than to a slogan about speed.
Time complexity is how the steps grow when the input grows. Two nested loops over the same list are usually quadratic, so a classroom sample can hide a problem that shows up on a large file. I would name that class and then say what it means for the size we actually have.
3. When would you reach for a stack, and when for a queue?
Name the order each structure serves before you name a library. A stack is last-in first-out, which matches undo and the call stack. A queue is first-in first-out, which matches a line of jobs, and it is also the fringe you use in a breadth-first search.
I use a stack when the newest item must be handled first, as with undo or function calls. I use a queue when the earliest request should go first, as with tasks waiting to run.
4. What is the difference between HTTP and HTTPS, and what does a 404 mean?
Separate the protocol from the lock icon. HTTP is the request and response protocol, and HTTPS is HTTP with TLS, so the traffic is encrypted and the server presents a certificate. A 404 means the server understood the request and found no resource at that path, and the lock does not by itself mean the site is trustworthy.
HTTPS is HTTP protected by TLS. The bytes are encrypted and a certificate is checked, but that still does not prove the organisation is honest. A 404 means that path has no resource.
5. How would you choose between a SQL database and a NoSQL database for a small project?
Refuse the claim that one kind is simply faster. A SQL database stores related tables with a schema and joins them, while NoSQL names a family of models, such as documents or key-value stores, often chosen for one access pattern. Then match the choice to the data: stable relationships favour tables, a shape that varies a lot can favour documents, and you still have to say what consistency you need.
For orders, customers and products I would start with SQL because the relationships are the point. I would look at a document store if each record’s shape varied and I mostly fetched one record by its id.
Problem solving and scenario
6. A feature works on your machine and fails for a teammate. How do you investigate?
Say that you will reproduce their steps before you change code. Compare one difference at a time: language version, dependencies, environment variables, data and operating system. Stop when you can name the difference that causes the failure, and do not call it an environment issue until you have found which part of the environment.
I would run their exact steps and write down the first point that diverges. Last time this happened the code was the same and a missing environment variable changed a default. I would fix that and add a check so the next person sees a clear error.
7. How would you talk an interviewer through checking whether a string is a palindrome?
Restate the problem with a tiny example, then ask whether spaces, punctuation and letter case count. Describe two pointers moving inward, or a reversed copy, and say what you do with an empty string and a single character. Mention the rough cost only after the approach is clear, and test the example by hand before you claim it works.
I would first ask whether spaces and case count, because that decides whether a sentence can be a palindrome. I walk one index from the left and one from the right, skipping nothing unless we agreed to, and I treat an empty string as a palindrome.
8. A page feels slow. What do you check before you change anything?
Say that you will measure before you optimise. Look at how many requests the page makes, how large the responses are, and whether a query returns far more rows than the screen shows. Mention a missing index or repeated work only as something the timing might reveal, and leave caching until you know which step is slow.
I would open the network timing and find the slowest request before I edit code. If that request loads an entire table to show ten rows, I would fix the query before I add a cache.
9. You find a bug the evening before a demo. What do you do?
Reproduce it, then say whether the demo path hits it. Tell the team as soon as you know that, even if you have not fixed it yet. Fix it if the change is small and testable, or script the demo around it and write the bug down so it is not discovered live.
I would confirm the steps, tell the person running the demo, and fix it only if I could test the fix that night. If not, I would show a path that avoids the bug and file it with the steps.
10. How would you sketch a URL shortener at a fresher’s level?
Keep the design to the data, the main request and one failure. Store a short code and the long URL, redirect on a read, and generate a new code if the one you picked already exists. Say that a counter is easy to guess, so a random code is safer when the links are private, and do not put secrets inside the code itself.
I would keep a table of short code to long URL and redirect when someone opens the short one. If the code collides I generate another. I would use a random code for private links so people cannot walk the ids.
HR and behavioural
11. Tell me about a project you built.
Use one project and four beats: the problem, your part, a tradeoff, and something that broke. Stay on what you wrote or decided, not on the team in general. If the result has no number, say what the tests caught or what a user could do afterwards.
In a college project I built the part that saved form submissions. I chose a simple table over a more flexible document because we had to join submissions to students. An empty field crashed the save, and the test for that case is what I would walk through.
12. Describe a time you got stuck on a bug.
Name the symptom, two things you tried, and the moment you asked for help or found the cause. Interviewers listen for whether you narrowed the problem or changed code at random. End with the check you added so the same trap is visible next time.
A score page showed zero for every student. I logged the query and then the input, and the id was a string where the database expected another type. I asked a classmate to look at that line, fixed the conversion, and left the log in for that field.
13. Why do you want to work as a software engineer?
Tie the answer to something you finished, not to a childhood slogan. Say what kind of problem you like, such as making a rough process reliable, and what you want to learn in a first job. Avoid claiming you already know production systems you have not worked on.
I like taking a messy manual step and making it repeatable. In my project the interesting part was the failing case, not the happy path. I want a first role where I can ship small changes and learn how a team reviews them.
14. How do you handle feedback on your code?
Show that you read the comment against the requirement before you defend the line. Ask what behaviour the reviewer wants if the note is unclear. Then describe the change you made, or a tradeoff you explained, without treating every comment as an attack.
A reviewer said my function did two jobs. I split the validation from the save and asked whether the error message was the part they cared about. The second review was about names, which was a smaller change.
15. Tell me about a teammate who wanted a different approach.
Describe the decision, not the person’s character. Say what each approach made easier, how you chose, and what you did after the decision so the work continued. A good ending is a shared test or a note, not a claim that you won.
I wanted to compute a result in the browser and my teammate wanted it on the server. We listed the data the browser did not have, so the server version was the one we could trust. I wrote the request, and they reviewed the response shape.