Programmers With These 3 Capabilities Will Be In the Highest Demand

Pen Magnet

Follow

Mar 1 · 7 min read

In the last decade, interview techniques are heavily redefined.

Previously, they revolved around boilerplate questions (often googled just before the interview). Since products and services turned into short-term projects, companies began to shift their selection space and redefined the interviews.

No one is talking about attrition rates, layoffs, and performance-based terminations

But how much have they succeeded is difficult to tell. While redefined interviews are already here, no one is talking about attrition rates, layoffs, and performance-based terminations. If the hiring strategies worked, how many of the hired developers ended up staying? How many of them ended up making a difference in the company?

And most importantly, how much of that difference was meaningful?

If the companies really want to embrace these challenges, they would try to correct things for the better. Here are the qualities they would seek in the future programmers:

#1: Write Specs:

Specifications in the time of the waterfall were quite verbose. Most of the whitespaces contained little useful information, including author, revision number, and revision date.

Many programmers literally despised the specs.

Agile dethroned documentation, just as the renaissance overthrew workable parts of the religion and replaced them with business-centric science.

The power to document went into the hands of Product Owners. A part of that power was delegated to UX designers. Coders became like functions they wrote: Accepting inputs from them and outputting the product that looked like those outputs under the most ideal conditions.

By the time bugs caught up with them, those coders claimed credit for fixing yet more tickets. Or, they were already replaced.

If you write a good readme during a coding assignment, chances of your interviewer choosing you over your opponent will surely inflate.

If writing specs (non-conforming to any standards) would be mandatory, they would have owned up the product feature from Day 1. First, they would put themselves in the shoes of the user, to understand his problem. Then, they would impersonate the founder, to solve that problem.

Writing specs not only involves specifications but also writing Readmes and release notes that can be easily understood by laymen customers. If you write a good readme during a coding assignment, chances of your interviewer choosing you over your opponent will surely inflate.

If someone is thinking about coders can’t write problem: Programming after all is a skill to express. That language is human-understandable. We are way beyond days of assembly. If it is a challenge, we must be able to embrace it. If we don’t, all software that we create (with its size reaching petabytes per day) will be unowned and will turn into a megalith with a grotesque structure.

#2: Express:

A program is written once but read multiple times.

— Uncle Bob

Writing is a form of expression. But how well is your program expressive? How well does it express its purpose? How will it benefit its future maintainers?

This is not just about sensible variable and function naming. Your program is a story, and as a programmer, you are the one who narrates it to the world.

Are your classes cohesive enough?

That will tell how do you bind related items under a common purpose of a class. For example, in a travel booking app, consider the following class:

class Booking {
   startDate: Date
   endDate: Date
   property: Hotel
   status: BookingStatus
   cancellationReason: String
}

The variable cancellationReason is tied with just one possible state of the booking (canceled) — why should it be part of the Booking class? It should belong to some other entity (Maybe BookingStatusChange class, which holds old + new BookingStatus objects, along with a timestamp, and a reason field that is generic enough to hold cancellation.)

Are your functions designed to operate on the same abstraction level?

This is a pretty high-level concept, but executed at a lower level. You need to be careful about it as you write every single line of code.

During a significant part of my career, I have copied code from StackOverflow. However, I must confess that when you do it, this is one thing you cannot do effectively. You need to practice it until you know.

Why? Because it requires one to classify every code statement and put it where it belongs.

Consider the following (syntactically incorrect) code:

function sampleFunction(fileName: String) {
    const fs = readFile(fileName)    if !validateFile(fs) {
       return []
    }    var byteArray = []    while (fs.bytes()) {
       // Do byte operation 1
       // Do byte operation 2
       // Do byte operation 3
    }
    return byteArray
}

This type of code is insanely widespread — it is even found in big tech quite frequently. One thing that it lacks is the same level of abstraction. The statements within the while loop deal with bytes, while the two statements before it deal with a file.

Why can’t there be a separate function parseFileBytes() that deals with the low-level byte madness of the while loop? Optionally, filehandle fs could also be passed to this function. That way, the entire function comes on the same abstraction level: It deals with filehandles only. The parseFileBytes(), on the other hand, deals with byte-level details.

Bonus: Both functions are separately testable.

function sampleFunction(fs: FileHandle) {
   if !validateFile(fs) {
      return []
   }
   return parseFileBytes(fs.bytes())
}function parseFileBytes(bytes: [Byte]) {
    while (bytes) {
       // Do byte operation 1
       // Do byte operation 2
       // Do byte operation 3
    }
    return byteArray
}

Some programmers may argue that involving a separate function call may result in a performance hit (depending upon the language). Some may also feel it is trivial.

A minute spent in refactoring saves hundreds of hours in debugging.

But if you consider the efforts of the debugger programmer, you will be able to justify the principle I just explained: Single Level of Abstraction. When the maintainer sees this function only deals with the file (instead of file + bytes), he/she can quickly decide to include/skip it during the debugging.

A minute of careful refactoring by an expressive programmer saves hundreds of hours in debugging.

#3: Zoom In:

During my early career hobby project, I had a junior colleague with whom I was designing a library booking website. The signup form had 6 fields. He had put validation on most of them. Some of them acted upon combinations of the fields. The total number of validations was 14!

I asked him to reconsider some of them. I argued that it was pretty bad UX. To that, he said: “Soon after we go live, they (1000 students) are going to register at once, on day 1 of the college term. If they put bad data, we will have to correct it from the back end. As for bad UX, everyone is going to need it. Who cares?”

“But you can spend some time on figuring out the real number of validations, refactor and deliver a better quality product.” I decided to go by the book.

To that, he said, “I would need to ask the librarian. His answers will take time. If we can’t deliver before the term start, it will be useless. In no time, he (the librarian) would be filling paper forms, and blaming us in front of the entire college staff.”

He had a point. While I never agreed with his half-cooked, validation-ridden UI, it forced me to think about how the website was going to be used in a live production environment.

It made me think about the average load and the spike statistics. It helped me think about the post-release data-migration possibilities. It helped me eliminate many nonsensical things and only focus on what was absolutely necessary.

Zooming in is a skill that is highly overlooked because it is rarely taught even in college, let alone online tutorials. In interviews, this trait comes under the Ownership company value (thinking long-term impact vs short-term utility). I have discussed it at length as part of my Senior Developer Interview eBook (50% off for the first 100 buyers)

Visionaries such as Steve Jobs are popular only because of Zooming in.

Your Zooming in capabilities is where interviewers try to see through the real You (as against your CV which was already in their mailboxes). It is this thing that sets you apart from other candidates. Without this, there is no talking about whether you worked on thing X for Y years.

Visionaries such as Steve Jobs are popular only because of this skill, but they earned it from outside the tech domain. It comes not by coding a thousand programs or solving the maximum number of LeetCode challenges. It comes with critical thinking skills.

Those skills are not really skills, but continuous activity, and an enjoyable one for those who truly care about the product they code.

That is what they mean by ownership in the interviews and the yearly performance reviews.

Conclusion:

With evolving AI, not all coders might become obsolete soon. But the level that they operate will be quite different from the one they are operating at right now.

These 3 capabilities will come in handy in setting apart a human coder vs a machine.