Rethinking Job Interviews in Software Industry
Never let ’em tell you what your worth is (Yeah)
Respect gotta be earned, it can never be purchased (Never) — Joey Bada$$
The job interview is a process that was dreamed up on a whim about a century ago, never worked in the first place, and hasn’t been altered since. A more effective approach to hiring people than conducting these interviews is not bothering to teach them.
The main issue with interviews in the Software industry is that in a limited amount of time is not possible to assess any individual ability. For a quarter of a million dollars, those in the CS education system have a lot of endowment. They are adamant that you should know how to whiteboard an alpha-beta pruning algorithm and tell its worst-case runtime. Are you going to use that in your day-to-day work? No, never. This is only sometimes the case because we can expand our knowledge through these exercises. Yet, we should believe that something other than what we will deal with as Software Engineers will be even related to this type of problem.
Imagine a hospital wanting to hire a well-known surgeon with 10+ years of experience. The hospital contacts the surgeon (through a recruiter), and he accepts to assist in the interview. During the interview, they ask the doctor to open a corpse and point out where the heart is. Any doctor will stand up and leave the place offended, and with a good reason. Surgeons have jobs that provide for them well; they don’t apply for jobs on a job board or LinkedIn.
Software engineering companies ask us to solve a problem writing code by sharing the screen or in the code platform. These problems are usually odd cases you never will see in real life (like balancing braces and brackets, dumb that the IDE does that for us). These things are comparable to the hospital asking the surgeon to show where the heart is and closing the corpse on the table.
The second camp of thought is associated with giving homework to the candidate that she or he can solve in their own time. This type of interview is more realistic but needs to catch up because of the different experience levels and not a single *right* way to solve a problem.
The take-home assignment requires us to use several hours after work to develop a solution, like creating an API or implementing a User interface. These tasks are real work that they ask us to do with no pay. And it is like they didn’t see all our references or places where we worked before or even check if we made some open source contributions in GitHub. It is like the company asking an architect to develop a building prototype. You can reject this kind of disrespectful task. You can leave and continue in your current job, explaining why this is wrong. You can kindly lead them to check your GitHub Profile, where there are many code examples you tried in the past. I am tired of this kind of interview. I was leading Tech interviews for several companies I worked for, and I refused several times to do this kind of test in my interviews. I have enough experience to determine if the candidate is, which he says he is in a quick tech call, and that is what I do.
What’s more, in this world, we’re all adults conducting business on our terms. We’re all knowledge workers, having replaced non-thinking work with automation. The corporate world needs to learn what programming is. Programmers tend to over-inflate their skills and worth. What if you got good at producing code that worked and kept working when other changes were tossed? What if you could slice your work into small deliverables and deliver several pieces every two weeks? What if the business could count on you?
Most companies want programmers with three to five years of relevant experience so they won’t have to pay to train and then lose them. Spend a year or two grabbing coffee with people and talking about stuff. Figure out their common problems and develop the skills to solve them. Software developers most often don’t change their position or title.
Corporations aren’t adapting to the new realities in our ecosystem, and most developers aren’t that quick to take advantage of these, either. Programmers are seen by many as being interchangeable, too. When viewed as a commodity, we are treated as a commodity. Programming is a technician activity — and it always will be. Programming is a tool that gets other things done. Understanding what to automate is more critical than solving three Leetcode algorithms in under an hour. The bottleneck in what we do is not typing fast a memorized solution. It understands when/where to apply a solution to the right problem affecting the company throughput.
