By Jesse Mazur
The New Hotness
You can’t go a month without hearing about the latest new framework or language that will solve all of your coding problems. In the mobile and front-end worlds it feels like last year’s state-of-the-art project is next year’s crufty legacy code. In this ever-changing landscape, engineers are always trying to learn the latest technique, attend a new bootcamp, or crank out a new personal project in order to keep up. The result can be piles of resumes that contain every new buzz word under the sun, and applicants painting themselves as the best candidate for just about any engineering position. How can hiring managers ensure that they find the right person? How can aspiring engineers land the right job?
The answer: fundamentals.
Back to Basics
The Current Process
There are certainly valid criticisms of common tech hiring practices. Long interview loops with difficult coding problems written primarily on a whiteboard inevitably leave something to be desired. The reason for this process is often misunderstood and can lead to dissatisfied candidates complaining about unfair, puzzle-like questions. “When was the last time anyone actually used a red black tree on the job anyway?!” Not all of those complaints are unwarranted. An engineer, at her core, is a problem solver. The programming language is simply one of many tools she uses to solve the problem. The spirit of these questions is to reveal the candidate’s problem solving skills in order to understand if she will be able to solve similar problems on the job. Coding interviews shouldn’t be vocabulary tests or mind bending trick questions. A well-worded question will challenge the candidate, but it will also be practical and relevant to the work they will be doing on the job. It will have several possible solutions, each of which may leverage different data structures and algorithms. Its difficulty will also scale, so that a more seasoned engineer will solve it more elegantly, while handling more edge cases right off the bat. An experienced interviewer should be able to gauge that skill early on and know what curve balls to throw the candidate to calibrate the questions to the candidate’s level.
Talent vs Skill
A final piece of the puzzle is the ability to recognize and balance the difference between talent and skill. In this context, talent is defined as an innate ability or trait the candidate possesses— something that cannot necessarily be taught. A skill, on the other hand, can be defined as something that can be mastered with practice over time. Finding the correct engineer should start with identifying which talents she needs to embody in order to be successful in the role, then defining the ideal skillset. For example, a candidate with a natural drive to deliver results, who is a quick learner with good fundamentals, might not need to be 100% familiar with the bleeding-edge framework being used on a given project. She can probably join the team, learn quickly, and get a project to the finish line on time.
The engineering world is always changing and there will always be some new way to solve the same old problems. Finding candidates with innate talents that are necessary for the role, who also have a strong grasp of the fundamentals, will set up any dev team for longer term success. Trying to hire a team of engineers who only know the latest and greatest means having a staff that will not outlast the ever-shortening lifespan of tech stacks. What’s more, trying to find that unicorn-ninja-coder may actually take longer than simply finding a solid engineer who can learn on the job.
Jesse Mazur is a Senior Director of Engineering at Meredith Corporation, the largest US media conglomerate (People, Sports Illustrated, Real Simple, etc.), and a member of the Brandeis GPS Master of Software Engineering advisory board.
Faces of GPS is an occasional series that profiles Brandeis University Graduate Professional Studies students, faculty and staff. Find more Faces of GPS stories here.