Software development

What interviewers look for

• Working code under time pressure: a small, correct solution with clear names beats a clever one that does not run.
• A debugging method: you read the error, reproduce the problem and narrow it down, instead of changing lines at random.
• Team habits: Git branches, clear commit messages, pull requests, and taking code review without getting defensive.
• Understanding how the pieces connect: the app, the API, the database, and what happens when one of them fails.
• Evidence they can open: a GitHub repository, a live app or a demo, with your own part clearly explained.

Questions they ask

1. 1“Walk us through one project you built. What exactly was your part?”

   Why they ask: They want to know if you really wrote the code or followed a tutorial, and whether you understand the decisions inside it.

   How to answer

   • Start with the problem it solves and who used it, in one sentence.
   • Name the stack and your own part: which screens, endpoints or tables you wrote.
   • Describe one hard problem and how you solved it.
   • End with what you would do differently now.

   I built a small stock app for a family pharmacy in Burao. It is a Flutter app with a Node.js API and a PostgreSQL database. I wrote all of it myself, except the login screen, which I adapted from a tutorial. The hardest problem was stock going below zero when two staff sold the same item at the same moment. I fixed it by updating the quantity inside a database transaction. If I built it again, I would write tests from the start, because I only found that bug after a week of real use.

2. 2“How would you find a bug that happens for users but not on your own machine?”

   Why they ask: It tests your debugging method and whether you think about differences between environments: data, device, network and version.

   How to answer

   • Collect facts first: exact steps, device, app version, time, and the logs.
   • Compare their environment with yours: data, OS version, slow network, permissions.
   • Reproduce it, fix it, and add a test so it does not come back.

   First I get the exact steps, the phone model, the app version and the time it happened, then I check the server logs for that time. Many bugs that only happen for users come from their data or their network. On one project the app crashed only for users whose names had an apostrophe, like Ma'alin, which my test data never had. Once I can reproduce it, I fix it, add a test for that case, and tell the person who reported it.

3. 3“What is the difference between an array (list) and a hash map (dictionary)? When would you use each?”

   Why they ask: A basic data structures check. They want a simple, correct explanation and a real use, not a textbook definition.

   How to answer

   • Array: items in order, reached by position; finding a value means checking item by item.
   • Hash map: values stored by a key, so looking one up stays fast even with many items.
   • Give an example from your own code, like finding a customer by phone number.

4. 4“How do you use Git when you work in a team? What do you do when you get a merge conflict?”

   Why they ask: Teams lose time to messy Git. They check whether you can work in a shared codebase without breaking other people's work.

   How to answer

   • One branch per task, small commits with clear messages, and pull the latest main often.
   • Open a pull request and ask for review before merging.
   • For a conflict: read both versions, keep the right code, run and test, and ask the other developer if unsure.

   I create a branch for each task, for example feature/sms-reminder, and commit small steps with messages that say what changed. Before I open a pull request, I pull the latest main and run the app. When I get a merge conflict, I open the file, read both versions and work out why each change was made. If the other change is a teammate's and I'm not sure, I message them before choosing. Then I run the tests again before I push.

5. 5“Explain what happens when a mobile app sends a request to an API.”

   Why they ask: It shows whether you understand the whole path, not only your screen: request, server, database, response and errors.

   How to answer

   • The app sends an HTTP request: method, URL, headers (often a token) and a JSON body.
   • The server checks the token, runs the logic, reads or writes the database, and returns a status code and JSON.
   • Say what you do when it fails: timeouts, a clear message for the user, and retry.

   When the user taps Send, the app sends an HTTP POST to an endpoint like /api/payments, with a token in the header and the amount and phone number as JSON. The server checks the token, validates the data, saves the record in the database and returns a status code: 201 with the new payment as JSON, or 400 if the phone number is wrong. In the app I show a loading state, turn error codes into a clear message, and set a timeout, because mobile data can be slow.

6. 6“A senior developer leaves twenty comments on your pull request. How do you respond?”

   Why they ask: They want to see if you can take feedback, learn the team's standards, and disagree politely with a reason.

   How to answer

   • Thank them, read every comment, and fix the clear ones first.
   • Ask about any comment you do not understand; explain your reason calmly if you disagree.
   • Note the repeated points so your next pull request gets fewer comments.

7. 7“How do you check that your code works before you say it is finished?”

   Why they ask: It separates developers who hand over tested work from those who leave the testing to the users.

   How to answer

   • Run the main path and the edge cases: empty input, wrong input, no network.
   • Write unit tests for the logic that matters, like calculations and validation.
   • Test on a real, cheaper phone and a slow connection, not only on your own laptop.

Example answers are in English, the language most panels use. Say it in your own words.

Topics to revise

• Arrays, lists and hash mapsAn array or list keeps items in order and you reach them by position. A hash map (dictionary, object) stores values by key, so lookups are fast. They may ask which one you would use to find a customer by phone number: the hash map.
• Big O (O(1), O(n), O(n²))A simple way to describe how the work grows with the data. O(n) means one pass over the list; O(n²) means a loop inside a loop, which gets slow with thousands of records. Be ready to say why your solution is O(n) and how you avoided a nested loop.
• Git: commit, branch, merge, pull requestA commit saves a snapshot of the code with a message. A branch is a separate line of work. A pull request asks the team to review and merge your branch. They may ask how you undo a bad commit that is already pushed (git revert).
• REST API and HTTP methodsA REST API exposes resources at URLs. GET reads, POST creates, PUT or PATCH updates, DELETE removes. Know what an endpoint, a request body and a header are, and be ready to design two or three endpoints for a simple app.
• HTTP status codes (200, 201, 400, 401, 404, 500)200 OK, 201 created, 400 bad request (the client sent wrong data), 401 not logged in, 403 not allowed, 404 not found, 500 the server failed. A common question: the app shows an error; how do the status codes tell you where to look?
• JSONThe text format most APIs use to send data: keys and values inside curly braces, lists inside square brackets. They may show you a JSON response and ask you to read a nested field or spot the error in it.
• SQL basics and joinsSELECT, WHERE, ORDER BY, GROUP BY, and JOIN to combine tables, for example customers and their orders. Know what a primary key and a foreign key are, and why you use parameterised queries to stop SQL injection.
• Unit testsSmall automatic tests that check one function gives the right result, for example that a fee calculation is correct for zero, a normal amount and a very large amount. They may show you a function and ask what you would test.
• Debugging with logs and breakpointsA breakpoint pauses the program at a line so you can see the values there; logs show what happened on a server you cannot pause. Explain how you use them to find the point where the real value differs from the expected one.
• Environment variables and secretsPasswords, API keys and database addresses go in environment variables or a secrets store, never in the code or on GitHub. A panel may ask what you would do if a key was pushed by mistake: change (rotate) it at once, then clean the repository.

Practical tasks you may get

1. 1Live coding (30 to 60 minutes): a small problem such as counting repeated words, finding duplicates in a list or checking a phone number. Ask about the input first, say your plan out loud, write a simple version that works, then improve it. Practise ten short problems in a plain editor without autocomplete.
2. 2Take-home task (one to three days): build a small API or an app screen. Keep commits small, add a README that explains how to run it and what you would add next, and include a few tests. Submit on time even if one feature is missing, and say what is missing.
3. 3Code walk-through: they open your GitHub or your laptop and ask why you wrote a certain line. Re-read your main project the night before. If you used AI or a tutorial for part of it, say which part and what you changed.
4. 4Debugging exercise: a short program with one or two bugs and a failing test. Read the error message and the test first, reproduce the failure, then fix the smallest thing. Explain each step as you go.

Portfolio questions

• Pin two or three repositories on GitHub, each with a README: what it does, screenshots, how to run it, and your part if it was a team project.
• Expect: “Which part of this did you write, and which part came from a tutorial, a template or AI?” Answer exactly; an honest, clear split is respected.
• A live app (a link, or an APK on your phone) is stronger than code alone. Make sure it opens on the day and uses test data, not real customers' details.
• Be ready for “What would you improve?”. Name one real weakness, such as no tests or slow loading, and how you would fix it.

Mistakes to avoid

• Starting to type in the live exercise before asking what the input looks like and what should happen with empty or wrong data.
• Going silent while coding. The panel scores your thinking, so say what you are trying and why.
• Listing eight languages on the CV with no project behind most of them. One follow-up question shows the gap.
• A GitHub full of tutorial copies, with one commit called “final” and no README.
• Showing code written by AI that you cannot explain line by line.
• Leaving passwords or API keys inside a public repository.

Quick check

5 questions. Answer each one to see the explanation.