151: Driving Leadership and Technical Quality as a Staff Engineer

Driving leadership as a Staff Engineer and respecting candidate experience during interviews

Thank you for reading Snippets of Text. Snippets from media about tech, programming, parenting, and more. This is a preview of a post available exclusively to paying subscribers. You can get unlimited access to all articles by purchasing a subscription.

Off Topic: Respecting Experience in Software Hiring

A hospital is seeking to hire a highly experienced surgeon with over ten years of expertise in complex surgeries. The hospital contacts the surgeon, who agrees to participate in the interview process. However, this approach needs to be more respectful of the experience of these two distinguished professionals. The surgeon and the architect already have well-established careers and did not actively apply for the job through traditional channels like job boards or LinkedIn. Instead, the hospital and the study initiated contact with them. One can only imagine the feelings of these professionals towards these companies. They would likely be offended and have valid reasons for feeling so. It's as if the hospital asked the surgeon to locate the heart and then closed the corpse on the table.

Similarly, the study asking the architect to develop a building prototype is equally disrespectful. These tasks can be declined, and the professionals can choose to remain in their current jobs while explaining why such requests are inappropriate (you are welcome to use my examples of the surgeon and architect). They can politely direct the companies to review their GitHub Profiles, which showcase numerous code examples they have worked on in the past. 

I am exhausted from encountering these types of interviews. In my previous roles, where I conducted tech interviews for various companies, I consistently refused to impose these tests on candidates. I have acquired enough experience to determine a candidate's abilities during a quick technical call, and that is precisely what I prefer to do.

Algorithms, in interviews, often become mere tests of memorization rather than genuine indicators of competence. Do the interviewers themselves write tests? It would be more productive to ask them to test drive a simple issue in the candidate's current codebase.

How do candidates approach debugging? What kinds of questions do they ask? Do they inquire about the rationale behind certain implementations? When was the last time they had to write a binary search? Improving infrastructure can enhance performance more effectively than striving for greater algorithmic efficiency.

The efficiency of algorithms rarely extends beyond their application in day-to-day work. The algorithms presented in interviews are only sometimes encountered in practical scenarios. System design interviews often amount to little more than rehashing answers. Instead, ask candidates to explain a project they have previously worked on and evaluate their proficiency in the technologies they utilized. It is essential to assess how well they collaborate and interact with stakeholders since technology ultimately serves people.

The job interview process, conceived over a century ago, has proven ineffective and remained the same. Rather than subjecting candidates to these interviews, investing in teaching and training them is a more practical approach. Laszlo Bock pointed out that brain teaser interview questions boost the interviewer's ego.

The main issue with interviews in the software industry is the limited time available to assess an individual's abilities. Given the substantial investment in CS education, with costs often exceeding a quarter of a million dollars, educators insist that candidates should know how to whiteboard complex algorithms like alpha-beta pruning and provide the worst-case runtime. However, these algorithms are seldom used in day-to-day work. There are two opposing schools of thought regarding interviews. While these exercises can broaden our knowledge, we should acknowledge that most software engineers will rarely encounter such problems in their careers. The second school of thought advocates for presenting candidates with real-world challenges they can solve in their own time. Although this approach is more realistic, it must be adapted to accommodate different experience levels, as there is seldom a single "right" way to solve a problem.

[^]: Developer Hegemony: The Future of Labor

Thanks for looking at the free preview of Snippets of Text. Please consider subscribing to the paid version if you find my work helpful. This way, I can spend more time developing new ideas to share with you.