Interviewing Java Developers: Focusing on Fundamentals

Had an interesting interview today. Candidate: 5 years experience in Java. We started the discussion and things sounded quite strong initially. He spoke about microservices, some production issues he had handled, even mentioned race conditions and concurrency. At that point, it felt like a solid profile. Then I moved to a few basic questions: – OOPS concepts – how static actually works – difference between types of variables And that’s where things changed. The answers were either unclear or incomplete. Not something you’d expect from someone with 5 years of experience. It got me thinking… Are we focusing too much on high-level concepts and skipping the fundamentals? Or is it becoming acceptable because frameworks, tools, and now AI are doing most of the heavy lifting? Personally, I don’t think fundamentals can be ignored. You can talk about architecture all day, but when something breaks in production, it usually comes down to basics. If those aren’t clear, debugging becomes guesswork. AI can definitely help us write code faster. But without understanding, how do we know if the code is even correct? Still deciding what I would do in this case. Would you hire someone like this? Or do you see this as a red flag? #Java #Hiring #SoftwareEngineering #Interviews #CareerGrowth #TechCareers #Hiring #TechInterviews #InterviewExperience #Recruitment #HiringDevelopers #CareerGrowth #JobSearch #DeveloperJobs #AI

Based on my experience asking how static works and what is internal JVM n all stupid and most of issue people face at design level or architect level and if your interview 5+ years candidate then focus should be API level such as what is predicte , What are adavanced concurrent features used and when , object design, SOLID design , OOPS coding is enough for selection and nothing todo with what is internal of static

Both high-level concepts and basic fundamentals are important. It depends on the interviewer and the topics they ask about. As always, we should keep our basics clear.

there was this interview where I was asked, "can we use final and abstract together for a class in java?" My answer was: "though I have never written a single class like that in my entire career. but putting final and abstract together does not make any sense."but then the interviewer response was, "am not asking whether it makes sense or not am asking can we write final and abstract together".and to that I replied, "am not sure".and 2 days later got a rejection mail 😭 the point here is, why ask such stupid questions. you know you would never encounter this final & abstract together wala problem. Java would never let you compile that (which I got to know when I tried the same after interview).question is - how are you even judging candidates based on these random foolish questions. ask practical questions like - build a class or design that does something

Fundamentals matter, agreed. But technical skills are only part of the picture. Work ethic, ownership, and curiosity matter just as much in real work environments. Personal experience: I once got rejected with feedback "didn't ask questions" and "wasn't explaining thought process" — while I was heads down solving a stack/linked list problem. I wasn't lost, I was focused. One prompt from the interviewer would have changed everything. That's my point — an interviewer's job isn't just testing knowledge, it's assessing the whole person. And that starts with walking in looking for what a candidate brings, not reasons to reject them. Not saying everyone should pass. But give people a real chance to show their value.

What I feel is that experienced engineers often have a strong mental model of how things work. The fundamentals are there, but they operate more at a subconscious level — they instinctively know that “if this happens, then that will follow.” However, that doesn’t always translate into clearly explaining definitions or textbook concepts during an interview.

Now days , need not to look into more in coding , most important whatever we are using it is correct on that place or not, only this matters. Now AI is coding so more focus into undertsnding of code and concepts. Mostly focus on "Why we use it" and "what will we use in this case (scenario based)" not on "How we will implement it". If anyone is aware of concepts on why and what then it gives a positive sign. And it is not AI written , it is written by me only.

Without ABCD, there is no "Mango" As simple as that.

Many companies are brining back the offline interview culture. Pen and paper coding is one of the best methods to judge a candidate because you actually ask them to explain as well as dry run whatever they’ve written and its not just some compiler gambit

These days most devs are too focused on getting work done rather than understanding the code they are writing and then pushing it. Can you imagine I was questioned for writing interfaces.

See more comments

To view or add a comment, sign in

Explore content categories