Software Developer without the theory is a bad candidate?

Question

I am Senior Java Developer with over 6 years experience. I have done Computer Science bachelors with C++ as the main language. Currently working in financial companies (Banks, Asset Managers etc.). I have been promoted to higher positions within the same company, worked as an architect for a new platform, created solution designs. Even started working on my own and faced front office directly to gather requirements and implement solutions for them, as I excelled working on my own.

Currently looking for new opportunities and any job that I apply, I can secure an interview. Most start with coding exercise, others with informal chat, which all of them I pass with flying colours, but all of them eventually have technical interview, where the Lead Developer would ask you Core Java questions (What is Java Memory Model etc.), which I fail to answer, as all my Java experience came just from working.

Does that make me a bad candidate? Is the theory really outweighs the practical side of the candidate?

Answer 1

Does that make me a bad candidate?

That would be up for the company to decide, but I can tell you why it would make you a bad candidate when I hire:

There is no fixed definition of what Junior/Intermediate/Senior means. Any company can define their own titles and meanings. But there are two definitions by which I go and which make sense in most contexts, not just software development:

• A junior needs help doing their job.
• An intermediate can do their own job.
• A senior can do their own job and help the others.

Or alternatively:

• A junior asks "how".
• An intermediate knows "how" and asks "why".
• A senior can explain "how" and "why".

By that definition (and they are not universal) you got stuck at intermediate. You never bothered to ask "why", never read a book about it or followed the links to the explanations. You settled for making it work. Which is not bad, producing working software is hard enough. But it's not senior level.

That is why I would not hire you as a senior software developer. With your experience, you might be a good team lead or project manager though. You do have extensive experience on the job and I don't want to deny that. But right now, you do not demonstrate you have what it takes to be a senior software developer. By my standards, and those are arbitrary and not relevant to your situation; but I guess by those company's standards as well.

So how to get to that level? Ask "why". The first thing I do when I learn a new language is crank up the compiler, linter, analyzer or whatever the toolkit offers to maximum. I want all the warnings. I want to know what I'm doing wrong in detail. I'm not content with the fact that my if and fors do work in that language, too. That is a given. That is the boring easy part. I do not only want to know how it works. All those tools, if they are good, will give you loads of information, why you should be doing this or not doing that. Because when you learn the "why"s, you will understand the problems and how to handle them best in that language.

Another really good test whether you know "why" or just "how" it works, try teaching it. A junior or apprentice maybe. Because they will ask you "why". And if all you can say is "because that's how it works", then you are not there yet. You are not senior level.

So if you want to get those jobs, learn it. The three languages I program in nowadays were not even existing when I graduated. Still, I can explain "why" in all three. (Although one is a web development framework and the explanation too often is "because it's a buggy piece of..., see this github issue"). With the years, new ideas and hardware will come along. I will adapt, I will learn and I will ask "how" and then "why" every time. You can do that, too. Go give it a try, don't stop at just being good enough to make it work, strive to get better than that.

Answer 2

Does that make me a bad candidate?

From what you state we can conclude that this makes you a bad candidate for those companies.

That is, if those companies are seeking someone that, besides being able to code, actually knows some theory and what's going on behind the scenes, then someone who lacks that knowledge would not be the best candidate (for those companies).

Surely, there could be companies that give more value to the hands-on experience of their candidates, and someone without theoretical knowledge of Java (but great hands-on knowledge) would be a good candidate for them.

My suggestion is that either seek companies that value more hands-on experience, or that you invest some time to read and build some theoretical knowledge of Java so you can be an even better candidate.

---

On a more blunt observation: It's precisely that theoretical knowledge that you describe that makes the difference between someone who only knows how to program and no background on what's happening behind the scenes and, for example, a Computer Science professional or a Computer Engineer (or whatever we are called now at the Uni), who actually knows what's behind the scenes and may have a deeper understanding of the language (and computing in general) that someone that "only" knows how to code.

Answer 3

I have to disagree with these answers so far.

Keep in mind that the people interviewing you will not usually disclose why you're being turned down. They may point to a wrong answer to a question, when pressed, but that is not necessarily the real reason. The real reason could be something far more subjective relating to their assessment of how your personality would fit within the org. This is especially true if you're getting past the resume, phone screens, and part of the interview.

To you, it may seem that everything is "flying colors" except for some silly technical question, but how can you really know that? In most interview situations successful candidates can and do "miss" some questions. Everybody has gaps in their knowledge, no one consistently gets "everything right".

Before ascribing these rejections to giving the wrong answer or no answer to some technical minutia, try to carefully examine all aspects of the interview process. Consider doing mock interviews with people you trust to get feedback about what might be the problem.

Answer 4

It takes more time to gain practical experience than to gain theoretical foundation. So in theory, experience should matter more. In practice, however, it's often the other way around. For example Amazon considers 3 years of experience equivalent to 1 year of education. Which means that a fresh grad is equivalent to an experienced software architect with 12 years of experience. Whether it's fair or not - does not matter.

Companies who value comp sci background or any deep technical knowledge usually pay more than those who value only practical experience. You will also have the luxury of working with some of the best quality code you have seen. And you will earn a lot more money. Check www.levels.fyi for more details. It's at least 2-3x what you typically get otherwise. A junior developer at FANG typically earns more than an architect at another company. If you can pass their interviews.

Theory is complicated, and it takes a lot of brain to learn, understand and be able to explain as if it's your own thoughts. But it does not take a lot of time. I would say get some online courses, spend a few weeks on it, and increase your job opportunities. At worse, you will get better at stuff you are already doing, so you might get promoted more often. Learning is always a win-win situation, so keep doing it.

Answer 5

There are undoubtedly working environments where it highly useful/necessary to know everything about the Java Memory Model or to have other theoretical knowledge. However I think that for the majority of companies where they make "run-of-the-mill" administrative software it really is not that important or useful. It is however the case that a lot of these companies think that what they do is unusually complicated and that only the best of the best rockstar software developers can be allowed to work there. I don't think you are bad developer because miss out on some theoretical knowledge. Unfortunately this opinion of mine doesn't change anything for job opportunities.

Answer 6

If you run into an interviewer who believes that theoretical knowledge is important, and you don’t have it, tough. You won’t get the job even if you are completely qualified for the actual job.

In practice, a company needs one person who can handle the difficult problems because you don’t run into them that often. And they need everyone to realise that a problem is difficult and ask for help if they are not sure they have a valid solution.

If they are looking for that one person, then you’re not it. Doesn’t mean you can’t do a good job. You can even be worth more than that one person with the theoretical knowledge if you are better at developing software.

Answer 7

"I am Senior Java Developer with over 6 years experience."

No, you are not. 5 years is BARELY not junior. To be a senior you need to be either very talented or have more AND....

...Senior is not about doing the same thing over and over and over again. It is about experience and a WIDE field of knowledge.

as all my Java experience came just from working.

Means you can have used the same crap style over and over. Been in 2 projects and doing quite menial work over and over. Never read a book about architecture. NOT what I would hire as senior developer - heck, with your explanation I would be very hard pressed to not rate you as Junior developer. At some point in all those years I would have expected you to step up and start reading some proper books.

A senior developer must be able to make decisions and guide other developers. The knowledge for this is not something you get JUST from work, ever. How can I expect you to improve the quality of the work done if your reference and all your knowledge is the work done?

I would suggest you start putting together a reading list of DEEP basics. Stuff you do not touch during your work. In depth things, stuff that is arcane and rarely used. Stuff that gives you a deeper understanding.

Here is something to think of about:

I have been promoted to higher positions within the same company, worked as an architect for a new platform, created solution designs. Even started working on my own and faced front office directly to gather requirements and implement solutions for them,

AS PER YOUR OWN WORDS - you may have done an awful job here without knowing it. And I am not joking. As per your own words, ALL your knowledge comes from work experience. So, without reading any in depth book, all your advice is based on EXISTING PATTERNS AND APPROACHES. Which MAY - or may not - be awfully bad. Your platform MAY be a copy of what you saw at work and may make people coming from a deeper background cringe. And I have been there and seen exactly that. So, I would have expected a decent set of books having bolstered what you see at work - not just copy/paste with ALL your knowledge (again, YOUR Words, not mine) coming from your work experience, without any external input. Again, I just finished reworking something for a customer in exactly that level. Actually better as they - while not reading books - copy/pasted code from random magazines, so they DID Have more input than just what was there. Noone ever considered long term implications, i.e., or the way they totally miss structured their API.

This gets quite obvious when you by your own words fail at questions like "What is Java Memory Model" - which is NOT what I would ask a SENIOR developer. I would not expect a junior developer to answer that, but anyone at the end of the junior cycle and aspiring to the next level (which is NOT senior) should better know a BASIC question like this. A senior developer better explains me how this correlates to cache sizes and how to handle performance issues on that level. And can then also argue whether or not a C# level struct/class approach is more efficient and why and how to avoid those pitfalls for Java. Yes, I would expect a SENIOR developer to also master 1-2 other area languages.