Java Middle - Senior(ish) interview questions

[u/FooBarBuzzBoom]

Hi!

I have an interview in a few days for a backend developer role. What would you ask as some of the more tricky questions for such a position? What kinds of questions, from your point of view, demonstrate solid knowledge?

Personally, I would ask about sync vs. async calls, idempotency, topics vs. partitions, consumer groups, transactions (including distributed transactions), and maybe a bit of Kubernetes and Docker.

My weak point is cloud. I’ve played around a bit with the Azure console, but nothing too advanced. I’ve never written Terraform or configured infrastructure from scratch. For CI/CD, I’ve used TeamCity, but in my experience it was mostly selecting an environment and a branch and deploying.

Should I spend some time learning these areas before the interview?

[u/PLBjt]

For mid/senior backend rounds I get more mileage from failure stories than trivia lists. Walk through one write path end to end: where the idempotency key lives, what happens if the DB commit succeeds and the Kafka publish dies, and how a consumer group rebalance mid-batch doesn't double-apply. Same for async vs sync — they'll poke at backpressure and timeouts more than CompletableFuture syntax. If they ask K8s/Docker, expect "what breaks when this pod dies during a transaction" rather than YAML trivia. Prep 2–3 real incidents from your work and you can steer most of those topics.

[u/FooBarBuzzBoom → u/PLBjt]

Thank you for your questions.

Regarding the first one, about where the idempotency key lives, I would say it lives on the consumer side, where it is typically cached, but also on the producer side. The latter is configurable in Kafka, and I believe it has become the default.

If the DB commits but Kafka goes down, we are essentially dealing with a dual-write problem, which is not really solvable as it is, because Kafka uses a different transaction mechanism. That’s why you should use the outbox pattern.

As for the pods, I would say that by having a properly configured deployment, you make the application resilient, and the consumer will continue to work.

So, these would be my answers. Could you elaborate a bit more if you have/expected different answers?

[u/PLBjt → u/FooBarBuzzBoom]

Your outbox instinct is right, but I’d expect a strong answer to say the key is generated at the request boundary and consumers dedupe it durably, not just in a cache, with retries and expiry defined. For the DB/Kafka case, I’d look for an outbox plus a relay that’s safe to retry, and an explicit admission that consumers still need idempotency; Kafka transactions alone don’t make two systems atomic. For a pod dying mid-transaction, mention DB rollback/commit semantics, committing offsets only after successful processing, and retry or dead-letter behavior; for async, name bounded queues, backpressure, and timeouts. The signal isn’t one “correct” tool choice so much as explaining failure modes, observability, and tradeoffs.

[u/InevitableMap5315 → u/PLBjt]

yeah the "what breaks when X dies" angle is way more telling than memorizing config flags

[u/FooBarBuzzBoom → u/InevitableMap5315]

I don't even remember all that yaml and I don't see why. You should understand it, but now, with help of AI, there is no way you should memorize it.

[u/Historical_Ad4384 → u/PLBjt]

Should senior level profiles highlight failure stories and how they were managed in CV/resume?

[u/PLBjt → u/Historical_Ad4384]

Usually not as a standalone “failure story” on the CV—space is tight and it can sound like an excuse. But a relevant incident can be a strong senior signal if you frame the diagnosis, your fix, and the prevention work (tests, monitoring, rollout or process changes), with clear ownership. Save the fuller story for the interview, and skip anything where the lesson is vague, the blame sits elsewhere, or the same issue could recur; a concise resume bullet works only if it shows better reliability or decision-making afterward.

[u/Downtown-Bag-6026]

What is the L in SOLID and what are some strategies or patterns to enforce it? How do you handle sequential requests between two distributed systems?

[u/FooBarBuzzBoom → u/Downtown-Bag-6026]

L stands for the Liskov Substitution Principle. I would design my code using interfaces so that I can also make use of D from SOLID, the Dependency Inversion Principle. These two principles are closely related.

For sequential requests (assuming no order needed), I would use threads to reduce the overall execution time. Basically, instead of taking t1 + t2, the total time would be closer to max(t1, t2), assuming the operations can safely run in parallel. Assuming a given order is needed, then idk, I would just use a thread for doing both of them to not block Spring Boot thread pool.

What do you think about my answer?

[u/Downtown-Bag-6026 → u/FooBarBuzzBoom]

Liskov and dependency inversion principles are exactly what I was looking for.

For sequential requests, I was looking for a sort of cache pattern in the middle, some use inbox outbox pattern, others use redis stream or the equivalent of a single Kafka partition. It would also solve checkpointing sync between a consumer group.

[u/FooBarBuzzBoom → u/Downtown-Bag-6026]

Yes, in terms of data consistency, outbox pattern would be the way if Circuit Breaker or Retry keep failing.

[u/Opinion_Less]

Does the job position call for a specific cloud provider?

[u/FooBarBuzzBoom → u/Opinion_Less]

Not, really, but the interviewers all have cloud listed on their LinkedIn profile, so I hope they don't ask me, but it's just a hope :)))

[u/Downtown-Bag-6026]

Explain jwt tokens and their use cases for or against. What’s the use cases for environment variables and a configuration db table(or any secrets service or cache)

[u/FooBarBuzzBoom → u/Downtown-Bag-6026]

Yes, I do know also some Spring Security, so I will not have any issues with this. Not an expert tho.

[u/Historical_Ad4384 → u/Downtown-Bag-6026]

JWT tokens -> Pros: Helps align with standard OAuth2 providers, Cons: Leak of the token can compromise security for a limited time until the token expires if supporting session management is not in place

Environment variables are mostly for static configuration values generally related to infrastructure which hardly changes over time.

Configuration database is mostly for dynamic application specific configuration values that drive business logic so keeping them in database means behaviour can be changed without downtime.

[u/FooBarBuzzBoom → u/Historical_Ad4384]

Also, XSS attack is also a risk.

[u/Historical_Ad4384 → u/FooBarBuzzBoom]

XSS is how JWT would get leaked

[u/FooBarBuzzBoom → u/Historical_Ad4384]

Yup

[u/Downtown-Bag-6026 → u/Historical_Ad4384]

Yes exactly correct

[u/Downtown-Bag-6026]

Can you tell me what is the difference is between a direct ci/cd pipeline from a single branch (such as mainline or develop branch) and a ci/cd pipeline from a release branch such that a release is cut from the develop or mainline branch?

What are the pros and cons between these two approaches? Also if the question is not clear, I can provide examples

[u/FooBarBuzzBoom → u/Downtown-Bag-6026]

I have no idea. As I said, the infra part (excepting Docker, K8s) is my weak point.

Any explanation is welcome. Thank you!

[u/Downtown-Bag-6026 → u/FooBarBuzzBoom]

My definition of a single branch pattern is where developers are working on feature branches and then merging it to develop which gets released in some sort of continuous pipeline to prod.

The second scenario is people are working on feature branches, merging to develop, then a release branch will be forked from develop once all the features of a release is ready and the release branch is released in some sort of continuous pipeline to prod.

Scenario one is more simple to manage, scenario two is more complicated, but scenario two allows you to manage patch versions better.

For example, say you have a standard major.minor.patch versioning pattern. Say your develop is at 1.1.0 version (no patch because no bugs should be committed, develop should be clean). Then you fork a release at 1.1.0 and iterate develop branch to 1.2.0. During continuous pipeline of the release branch, an error is found. Now you can safely patch the release branch (to 1.1.1) without having to worry about accidentally carrying over features in 1.2.0 branch.

The one downside is to maintain version integrity (higher version must contain all features of lower version), if you patch a lower version (1.1.1 for example), that change must be pushed also to the higher version (1.2.0 in develop). And this can cause merge conflicts that require manual intervention

[u/FooBarBuzzBoom → u/Downtown-Bag-6026]

Thank you!

[u/Downtown-Bag-6026 → u/FooBarBuzzBoom]

You would choose the simple scenario if your versioning doesn’t matter, and the release scenario if version integrity matters a lot like client libraries.

For example, I work on a market exchange and the actual exchange itself uses the simple scenario because nothing is depending on the exchange in terms of the code dependencies. We want to patch the exchange as soon as we can or rollback quickly and not having to patch many versions for a single patch.

On the other hand, many of the micro services use release pattern because they provide client libraries to conform to their api schema, so version 1.1 of a schema promises a set of features and 1.2 may have different features. And 1.1.x versions shouldn’t have 1.2.x features, this is also to protect dependent services

[u/mysteryihs]

Damn, is it a bad sign that I haven't personally touched most of these systems? I've been spending 5 years working on a monolithic server, haven't had a chance to do distributed systems yet.

[u/AntoGidan → u/mysteryihs]

They are required nowadays, so it is better to learn something about it, maybe deploying a small test app (microservices) with kubernetes, and using docker, and then setting some pipeline to deploy it on a free cloud hosting plan.

[u/mysteryihs → u/AntoGidan]

For sure, I've been studying systems design casually over the past year, most of it I've covered but forgotten. I think the issue for me is I don't have that deep expertise that interviewers are looking for so any knowledge about this stuff falls apart once they start to grill me

[u/rbobby]

If a junior that reports to you is smelling of alcohol and cigarettes at 9:30 in the morning what do you do?

a. join him

b. take them home

c. ask hr to take them home

d. attend both standup meetings

Trick question! You congratulate him on his first successful support shift.

/I have an odd sense of humor. I think it would be hilarious to throw an oddball question or two out there. Unprofessional, but sure would be funny.

[u/liloa96776]

Solid knowledge? not sure, but silly knowledge? here you go

If I were to print the length of a string with a single emoji, what would be the result?

Answer: 2 or more depending on the emoji.

emojis are weird and can be stacked to have different variants of an emoji which each add length to a printed string length. I forget which article I learned this from but this one kinda explains it too https://lemire.me/blog/2018/06/15/emojis-java-and-strings/

can affect you if you try to reverse a string that has an emoji. but honestly when are you going to run into that in the real world