Doug Rathbone is a software architect working in Ad land. He is passionate about software design and automation, and regularly contributes to a number of industry sites on these topics. Douglas is a DZone MVB and is not an employee of DZone and has posted 62 posts at DZone. You can read more from them at their website. View Full User Profile

I’m a Junior Developer – You Probably are Too

  • submit to reddit

Part of my job is hiring people to build websites for advertising clients. Most of the things that we build don’t compete with brain surgery for complexity, but as anyone knows when working in software, having skilled people working on simple problems often leads to scalable, well built solutions – I hire accordingly. The problem is how do you define "skilled" and does it even have meaning in software out of the context of a company’s needs?

imageI have been quite lucky that early in my career I realised that no matter how skilled I got at my craft, there would always be someone on a whole other level. Crossing developers with egos aside, attending conferences, user groups and development events is one of the easiest ways to reset your expectations surrounding skill level, and find this out early.

I am a Junior Programmer

I have been developing software since I was 10. Commercially since I was 14 and 9 months (this is the legal age in Australia to work). I have had a go at creating many different types of software in many different programming languages, more recently on the Microsoft stack.

I’ve lead teams, travelled for work, had high risk, low risk, sexy, boring, you name it programming jobs over the years.

All this has made one thing very clear to me:

I know nothing.

Our industry is so vast, and different technologies and methodologies are so numerous that this single piece of information should go with you everywhere you travel.

How about you?

When applying this to hiring though, things are never as clear. Nowhere is this more evident than working in a Sydney advertising agency, and being tasked with hiring web developers.

You see in the land of web development in Sydney, the age of the Brogrammer/Coder is upon us.

Recently I have been tasked with hiring a new senior technical member of staff. I literally did 30 or more phone interviews, many-many in person interviews and the experience left me feeling quite dis-enchanted with the Sydney .Net web world. The amount of 10+ year experience huge salary swinging web developers I saw who couldn't:

  • Describe how POST data was submitted to a server by a browser.
  • Explain a number of HTTP status codes (except maybe 404 and 500).
  • Explain SOLID or name a design pattern.
  • Explain ways to improve a pages load speed or user experience.

You may think I am being being aggressive in suggesting this, but if you can’t answer the questions above there are a lot of people who wouldn’t think of you as a Senior Web Developer (maybe we can rule SOLID out… but you understand my point). However what do you call yourself if you have been building websites for 10 years in ASP.Net (or PHP, or Perl, or anything…) and you need a title?

This got me thinking though: how do you define seniority or skill in Software Engineering terms. Especially when hiring.

So many people can have simple roles for long periods of time, where they aren’t necessarily exposed to new principles or changes in their industry – do these people deserve high 6 figure salaries and “Senior” or “Architect” in their job titles?

This is where I think it all comes down to a single word:


If you have been building applications, websites, or *whatever* for many many years, you would hope you would have become considerably good at it. This doesn’t make you a senior developer, and this I think often gets lost on most of our ilk. It does make you good at what you have been doing.

But my view on people compared to your view on a candidate and their skills might be totally different – because I am totally blinded by the context for which I need from my new team member. My definition of senior will be totally different from that of someone hiring at a place that builds landing systems for spacecraft; or someone working on small business accounting packages.

In my hiring case, I was looking for someone who had a fair bit of experience building websites in ASP.Net and c# among other things. Not someone to build the next Google. However our industry only thinks of people in terms. “Junior ASP.Net developer”, “Senior Ruby programmer”,”Mid level PHP developer”. I don’t think this describes people’s experience or knowledge levels well enough.

Usually this equates to someone who is new, has been around for a while, or is an “old salt” at whatever they were doing – maybe building “Hello World” websites over and over… Who knows?

Maybe it’s time to rewrite how we describe people in our industry. Something similar to Scott Hanselman’s use of “FizzBin” in technical support calls might just do…

Published at DZone with permission of Douglas Rathbone, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Jammer Man replied on Tue, 2012/04/10 - 8:27am

SOLID?  Aren't you impressed with yourself.  I guess I would have to ask the question: "Why would anyone want to work with/for you?"

Chuck Dillon replied on Tue, 2012/04/10 - 10:21am

Consider that skill and encyclopedic fact storage are two different things.  What you know and your skill level are two different things.  It seems to me that you are focused on facts and ignoring what brings value to a team.

Your description of your interview is unrelated to skill.  You, self described as knowing nothing, are evaluating others on facts when you need skills.   If you are hiring a full time permanent person to work in a discipline that is highly dynamic why focus on facts that will be irrelevant before they get a five years of service recognition scrunchy ball?

Skilled SEs (engineers in general) work within the problem space they are given and get stuff done.  One of their primary characteristics is that they can climb any learning curve in their area of expertise and they can climb faster than lesser skilled SEs.  They are highly adaptive and so often are not the people who can quote language specs and such.

Rather than try to find someone you are confident is atop the learning curves in your domain, consider looking for someone who has verifiable accomplishments and a verifiable aptitude for scaling learning curves.  For senior level positions look for leadership qualities.

If all you want is someone to fit into a cookie cutter slot, hire a consultant who fits your slot.

Arjay Nacion replied on Tue, 2012/04/10 - 11:00am

A good programmer is not measured by his capability to answer those technical questions but more on how he knows how to apply fundamental knowledge in his work.. for example even if you know how POST works, design patterns etc... if you lack the skills to apply the right algorithm to a problem, then you still have a long way to go.. Algorithms are one of the important foundations for a programmer.. It is a tool for providing a solution which does not only work.. but is also a solution that is correct, efficient and would stand the tests of time.. 

Anyone can create solutions that work.. but few can create the "RIGHT" solutions. 

Stephane Vaucher replied on Tue, 2012/04/10 - 7:35pm

@Chuck - Honestly, if you've been working on web apps for 10+ yrs and don't know how a POST works or some HTTP codes, then you are not interested in your problem space. That is a significant problem.

Fabien Bergeret replied on Wed, 2012/04/11 - 6:34am

I know some people that I've interviewed that would have been able to aswer your questions in a blink. However, I didn't hire them. I have more than 10 years of experience in creating J2EE Intranet applications. I consider myself as a expert at it. And I no longer know how POST parameters are sent ; and I don't know what SOLID refer to. And you know what? It's not an issue

Jose Maria Arranz replied on Wed, 2012/04/11 - 9:08am in response to: Chuck Dillon

Masterly comment Chuck.



Chuck Dillon replied on Wed, 2012/04/11 - 12:01pm in response to: Stephane Vaucher

A couple points here.

Interest - I've been a professional SE since 1978.  My interests are golfing, bowling, my family, watching baseball and the like.  No software technology or trend or author or blog or what-have-you is on my list of interests.  I get paid to do software I don't "live it".  What I know about the underlying esoteric details of technologies I apply is a function of the collective need-to-know I've encountered, period.

POST/HTTP code - I don't do web apps but I know that these are foundation technologies that few of today's developers use directly.  Those that do know the esoteric details about that layer of technology.  Those that use higher level technologies don't have a need to know.  If/when they need to know there should be no problem in them acquiring that knowledge.  There's no rocket science here.  Answering your questions correctly requires only the experience of reading "HTTP for dummies" which any middle school student can do.

Problem space - Web apps, and technologies are not problem spaces.  They are technologies, tools to be applied to problem spaces by people who engineer software solutions.

I don't mean to be disrespectful or argumentative.  My primary point here is that skills are persistent while technologies and tools come and go.  If I had become religious about developing FORTRAN on CDC mainframes in the early 1980's my career would have been pretty damn unfullfilling.  Don't expect and coerce young developers to marry the latest technologies or any technology.  Expect them to have skills and adaptability.



Paul Russel replied on Sun, 2012/06/10 - 9:31am

Generally speaking job titles are a way to compensate employees using non-monetary means.  Believe it or not many people value titles as much as they do a raise.  That's why many companies are suffering from VP inflation where seemingly 50% of employees are VP of something.  It costs nothing to hand out a title.  It has value to the employee.  Companies exist to make money.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.