Today, I want to focus on a skill I think every candidate should develop.
Interviewing many candidates while also growing in my own career has taught me there’s an overlap between career advancement and interview skills. Yes, there’s still the matter of “studying for the test” and irrelevant algorithmic questions. But the ability to communicate complex ideas effectively is an important skill both on the job and during interviews.
As an experienced engineer, you are expected to have a library of patterns you can deploy when solving problems. But actually applying the pattern is a small part of your job:
You need to convince others a particular solution is the right one. This may even involve communicating a technical solution to non-technical stakeholders, in order to determine the right set of trade-offs.
You need to communicate that solution to other engineers who will help you in implementing the solution. Often, those other engineers will be junior engineers.
If you’re part of an organization that values external communication, you may also be communicating your technical solution to other teams in the company, or even to other companies at a conference or other industry event.
Communication during an interview
In an interview, one of your goals is to convince the interviewer you’re able to solve technical problems. That means communicating your solutions just as much as it means solving the given problems in the first place. See how that might align with the responsibilities of a senior engineer?
Certainly, the same type of communication skills you’re developing are useful for system design interviews and interviews where you have to recount complex problems you’ve worked on in the past. Your ability to communicate results to others translates directly into strong performances at these interviews.
But even in algorithm-based interviews, once you have an answer, you need to communicate how you came up with the answer and why you believe it’s correct. This is similar to writing code, but acknowledging you still need to insert that code into your codebase in a way that’s clear to future maintainers. Whether you’re writing code comments, preparing documentation or simply writing the code in a self-explaining way, communication is key even at the micro-level.
Developing your communication skills
Ideally, your company can help you develop these communication skills, for the benefit of the organization as much as for your sake. But whether or not you’re getting the mentorship you need, an effective strategy is to keep a dev log:
Start by writing down the problems you’re solving. A clear problem statement helps you focus your energy on the right solution space.
Document prior knowledge that may be useful to the task at hand. For example, if I’m working on a quality-of-life feature, I write down the type of test data I need to reproduce the conditions where my feature will show up.
Document failed approaches. Failures are just as enlightening as successes, maybe more so.
Finally, summarize what you actually did to solve the problem.
I personally keep a bunch of documents, some for myself and some to share with my coworkers, that document my work. Consolidating tribal knowledge into a structured form helps me understand my impact on the company, as well as gives me great documentation to look back on when working with similar areas of our product. And, if the same questions keep coming up, I just point people to my documentation.
If you’re disciplined about documenting your own work, you’ll find it much easier to explain that work to an interviewer.
All of this has some limitations. I regret to say, in the past, I’ve put less value on technical communication and more on real-time problem solving. I know now that on-the-spot problem solving is not always a good benchmark, but many interviewers are still suspicious of candidates who can “talk the talk” but not “walk the walk”. (This comes down to looking for weaknesses, not strengths.)
Still, as you grow in your career, good communication skills become increasingly more important. So it still makes sense to cultivate them, and in doing so, add another tool in your interview toolkit.