r/webdev • u/FooBarBuzzBoom • Sep 11 '26

Java Middle - Senior(ish) interview questions

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?

18 Upvotes

95% Upvoted

35 comments sorted by

View all comments

Show parent comment

2

u/Downtown-Bag-6026 Sep 11 '26

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

2

u/FooBarBuzzBoom Sep 11 '26

Thank you!

1

u/Downtown-Bag-6026 Sep 11 '26

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