The Dysfunctional State of Tech Hiring

Image by Parveender Lamba from Pixabay

There are so many tech companies hiring, but why is it so hard to hire or find a job in the tech industry? The major problems are a computer science degree does not prepare people enough, the interview process is all over the place, and companies do not want to spend a significant amount of time for training. Being part of a hiring committee for four years, I have found that hiring a software engineer is a difficult task because it’s rare to see an ideal candidate or sometimes even a candidate that fulfills all of the minimum requirements.

With a lack of specialization degrees or certifications in the software world, each tech company creates its own “entrance exams” interviews for potential software engineers. The typical technical interview consists of one to three phone interviews and an on-site interview of between four to seven interviewers to find the ideal candidate. Interviewers will ask about computer science fundamentals, domain-specific questions, behavioral questions, and give a coding test to assess a person’s current skills and their growth potential.

Skills and Knowledge

As I have found out, a computer science degree is just a checkbox because it’s a “you must be this tall to ride” kind of requirement that could be bypassed by boot camps and prior work experience. Why isn’t a degree in computer science highly prized? Technology is changing faster than universities can keep up so they will teach the general fundamentals but not dive deeply into specialized knowledge that tech companies want. Who would have been able to predict cryptography would be an attractive skill to have because of bitcoin? Code boot camps are a route that teaches specialized knowledge such as web development, cryptography with blockchain, machine learning, and more. They often don’t teach general computer science fundamentals, but these engineers are good enough for some companies.

The typical subject to ask is domain knowledge related to your tech stack, but the fallacy is testing only within the tech stack. Companies expect engineers to know the programming language they are using, but the university courses and code boot camps commonly teach Python, Javascript, and Java languages. This requirement makes it more challenging to find junior engineers and many companies are moving away from hiring junior engineers all together. For senior engineers, pivoting between the different specializations within the software world is quite tricky because of x amount of years in the programming language requirement.

The popularity of programming languages will change over time also. Github shows the current trend of programming languages:

The top five are Javascript, Java, Python, PHP, and C++. Perl used to be popular, but it’s not even in the top 10 anymore. There’s also Ruby that used to be popular but has fallen quite a bit. Then there are new emerging languages like Go, which has been getting popular recently as many companies are adopting it.

A good software engineer can learn another programming language over time because these languages have very similar basic concepts to each other like loops, variables, or even assigning value. It’s mostly learning the syntax, the key differences, and best practices of a specific language.

A take-home coding assignment is usually given before an on-site interview to assess the candidate’s coding ability and weed out people who don’t want to put in the time. This method works for a while, but eventually, someone will post the coding assignment onto StackOverflow where someone else will write up a great solution. Some people cheat on tests, and it’s no different for a take-home coding assignment. The funny thing is there are different qualities of cheaters out there. I have seen a few who submitted their work but had no idea how to explain any design decisions made. Then some people could answer basic questions about how but had trouble diving deeper to understand the overall project. It’s still an excellent way to test someone’s coding ability despite the chance of someone cheating.

Once a candidate gets to the on-site interview stage, there is usually a whiteboarding test given. The industry is pretty split in groups of whiteboarding is nonsense or not. Here’s a good read:

Write a function that verifies if a string is a palindrome

Whiteboarding an algorithm isn’t useful because successful people have memorized the algorithm answers or tricks. Passing this part of the interview is more skewed toward new graduates who have just studied computer science theory. Senior engineers are less likely to pass these tests as they haven’t been in school for a while. Lastly, it’s not a real test of software development either because no one writes code on a board or paper.

Instead of a whiteboarding test, a live coding test where the candidate spends 60 minutes on either coding or debugging is much better. The candidate would sit in front of a computer with a full-fledged IDE where they could code up a solution. Debugging is a skill that even the most senior engineers may be quite awful at, but being able to debug means fixing software defects and writing less buggy code. The coding test should be a simple problem that can demonstrate their skills without having to create something insane like traversing a spiral matrix.

History Repeats Itself

If someone has done great things in the past, they are bound to repeat themselves.

Looking at a candidate’s previous experience is a great place to get a feel for what this person can accomplish. However, it still does not provide a complete picture because the interviewer has no idea how complex the project is or the candidate’s involvement in the project. Most software projects are done in teams so all interviewers will probe deeper into work history. New graduates trying to get into the industry face a harder time with lighter employment history, but can make up for it with projects. People who have been in the industry for a long time have an excellent work history to display their accomplishments but may have difficulty explaining why it was such a great achievement. Sometimes, the only difference is the perspective of the interviewer versus interviewee.

The other problem with resumes is the state of job titles at tech companies is quite messy because there isn’t a standard so titles at different companies may not translate well to each other. A CTO at a startup of fewer than ten people could be equivalent to an engineering manager at a large 1,000+ people company. Then there are also “non-standard” job titles that don’t translate well such as Head of Engineering which could be an engineering manager, director of engineering, or vice president of engineering. Don’t be surprised if your current title translates to a different title because the role’s responsibilities of that specific company are different.

Nowadays, having a GitHub link on a resume is very common for software engineers, which is a positive trend that technical hiring has achieved. Employers want to see if this person has initiative and kind of what skills they have. GitHub makes it very easy to review someone’s code and recognize their contributions to a project.

Don’t have a GitHub? Try an online course website such as Khan Academy or contribute to an open source project:

Culture Fit

Tech companies have spent an enormous amount of time to form their own culture and are only looking for people who fall within their culture to hire. A candidate may have all the skillset wanted but still disqualified if they are not the type of personality the company is looking for to fit into their culture. Although it’s good to filter out people with high ego, sometimes great engineers are disqualified because of minor character flaws such as being timid or having low confidence. These character flaws can disappear over time as the person grows.

The time tested behavioral questions are relevant in the tech interviews because they are good at revealing many aspects of a person and help paint a better picture of what this person has done. The S.T.A.R. (Situation, Task, Action, and Result) method has become a highly popular technique of answering behavioral questions. Describe the situation, state the goal, what actions the person took, and the results. There’s nothing tricky about this part except preparing past experiences in the correct format.

Tell me about a time you had to go above and beyond your normal duties.

The startup life is a small company that is still trying to break into an industry or create a new product. This period of a company can be the wild west where a person may be expected to move fast, wear multiple hats, work long hours, and be asked to do something that you weren’t hired to do. It’s not the life for everyone, but the rewarding part is it’s usually easier to make a more significant impact and learn new skills.

The corporate life is an established large company with processes and policies that outline how things work. Typically, large companies move at a slower pace because there are quite a few layers in the organization and actions may require approvals. The type of responsibilities that accumulated in one role in a startup environment may be split into different positions in a corporate environment. Engineers make smaller impacts on the company’s overall direction and projects.

Switching between the two can be very difficult, and some have failed to transition. Both have its pros and cons. It’s a matter of finding which one fits better.

Key Points

Hopefully, a company will make an A.I. that places people in jobs so we can all stop wasting time and money. One can hope, but let’s improve things in the meantime.

  • Slow down! Take chances and invest in people. An engineer will be able to pick up new languages and technologies.
  • Software development is changing at a rapid pace into many different verticals. Universities need to keep up with the trends to better prepare new engineers. There needs to be a natural way to pivot between the different verticals.
  • The tech industry needs to stop whiteboarding. Use a live coding test!
  • Interviewers may not understand the impact or complexity of projects in a person’s professional work history. Sometimes, it’s a matter of perspective.
  • Job titles are a mess and may not translate well between companies.
  • Try contributing to an open source project or learn new skills from online courses such as Khan Academy. It’s highly recommended to have code projects on GitHub to showcase.
  • Culture is important! Hiring a person based only on skill can affect team dynamic or even the whole company.

Engineering leader. Software Developer. Problem solver. Failing forward.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store