8 Common Java Interview Questions to Avoid

This tiny Java interview task looks strange, but it's a catch. Solve them all, and you're a giga-catch. Today I'm sharing code for reviewing. In the past examples I shared, I pointed out problems with using Java and Spring Boot. Today, I focus on problems in the business logic. Most of them are critical, so let's fight them. 1. Any user-input data should be validated, especially authentication data. Hackers will manipulate it to get access. You have to be paranoid here. 2. Logging sensitive data is a bad idea. If you want to do a hacker a favor, then log any user auth requests. In the event of a data leak, it'll help hackers collect many more credentials than ever. I have seen this two times in production code and immediately raised concerns and fixed it. 3. Creating an objectMapper in each call is a bad idea. ObjectMapper creation is not a cheap operation in terms of memory and CPU consumption, and you have to reuse it. You can get it from the Spring context or make your own copy in the service. That problem I saw while performing high-load testing and analyzing flame graphs - I noticed an intensive method where 70% of CPU time was spent creating an object mapper, nice, isn't it? 4. Code is loaded with different parts of the JWT token into memory and fetches the signature algorithm, but never validates the value inside it, and does not validate the signature at all, but it will be the next topic. 5. Dynamic deserialization - an easy way to deserialize the data because you don't need to write a class for JSON. Anyone could pass bad JSON to your service, and your service should deserialize it. Next, you should get the value from that a map object and pray it is in the expected type. Don't make your work harder - ask AI to generate a class for JSON. 6. JWT tokens contain different fields, but one of the important things is checking the expiration time. It helps to avoid problems when an attacker steals your token and logs in to a system. 7. The elephant in the room, hello mr. I'm not checking the JWT signature. A JWT has three parts: the header, the payload, and the signature. Anyone can try to manipulate the token's data, but the signature protects it from tampering. Only the private key owner can sign a token. On the receiver's side, you have to verify it using the public key. If the signature mismatches, the data has been changed. You always have to verify the signature to ensure it was issued by a trusted issuer. 8. Finally, because the signature wasn't checked, we are passing the subject to the query to check if the user is present. If so, we authenticate a user, regardless of whether they have the necessary rights. In other words, if you rely only on user input, you're opening the door to hell. I reached the post size limit many times. Some of the problems in the screenshot aren't described, but I know you can handle them on your own.

  • text

DB code not wrapped in repository class i would add to the "transactional" private method. But these annotation are steorotypes and optional (still would use it for marking and doc reasons) Logging input data can go horribly wrong (log4 hack which interpreted log , floating disk on denial of service)

Like
Reply

this is a classic example of why understanding the nuances of the java language specification is so important. it's fascinating how a seemingly simple task can reveal deeper complexities in how the jvm handles memory and object comparison. these "strange" interview questions are often the best way to separate rote memorization from true technical depth. thanks for sharing this great brain-teaser!

Like
Reply

In this case, every JPA repository find method - including custom ones defined in the interface - is already executed within a read-only transaction, so an explicit @Transactional annotation is not required

This is gold. Especially the ObjectMapper and JWT signature points - things that look “fine” until you see them under load or in real attacks. Real-world backend issues aren’t obvious until they hurt.

Like
Reply

I would inject userRepository via constructor and avoid generally autowired.

Transactional for reading??? :O omg..

Like
Reply

Shouldn’t the token be stored in ThreadLocal storage so downstream services chould validate claims themselves.

Like
Reply

Ah yes good old @Autowired allows null Injection. Maybe use constructor injection instead (soooo ugly lol). I am personally using @Inject which is supported by spring and disallows null values.

Like
Reply
See more comments

To view or add a comment, sign in

Explore content categories