Software engineer interview questions and answers in English

B1 answer

I'm a backend developer. I've worked with Python and Django for four years. Right now I'm building a payment system for an online shop. I like solving problems with clean code, and I want to work on a bigger product.

B2 answer

I'm a backend developer with four years of experience in Python and Django. Most recently I've been building the payment service for an online marketplace, which handles around 20,000 orders a day. I enjoy working on reliable systems, and I'm looking for a team with a larger product.

B1 answer

I use your product every week, and I like how simple it is. I read your engineering blog, and I like that you write tests. I think my experience with APIs can help your team.

B2 answer

I've followed your product for a while and I read your engineering blog about moving to event-driven services. I have worked on a similar migration, so I think I could contribute quickly. I also like that your team shares knowledge openly.

B1 answer

I'm proud of a payment system I built last year. Before, payments failed many times. I added retries and better error messages. After that, the failures went down by 60 percent.

B2 answer

I'm most proud of rebuilding our payment flow last year. Failed payments were costing the company about 5 percent of revenue. I designed a retry system with clear error handling and led the rollout. Within two months, failures dropped by 60 percent.

B1 answer

Our API was very slow. I looked at the logs and I found too many database queries. I added a cache. The response time went down from 800 to 200 milliseconds.

B2 answer

Our main API had become slow, with response times around 800 milliseconds. I profiled it and found an N+1 query problem. My first fix, adding an index, only helped a little, so I added caching for the heaviest endpoint. That brought the time down to about 200 milliseconds.

B1 answer

A colleague wanted to use a new framework, but I thought it was risky. We did a small test together. The results showed it was not ready. We stayed with the old framework, and we were both happy.

B2 answer

A teammate wanted to adopt a new framework, and I thought it was too early. Instead of arguing, I suggested a two-day spike so we could decide with data. The test showed some stability problems, so we waited. We still use that spike as our template for technical decisions.

B1 answer

I use simple words and a short example. I do not use too much jargon. For example, I once told a manager that a database is like a big filing cabinet. Then I ask, 'Does this make sense?'

B2 answer

I start with what matters to them, not the technology. Then I use an analogy: I once compared an API to a waiter who takes orders to the kitchen. I avoid jargon, and I check that they have understood by asking them to tell me the idea in their own words.

B1 answer

I read tech blogs for twenty minutes every morning. I also do small projects at the weekend. Last month I learned Docker this way. I like to share what I learn with my team.

B2 answer

I mix reading with building. I follow a few engineering blogs and newsletters, and I learn by making small side projects. Recently I built a small service in Go to understand its concurrency model. I also run a short monthly session at work to share what I've learned.

B1 answer

One Friday I deployed a change and it broke the login page. I saw the alerts, and I rolled back the change in ten minutes. Then I wrote a test for the bug. After that, we stopped deploying on Fridays.

B2 answer

A few years ago I released a change that broke the login page for about ten minutes. I noticed the alert immediately, rolled back and told the team what had happened. We then added a test for that case and a staging check to the release process. Since then we have not had the same problem.

B1 answer

I break the work into small tasks, and I estimate each one. I add some extra time, because problems always come. If I think I will be late, I tell my manager early. I do not wait until the last day.

B2 answer

I break work into small tasks, estimate each one, and add a buffer for the unknowns. I update the estimate as I learn more. If something is at risk, I raise it as early as possible and propose options, such as reducing the scope or moving the date.

B1 answer

Yes. How does code review work in your team? And how often do you deploy to production?

B2 answer

Yes, a few. How does code review work here? How often do you deploy, and who is on call? And what would a successful first six months look like for this role?