I feel that often the title "senior programmer/developer" is used to entice less-than-senior programmers into a company, while not paying them according to the title "senior" - after all they "don't know enough to justify it", is what the recruiter would tell them.

Maybe the same way that today there are in US food stores only medium and large eggs but never small ones.

Anyway I have been interviewed recently for several "Senior (Java) developer" positions and was annoyed to be asked in some of them only junior questions:

  • What is an interface?
  • What is an abstract class?
  • What is garbage collection?
  • What is dependency injection?
  • How to eliminate duplicates from a list?
  • How to traverse a tree?
  • Etc....

All of these are things that I knew before starting working with Java, or sometime during my first year with Java.

Where are the questions on what I learned during the last ten years?

Usually I was told by the interviewers that I did better than other candidates... which made me think "Really? What kind of people do you consider???"

But should such interviews make me feel that these positions would probably be too mediocre for someone who does not want to do conventional technological paper-pushing stuff (get a response, decorate it, and send it forward... yes, through a web service, yay...!)

Sometimes these jobs are in a salary range with a maximum that is a little lower than what I want. I may still go and talk to them:

  • If the recruiter convinces me that it's a great company that does interesting things.
  • If I think that they may see me and be willing to bump up their offer.

Should I run away from job offers I may get after such disheartening interviews?

closed as off-topic by gnat, Dawny33, user8365, mhoran_psprep, Dan Pichelman Jan 10 '16 at 16:26



  • 11
    I imagine those questions are more to see how you explain things, rather than testing your knowledge. – Joe Jan 9 '16 at 21:37
  • Yes you are too good for them - run – paparazzo Jan 9 '16 at 22:06
  • 6
    "If I think that they may see me and be willing to bump up their offer." This is a huge, huge fallacy. It may work in a few cases where the company can use someone with more experience (hence deserving of a higher wage), but in the vast majority of applications you're just wasting everyone's time. They're looking for a specific profile and have a specific budget. Aside from that, people can be in "senior" positions after only a few years, so my bet is that you're either applying for the wrong jobs or are getting too worked up over questions designed to weed out inexperienced candidates. – Lilienthal Jan 9 '16 at 22:14
  • I like to ask X vs Y questions in interviews (where both X and y are good sometimes). You can use several of those questions as jumping off points for those sorts of answers. Interface vs abstract class. gc vs reference counting vs manual memory management. Dependancy injection vs service locator vs new etc – Richard Tingle Jan 10 '16 at 8:52
  • 3
    Relax. They're just filtering out the Programmers who can't program – Dan Pichelman Jan 10 '16 at 16:25

Senior Developer is just a couple of words, they can mean anything dependent on what the company wants them to mean. Disregard them except as a general guideline and focus on what is being paid. That is the true test of what they're looking for.

I have worked for a company where everyone seemed to be a senior developer or senior engineer except the cleaning ladies and the drivers.

  • 2
    At my last firm there were people with only 4 years total experience and no grasp of interfaces or basic skills like repository management being called lead and senior developers. Some people just get these roles due to staff turnover and automatic promotion rather then actual skill and ability. – Stormy Jan 10 '16 at 11:05
  • @Stormy it happens in many places, I hired (and soon fired) a guy with 11 years experience at top level in a govt department on his resume. The chap didn't actually know how to do ANYTHING except make excuses and try and delegate everything to others. – Kilisi Jan 11 '16 at 0:42
  • 1
    I have chosen it as the answer for "Disregard them except as a general guideline and focus on what is being paid. That is the true test of what they're looking for." – rapt Jan 13 '16 at 15:56

Two things here.

  1. You'd be surprised how many "senior" developers can't do even the basics. My last big round of development recruitment saw maybe 75% of the pool fail at the first real interview, and we started doing fizz buzz, not because it was a great positive indicator, but it caught the many who couldn't even do that. Many senior devs get that way by being there for a number of years, but haven't progressed in their skills, so these questions are necessary.
  2. Having said that, what is a "senior" anyway? I wouldn't automatically say tech skills are the difference from a junior role, but what I would expect are the more soft skills: being able to manage their (and maybe a junior's) time; being able to see through a task/story with the business from beginning to end and deal with (or escalate) issues as appropriate; and being able to mentor a junior in the above.

What I would also expect is a different level of discussion around the questions you mention, maybe some more opinions on why they're good/bad/ugly and leading into war stories that give me confidence of their skills rather than a textbook answer.

  • 3
    Point 1 is absolutely impressive. I've seen people with 10+ years of experience unable to make a SQL request with a simple join and a signle AND, and that, after one week trying to explain them. A more detailed entry : blog.codinghorror.com/why-cant-programmers-program – gazzz0x2z Jan 10 '16 at 9:24
  • 1
    @gazzz0x2z, I have seen that in people applying for database programming specialists not just ones where it was a small portion of the coding required. – HLGEM Jan 10 '16 at 20:26
  • Consider also that managers doing the interviewing may be away from programming for several years and thus can't actually ask the more complex questions because they are no longer sure of the answers. Also consider that when you talk about your own accomplishments is the time to discuss that in depth knowledge to show that you have more than the lowest skill level. – HLGEM Jan 10 '16 at 20:28
  • I'm always amazed at the results of that FizzBuzz test. My gut says "that's just one bad round" and then I find out nope, it's pretty much industry standard to have 1/4 or 1/5 be able to pass it... and it makes me sad... – corsiKa Jan 11 '16 at 7:09

Those aren't really "Java questions", those are "OOP questions" and "any programming language questions". So if you mean that you knew the answers to these questions from working with some other OOP language, then, well, good for you.

I think questions like that, rather than questions about details of Java syntax or API, are a good sign. It hints that the company realizes that the mark of a good software developer is that he understands concepts that transcend specific languages. I'd be concerned if a company asked me questions like, "what is the third parameter to the foo function in the bar class". If I don't remember, I can look it up in a minute or two. But if I don't know what garbage collection is, that's a long story.

Give the interviewer some slack. Coming up with interview questions is a tricky business. Is your problem that the questions are too easy? If so, well, good for you. Those questions would stump a good percentage of developers I've run into. If you can answer them all correctly, that probably puts you in at least the top 50%, maybe better. You want questions that are hard enough that you can distinguish the candidates, but unless you're giving them a 20-page test, you don't want to eliminate a candidate because he didn't know the answer to one hard question. Maybe if you'd asked ten more he would have gotten them all. You can tell a lot not just from the answer, but from how the candidate answers. Obviously if he has no idea that's a minus. But if he rattles off a textbook definition, that may indicate that he knows the buzz-words but doesn't really know how it all works. (I once got burned when I hired a guy who was able to recite all sorts of technical terms and definitions in the interview, but who turned out not to be able to complete the simplest tasks. Yeah, he could name all the frame works and languages and products out there, but when we asked him to write a screen with two input fields and save it to a database, he didn't have a clue.) I'm impressed when someone can explain a concept clearly and confidently.

Oh, and asking for obscure facts seems pretty pointless to me. Years ago an interviewer asked me what data was in a Unix inode. I happened to know -- indeed I knew better than him, he thought the file name was in an inode -- but if I hadn't known, so what? I only knew because I happened to read about it one day. I don't think I've ever used that knowledge when writing a program.
