Software Engineer interview questions

I've been writing software professionally for about six years. I started in India with a product company building APIs for fintech, then moved to Muscat two years ago when I joined an Omani digital-banking team. The move was deliberate; I wanted to work in a market where digital transformation is happening at speed, not just maintenance. Today I lead the backend for our mobile-banking app and the GCC has matched what I was looking for: fast-moving products with real users, regulated environment, multi-cultural teams.

I'd start with the constraints: latency budget (probably 200-300ms), region (Oman-based traffic, so I'd host in a regional data centre or AWS me-central-1), and what 'login' includes (auth, MFA, fraud check). For 10K concurrent, I'd put a stateless API layer behind a load balancer scaled horizontally, with Redis for session and rate-limiting state. The fraud check is the bottleneck so I'd make it async where I can, sync only when risk score crosses a threshold. I'd front everything with a CDN for static assets and use connection pooling carefully on the DB. For monitoring I'd want p50/p95/p99 latency, error rate, and per-endpoint throughput on dashboards before launch.

I test what would hurt most if it broke. For a payments service that means full coverage on financial calculations, currency conversion, idempotency, and concurrency. Lower priority is UI styling tests, which I lean on visual-regression tools for instead of unit tests. I'm also pragmatic about integration vs unit: I write a smaller number of fast unit tests for the core logic plus a few end-to-end tests for the critical paths. I do not chase 100% coverage; coverage is a vanity metric. I chase confidence-to-ship.

First I check the obvious: environment variable differences, the deployed version vs my local branch, and the production logs in the time window of the failure. Most prod-only bugs trace to one of three things: data differences (prod has real data, local has cleaned data), config differences, or concurrency/load differences. I reproduce the failure in staging if I can, with a similar dataset. If I can't reproduce, I add targeted logging or feature flags so I can light up just the broken path in prod for one user. I rarely guess; I instrument.

I try to share information without the jargon by default. In standup or update calls I lead with what changed for users, then what we shipped, then what is next. When there is a tradeoff, I bring it to them with options rather than a single answer; for example, 'we can launch this on time with the smaller scope, or two weeks later with full scope; which matters more for the launch event?' That phrasing puts the decision back in their hands instead of me deciding for them. It builds trust because they feel like a partner, not a customer.

Based on the Talent Arabia salary data for senior engineers in Oman banking, I'd target OMR 1,800 to 2,200 total package, depending on the full benefits structure. I'm flexible if the package is structured well, especially the housing allowance and the annual bonus. On start date, I'm on 60 days' notice. If the offer is right, I'd also explore a buy-out arrangement to start in 30 days. Happy to discuss the specifics once we're both confident this is a fit.