I’m a Junior Developer – You Probably are Too
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?
I
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:
Context
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…
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)






Comments
Jammer Man replied on Tue, 2012/04/10 - 8:27am
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
Fabien Bergeret replied on Wed, 2012/04/11 - 6:34am
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