Backend Software Engineer interview questions

I've been writing backend code for seven years, three in Oman. Started in Java at an Indian banking IT services firm, transitioned to a Node.js stack for a fintech startup, and for the past three years I've been at an Omani digital bank working primarily in Java (Spring Boot) with PostgreSQL and Kafka. My typical day: API development, integrating with our core banking system, debugging production issues, code review for the team. I've contributed to about 40 microservices across two product lines. SQL is comfortable, NoSQL (Mongo, DynamoDB) I've used for specific use cases.

REST-first, with proper resource naming, standard HTTP methods, consistent status codes. Versioning strategy from day one (URL path versioning works for most cases). Pagination, filtering, sorting baked in from the start, not added later. Strong typing on requests and responses with validation; reject bad input fast at the boundary. Idempotency where state-changing operations need retry safety. Authentication via standard token mechanisms (JWT or similar). Rate limiting per client. OpenAPI specification as the contract, with code generated from it. Errors structured consistently so clients can handle them predictably.

Normalise to third normal form by default; denormalise only with explicit reason and measurement. Indexes on every column used in WHERE, ORDER BY, JOIN, but not blindly; too many indexes slow writes. EXPLAIN every query before deploying. Foreign keys to enforce referential integrity unless the performance cost is documented. Naming conventions consistent (snake_case, singular table names for some teams, plural for others; pick one and stick to it). Schema migrations always reversible, version-controlled, applied via automation not manually.

Depends on the scope. Within a single request: be careful with shared mutable state, prefer immutability, use proper synchronisation (locks, atomic operations) when needed. Across requests for the same data: optimistic locking (version columns) or pessimistic locking (SELECT FOR UPDATE) depending on contention. Across services: idempotency keys for retry safety, eventual consistency where strong consistency isn't required, distributed locks (Redis or ZooKeeper) only when absolutely necessary because they're complex. The most common concurrency bug is forgetting that the database is shared state across all instances of a stateless service.

I try to understand the why before the what. If the PM asks for a feature, I ask what problem it solves and what success looks like; often that conversation reshapes the requirement. I bring engineering perspective to scope: this would take 4 weeks because of X, but if we descope Y we can do it in 2. I avoid 'no'; I prefer 'yes, with trade-off'. I respect that the PM owns the priority; my job is to help them make informed decisions, not to substitute my priorities for theirs. The relationship works when both sides treat each other as partners.

For a senior backend role in Oman fintech I'd target OMR 1,500 to 1,900 total package depending on the team scope and the tech stack. Modern stacks (Spring Boot, Kafka, modern cloud) pay better than legacy Java EE shops. I'm on 60 days' notice. Beyond pay I'd value the engineering culture; backend engineering in an org that values craft is much better than in one that values feature throughput only.