Hiring a good software engineer is tricky

It is always a risk for a company as much as it is for the individual to form that employer to employee relationship. There are nuances for hiring developers, and understanding the type of developer you are looking to get.

I wrote before about the intangible skills that are difficult to pin down, but this discussion will mostly focus on the technical skills. A software engineer, can be categorized and weighed based on three major components. The individual has technical ability, hard, more tangible (measurable) skills as you will, then communication and collaboration ability, soft skills, and the more intangible (difficult to measure) skills, for example the ability to learn a lot of new things quickly.

Focusing on the technical ability, there are some things immediately of note. A person can typically do well enough on a phone screen to get in the door, but be prepared for some interesting challenges.

Expect a next step, or one that comes soon thereafter, to include a highly technical interview. If a company is doing it right, they are not giving you a code test. Code tests are antiquated and a bad read of technical aptitude. My experience has taught me that you can ask a couple of simple questions about logic to understand how a person thinks and how a person conveys knowledge. An individual’s answers will give you enough to know if the person can at the very least be a programmer, but we look for so much more.

The best technical interviews are organic. In our case, typically a team of a few technical leaders go into a room and ask questions about experience. Then they hone in on the explanations, filter through the answers, and shake out whether you actually know what you are talking about. The best advice for this process is: Do your homework. Look at the general job description, read between the lines, and take the time to actually go and learn what they are looking to get from you. If you do not know a term, research it. Look up the company, understand the domain a little more, etc.

So I have had the opportunity to get feedback on the hiring processes for software engineers from interviewees and people in general looking for work.

Some advice for any software engineer with existing experience who is looking to change jobs or get back into the market:

If walking in the door of a software company, and billing yourself as a person with software engineering experience, you better well take the time to look at the technology stacks, learn them enough to speak to them, and do not make excuses for not having taken the time to do so. If you are an experienced developer, you already have strengths. Take the time to fill the gaps where you do not make the cut so that when you walk through those doors, you bring the best version of you. Look at the list of abilities and technical skills a company has on a job posting and dive deep into everything you do not know and take the time to really learn and speak to them.

I interviewed many software engineers for senior and principal level development positions who can only speak to older languages, or older language versions. If you step out of the software engineering job market for any length of time, it is not up to a company to train you to learn modern languages or language versions, it is up to you. If you are coming back into the fold, you have to modernize your skillset.

A big reason for this is that when you are coming in with existing business development experience you expect a higher pay than someone else who is coming out of college. You must justify that differential and separate yourself from your competition. The way to do that is to take the time to beef up your skillset and make yourself technically relevant to the market where you want to work.

Not just the technology changed over time. Many companies changed the processes and approaches with the way they do business. Many technology companies no longer look for “heads down” developers, instead they want your head up. They want someone who can work on a team, mentor, lead, and grow with a team. When we are talking about a senior and principal level engineer, we are looking for someone who is a leader, leaves that ego at the door, and understands that the measure of success is that of the team and company and not of the self. A big part of that expectation lies in the need to take ownership of your knowledge and skills without being paid to do so.

If you present yourself as someone who has been out of the fold for a while, but has taken the time to modernize a skillset to great depth, you will set yourself apart. It is unbelievable how many engineers do not take the steps to modernize what they know and how to apply it. I truly look forward to meeting someone who considers this advice.

Now for the trickier one.

Younger, straight “out of school” software engineers bring a fresh look and perspective into the industry. We are not always looking for someone who has a formal education in computer science. We are looking for someone who can do the technical part of the job, understands the concepts, learns quickly, and gets along with the people already in the company.

I have seen an interviewee walk in a door, possess all the ripe potential and even with the capacity to do logic and code, and the person does not have a good enough technical background that we will have to do a lot of extra work bringing them up to speed. At the end of it all, the technical background the person possesses is not their fault, because the person went through some sort of technical education that should prepare them for the modern technology market. It did not, and companies cannot tell you that to your face. Who wants to tell someone you wasted two to three thousand dollars on a bad educational experience? It might set a dangerous precedent (from a HR perspective) to do so, and I wish we could.

These educational programs are either ignorant or financially predatory, as the students coming out of them do not have enough marketable, modern programming skills to compete properly with their peers from other schools and programs of similar cost, but greater value. The best way to address this issue is for these schools and programs to actually reach out to hiring companies, and vice versa, to establish a modern curriculum around the processes, skills, and tools, readily being used in the wider market.

I applied a number of years ago to a college graduate program for a PhD in Computer Science. I was accepted into the program. They had one, and only one, professor on staff who knew C#. This inherently was not a big deal, but I asked about submitting some C# code for a technical assessment (required of the school to assess my coding background). My question was outright rejected, including a snarky answer about C#. I have spent a great deal of my career in the .Net code stack, and it is not a big deal to me to use another language. I love (LOVE) JavaScript.

What I experienced is an academic bias against C#, because of some perception of Microsoft’s technology stack in this particular institution being very negative. The abject rejection of any programming language by someone with a PhD in Computer Science baffles me. I can look at code in almost any language, and with a little time, figure it out. I did not continue a relationship with that institution or program. So why tell this story here?

Many boot camps, colleges, and programs that work within the technology industry do so based upon academic perception without a good gauge of the business application behind those technology stacks. It is easy to focus on an area of technology and stifle the potential marketability of someone transitioning from academic to business programming. Some schools do an amazing job of keeping their finger on the pulse and trends of the technology market, but many do not.

I can immediately gauge someone with education or training from a specific school or program because of my experiences with interviewing others who graduated from those same programs. After a while, you just know ahead of time that someone is not positioned with an equal educational or training experience as another person. This is frustrating and infuriating to see happen.

So the TLDR; version of this: You can set yourself up for failure. Choosing the wrong development boot camp, degree, or program, can inherently cripple your opportunities. Not all educational programs are equal. My best advice for finding an education in computer science, web development, etc., is to look at the jobs and see if the job descriptions match with the curriculum in any way, by a factor of one or more. Assign points to things that match, and the more points you end up with is likely the best place to go. This system might help a lot in just about any weighing of academic programs, but is especially relevant to the fast changing world of software engineering.

A software engineer can also be self-taught, whether new or experienced. I find self-taught engineers to come in one of a few flavors. Most have a high internal motivation that is especially good for fast learning, but this is not a reflection of work ethic, ego, or how well a person actually does on a team. Many self-taught engineers are a riskier investment for a company, most often because they do not have a good mentoring program established to professionally grow someone who needs it.

While technical ability is only one component of a developer, it is the foundation for doing the job. Without it, there is no developer. Invest the proper time and energy into that part of your career, and the likelihood of your personal and professional growth with it may benefit you for years to come.

Thank you for reading.