Introduction

At some point in my programming career I’ve been named a Senior Software Developer. Then customers started asking me to help interview their new hires. Many of them applying for a similar senior role. What does this term mean? How did these interrogations go?

TL;DR

More than often, not very well. Sturgeon’s Law describes exactly how bad.

This article is a slightly ironic look at realities of hiring in IT. True story based on own experiences, discussing a controversial issue of programmer’s rank and seniority, with lots of rants and code samples for entertainment. If you have thoughts, ideas, comments or you’d like to share your own experiences, I’d love to hear about it!

What makes one a Senior Software Developer

I’m fully aware that I’m stirring up a hornets’ nest ;-) I might be even accused of patronizing or being an elitist dinosaur. That’s okay, I’ve been called worse things for lesser sins.

Before I continue, let’s see what people wiser than me think about it. For example, my favourite news outlet “The Guardian” proposes this approach:

At the Guardian we have a general role of software developer which we recently divided into five sub-groupings: associate software developer, software developer, senior developer, lead developer and principal developer […]

A senior developer has an acknowledged area of expertise, mentors and coaches others on their team, understands the goals of the team, particularly in terms of outcomes or metrics, has an idea on how the team can deliver software more effectively, is a strong individual contributor and either talks publicly or is involved in the wider software community outside the organisation […]

We have non-senior software developers who are tech leads and the two things are not synonymous.

What to Expect from a Senior Developer in year 2020

Here’s a simple whiteboard question asked many times during my tenure at a certain major bank, where I was employed as full-stack developer building software with Angular, Redux, and NodeJS + MongoDB back-end.

We were regularly looking for senior developers. Our institution required the software to run on ancient browsers. We thought that understanding what polyfill is and being able to write one is an important skill of our future senior team member, so we asked:

1. Tell us what Array.filter() does.
2. Tell us what a polyfill is.
3. Imagine a browser where Array.filter() does not exist. Propose a polyfill for it. Pseudo-code on a whiteboard will do.

Initially, we’d go straight to point 3. Then, we realized that for most candidates this sounds like Klingon. We wanted to be nice, so we decided to build tension gradually by asking it in three steps of increasing difficulty.

We didn’t expect perfect JavaScript. Coding while strangers watch you is inhumane and should be banned by Geneva convention. I hate it as much as I hate kiwi fruit. Pseudo-code is usually enough to get a grasp of someone’s knowledge and abilities.

Here’s what we’ve learned:

1. 25% of candidates were unable to explain in plain language what Array.filter does. Many of those who did wouldn’t know what Array.filter returns if no elements match the condition. Some would say nothing. Shhh! Don’t say that loud, otherwise it reaches the ECMAScript committee, and soon we have another one to the already confusing null and undefined ;-)
2. Majority won’t make it past question 2.
3. One single candidate in nearly 20 interviews during the course of 2 years proposed a polyfill that would do. Many haven’t even reached the point of wiring up a polyfill. They’d reboot spontaneously on attempt to invent a filter function. In one case a candidate started with for (var i=0; i<100; i++) then froze. I’d at least declare an empty function to buy myself some thinking time! We waited a while, then asked: why 100? There was silence in the air, and we could hear Earth rotate.

Here’s what we’d be happy to hear:

1. Function Array.filter returns those elements of an array, which match the specified condition.
2. A polyfill is code which simulates modern JavaScript features missing in older browsers.

Pseudo-code proposal:

    function filter(array, condition) {
      result = []
      for (element of array)
        if condition(element)
          result.push(element)
      return result
    }

    if (Array does not have filter function)
      Array.filter = filter

Real-code proposal. We haven’t asked for it but if proposed, hire the guy immediately before someone else does:

    function filter (array, condition) {
      if (!array) return
      var result = []
      for (var i=0; i<array.length; i++) {
        var item = array[i]
        if (!condition || condition(item)) {
          result.push(item)
        }
      }
      return result
    }

    Array.prototype.filter = filter

Someone please tell me that I’m not too demanding for Senior Stack Overflow Experts ;-)

But, but… what about Years of Experience !?

In the old days our level of experience was measured in KLOCs. It went into oblivion, but only to be replaced by an equally inaccurate measure of Years of Experience.

I’ve seen developers with decades of “experience” who were bad to the point of being dangerous. Then it gets worse. 10 years at a major investment bank must mean something, right? This is often used as a sole reason for promotion. Bad programmers end up ruling over and ruining teams and whole IT departments because they have the necessary “years of experience”.

10 years of JavaScript is just as good of an indicator of me being a senior programmer as 10 years jail time for armed robbery is an indicator of me being a law professor.

In private, we ridicule the idea, like in this humorous old piece titled “What if Carpenters were hired like Programmers”:

Interviewer: So… have you worked much with walnut?
Carpenter: Sure, walnut, pine, oak, mahogony – you name it.
Interviewer: But how many years of walnut do you have?

But in the end, we keep playing this game. We come ourselves to another interview and we declare. Yes, I am a senior software developer, for I have worked with Angular since I was born. Why? Because that’s what they all want to hear!

Back to The Guardian’s definition

The Guardian’s concise definition has deep consequences. To mentor others in an area of expertise, one must possess more than a working level of understanding. One must know “why”, and not just “how”.

Using Angular as an example: to mentor and contribute, one must not just know how to use Angular to build even a complex application. One must also understand why Angular was built and how it works. One must know a wide variety of patterns and architectures of applications, and how and when to execute these with Angular. Only then we’re able to make juniors believe that certain things are better done this and not the other way. Otherwise we’re just being annoying if not bossy.

Finally, one must natively speak the languages of Angular platform - JavaScript and TypeScript. Not so much to memorize the syntax or know all methods of WeakSet class. But to master the style, the structure, paradigms, and capabilities of a language. It’s about being able to tell an entire story in it. Because writing software is an exercise in elaborate and consistent story telling, more than assembling formulas and patterns. As E.W.Dijkstra, one of founding fathers of computer science, has noted 45 years ago:

Besides a mathematical inclination, an exceptionally good mastery of one’s native tongue is the most vital asset of a competent programmer. Edsger W.Dijkstra in “How do we tell truths that might hurt?”, EWD498, 1975

Another real-life example

This one is about async code and promises, my favourite.

You have three functions, which are all asynchronous:

loadReport(id) which fetches definition of a report
runReport(report) which runs the report and returns a path to PDF output file
sendReport(filePath) which mails the file to subscribers and returns true if succeeded

Write code that executes a report using these three functions and shows alert if everything went well. Each of these functions can throw an exception. How would you handle it?

What happens next deserves an IT Crowd episode. If it was just one promise-returning function to call, all is well. With three functions hell breaks loose.

1. Some will just give up at this point.
2. Some will somehow end up with a callback hell, unaware that functions returning promises can be chained.
3. No candidate would propose using await to simplify things unless gently told to do so. There seems to be no mental link between async/await and promises.
4. The question about handling errors has been responded correctly just once.

In 2020 it seems perfectly normal that Senior JavaScript Developer doesn’t know how promises work.

Funny thing is that we’ve already written half your code! Just add .then() prefix where it’s missing and you’re done. Throw in a .catch() and we hire you the next minute:

  loadReport(id)
  .then(report => runReport(report))
  .then(outputPath => sendReport(outputPath))
  .then(completed => alert(completed ? 'Done!' : 'Bad monkey!'))
  .catch(error => alert(error.message))

If you also said: But hey, why not make it simpler with async/await?:

  try {
    const report = await loadReport(id)
    const outputPath = await runReport(report)
    const completed = await sendReport(outputPath)
    alert(completed ? 'Done!' : 'Bad monkey!')
  } catch (error) {
    alert(error.message)
  }

we’d invite you for a pint right after the interview.

The Deep Knowledge

Frequent references by me to the Great Old Ones such as E.W.Dijkstra are intentional. My message is: a senior software developer knows these masters of computer science and learns from them first, before going to Stack Overflow.

To use an analogy: how could one claim being an expert in Russian culture and language, without having studied the works of Dostoyevski, Tolstoy, Pushkin, Akhmatova, Solzhenitsyn, Bulgakov, Strugatsky brothers - to name just a few. Without studying them, one could call himself an “aspiring enthusiast of Russia” at best. Watching “Russia Today” on YouTube, even 24/7, simply won’t cut it.

And we all know that, as we demand proper expertise from our doctors, car mechanics, lawyers, architects and constructors. We’d be shocked if a doctor told us that he actually never studied an atlas of anatomy, but they’re very good at googling stuff when necessary.

Yet somehow our own profession is exempt from such rigid requirements for knowledge and expertise ;-)

Technologies and frameworks come and go, nowadays quicker than ever. But foundations of computer science are well established and will remain valid for generations. Believe it or not but functional programming hasn’t been invented in 2015 by Facebook engineers working on React. It’s nearly as old as the man writing these words. React is a brilliant application of an old and well studied paradigm in the realm of modern front-end development. Finishing that boring LISP studybook while at university would’ve probably made you a better React developer today!

Yet… It rarely happens during those dreaded interviews that our Senior Software Developer would be aware of the “Gang of Four” book. Or familiar with Martin Fowler’s contributions to application architectures. Or admitted having spent hours in a cold bath going through “JavaScript: The Good Parts” by Douglas Crockford. Or knew who E.W.Dijkstra was and have read some of his madly entertaining writings, all publicly available in the classy and vintage E.W.Dijkstra Archive.

True, one cannot possibly know everything, past and present. But… could we at least try? Unfortunately for some Senior Software Developers their knowledge mainly consists of tricks and recipes acquired through (fully undisputed) years of experience. Finally, we’re being killed by a beast of our own making - why bother studying if one can find it all on Stack Overflow. Stanisław Lem once said:

Nobody reads anything. If they do read, they don’t understand it. If they do understand, they don’t remember it for long.”

The Consequences of a Botched Interview?

Well… There are none. Senior Stack Overflow Developers are undeterred and keep coming to interviews in large numbers. Why?

Two words - no feedback.

In my 20+ years of experience as an interviewee I cannot remember a single time when I’d have received genuine feedback after being rejected. I’m usually left in dark, resorting to conspiracy theories: The manager was a racist sociopath who didn’t like my jokes spoken with a rough Polish accent. Questions were deliberately arbitrary, designed to increase my suffering which made them pathetic legacy Java developers feel superior.

I’m so glad to hear The Guardian say this:

When recruiting though we need to explain what a senior developer is, not just to ourselves, but to people outside the organisation. Sometimes we also have the difficult job of explaining to people who currently have the title of “senior developer” why we don’t think they are a senior developer here at the Guardian.

I don’t think it’s too much to ask. I would appreciate my interviewer to spend an additional 15 minutes on honest critique, after I’ve often spent days, unpaid, using my best efforts to sell my skills.

A few years ago, I applied for an architect position in a small but interesting Irish government institution. Two screening calls followed by a face-to-face interview with a technical lead and a manager. It went smooth: no reverse binary trees, just an informed discussion amongst professionals. I didn’t get the job. That’s fine. But until today I have no clue what I didn’t have what they needed. I’d be thrilled to hear more, even it was harsh critique. Maybe I’d learn which topics I should study more, to qualify for similar jobs in the future. Maybe I’d discover that they expected things which I find boring and tedious, so it’s good that I haven’t gotten the job and I won’t waste people’s time when a similar job comes in future?

Employers, recruiters would do everyone a great favor by giving proper feedback on negative outcomes of interviews. It would be a real assessment of our skills and help us be realistic with our claims. It would bring more efficiency to hiring process and reduce disappointment for you and your customers. Otherwise, we keep applying for jobs for which we simply aren’t yet qualified.

Finally, believe me, you don’t want to have just seniors on your team. A team made of only senior developers is as orderly as a horde of cats instructed to march in columns of four, with a drummer cat at the front and trumpets at the rear-guard. Good luck achieving that. You need a good mix of people assigned to tasks they’re best skilled and efficient at. Having figured out how to detect a senior, now please don’t be shy of advertising for “intermediate” or “junior” developers to fill in the other half of the team. There’s no shame in it, and it would immensely help the juniors feel more confident during interviews ;-) They’d be relieved that they no longer have to pretend to be more qualified than they are.

Summary

During my career, I’ve had enormous pleasure of working with many brilliant software developers coming from all backgrounds, languages, and cultures. It’s a humbling and fascinating experience to meet a person who’s sometimes many years of career younger than you and yet they blow your mind with fresh vision, thorough understanding, and mastery of technology.

But it is never a given, never just a result of “years of experience”. All these great people have taken enormous and conscious effort to learn and understand the deeper reality of software development. They are The True Senior Software Developers. We should be careful throwing this label so easily at everybody and ourselves, if only from respect for those who do deserve it. We should not be afraid of telling those who honestly aspire to be a senior software developer, when they are not there yet. Then we must take our best effort to help them get there!