Jekyll2024-02-07T22:00:56+00:00https://hiringfor.tech/feed.xmlHiring for TechThe weekly newsletter for all things tech hiring. Tech interviews are hard, whether you're hiring or looking to be hired. Poor interview practices mean the right candidates are not being matched with the right companies. In this weekly newsletter, I'll send you advice on how to prepare for an interview, as a candidate or as an interviewer. Each edition is short, so you can read and be on your way.
Avik DasAcing the system design interview2022-01-10T00:00:00+00:002022-01-10T00:00:00+00:00https://hiringfor.tech/2022/01/10/acing-the-system-design-interview<figure id="cover-img">
<p><img src="/assets/images/posts/2022-01-10-acing-the-system-design-interview.jpg" alt="A busy container port at night, with hundreds, maybe thousands of containers" /></p>
<figcaption>
<p>A complex system has many parts working together. Image by <a href="https://unsplash.com/@timelabpro?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Timelab Pro</a> from <a href="https://unsplash.com/s/photos/shipping?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a></p>
</figcaption>
</figure>
<p>It’s been a while since I last wrote, but in the last year, I’ve done a lot of system design interviews. I really like these interviews, even if they could use some improvement, because they can closely resemble work I really do and are open-ended enough to allow candidates to play to their strengths.</p>
<p>Based on interviewing many candidates, I’ve compiled a few important tips to make sure you’re giving interviewers exactly the signals they need to evaluate your strengths. System design is a skill that requires experience, but for those who are experienced, that skill should be something they are utilizing in their daily work anyway. What follows is a checklist to combat interview nerves and showcase your experience in that one hour.</p>
<h2 id="gather-functional-and-non-functional-requirements">Gather functional and non-functional requirements</h2>
<p>I talked about <a href="/2020/07/06/gathering-requirements-in-an-interview.html">gathering requirements</a> before, but doing so is especially important for system design interviews. Unlike a constrained algorithm, a large system has many more areas where you can make different decisions based on your requirements. There are two types of requirements you should be clarifying:</p>
<ul>
<li>
<p><strong>Functional requirements</strong>: what should the system actually <em>do</em>? For example, when <a href="/2020/03/23/system-design-practice-distributed-id-generation.html">designing a URL shortener</a>, one important question to ask is if we want to support reverse lookups (from a long URL to an existing short URL), or if you can tolerate the same long URL being shortened in two different ways. This is where you understand how users will actually interact with the system.</p>
</li>
<li>
<p><strong>Non-functional requirements</strong>: how the system behaves technically. You’ll want to understand the scale of the system (number of users, simultaneous requests, amount of data being processed or stored). Another common factor to clarify is expected latency, especially end-to-end latency for the entire system, which can include read-after-write consistency requirements.</p>
</li>
</ul>
<p>It’s okay to dive into some of these requirements during the design of your system, as you figure out what trade-offs you’re being forced to make. However, the more experienced you are, the more of these requirements you can recognize up front and therefore, your experience level comes through in this portion of the interview.</p>
<p>But whatever you do, don’t dive straight into a design. Figure out what you’re designing first.</p>
<h2 id="present-an-end-to-end-solution">Present an end-to-end solution</h2>
<p>The biggest issue I see is when candidates go into too much detail in some parts of their architecture, and at the end of the interview, they don’t have an end-to-end solution. Maybe they focused too much on the data storage and hand-waved over how the data is processed. Or they never talked about how the data, or even what data, actually ends up in their system.</p>
<p>If nothing else, make sure you have a high-level block diagram that clearly presents all the different components of your proposed system. Most solutions will consist of these common pieces:</p>
<ul>
<li>Data sources: application servers, client devices, etc.</li>
<li>Data stores: relational, time series and key-value databases, in-memory caches, etc.</li>
<li>Data transport: message queues, REST APIs, etc.</li>
<li>Data processing : where the processing happens, what data is needed and what the processing does.</li>
<li>Auxiliary services if they make sense: firewalls, load balancers, etc. In the problems I give, these are usually a given and not necessary to mention, but they may be central to other applications.</li>
</ul>
<p>Notice the heavy emphasis on <em>data</em>. This is because in most large-scale systems, at least in my experience, the data is at the heart of the system. Everything about the system, the different pieces and how they tie together, exist to make sure the data can flow through the system and get processed in a way that’s valuable for your users.</p>
<h2 id="use-industry-standard-terminology">Use industry-standard terminology</h2>
<p>The specific technologies and terminology your company uses is sometimes unique, often driven by the specific needs of its history. But underlying that uniqueness is a common set of patterns your company applies, and those patterns are the language you share with the interviewer. Reference those patterns.</p>
<p>For example, feel free to name drop Kafka or Amazon SQS if that’s what you’re comfortable with, but mention that you want a message queue configured as a pub/sub system. This approach has many advantages:</p>
<ul>
<li>If the interviewer doesn’t know the same technologies as you (though they should know the big ones), you have a common language.</li>
<li>You show you understand exactly the functionality your proposed system needs, since the same technology can often be used for multiple reasons.</li>
<li>And finally, it shows that regardless of your background, you have sufficient general knowledge to translate your experience to your new role, where you may be using different technologies.</li>
</ul>
<p>Naming a specific technology is great to show you have real-world experience, but still make sure to reference the underlying patterns.</p>
<p>The same goes for company-specific terminology. If you and the interviewer interpret the same words as different concepts, you’ll have a lot of miscommunication. (Interestingly, all of this can apply when working with other teams at a big company!)</p>
<h2 id="explain-what-problems-youre-solving-with-your-choices">Explain what problems you’re solving with your choices</h2>
<p>I have historically thought of this as presenting trade-offs, but I found candidates often spend too much time detailing alternate solutions instead of committing to a specific proposal. Still, trade-offs are an important part of designing large systems, so it’s important you explain what problems each of your choices solves.</p>
<p>For example, if you decided to incorporate a message queue into your design, you can say that you’re willing to take the hit to processing time (the processing is no longer on-demand, but when the queue consumer gets to that piece of data) in order to ensure every piece of data is processed reliably, without worrying about race conditions between processing of related data. Or if you incorporate a key-value store, you can say you want low latency reads for individual items, and you don’t need to do any other queries based on the functional requirements you gathered earlier.</p>
<p>Saying this much and moving on shows you made your choices deliberately and with a clear understanding of both the problem and solution spaces, all while sticking to a unified narrative about your proposed system.</p>
<h2 id="be-ready-to-deep-dive-into-your-areas-of-expertise">Be ready to deep dive into your areas of expertise</h2>
<p>It should be acceptable to not have deep expertise in all areas of the system (though I know not all interviewers are so accommodating), but if the interviewer chose the problem based on your background, there should be areas you have experience in. In particular, you want to make sure you can talk intelligently about any piece of the system that aligns with your previous work, especially if that piece is prominently mentioned on your resume.</p>
<p>Did you say you worked on a streaming architecture for processing data? You should be able to talk about message queues, mention technologies like Apache Spark or Samza (or whatever technologies you used before), the trade-offs between stream processing and online or offline data processing, etc. If you’ve worked extensively with data storage, you should be able to talk about sharding, database choices, disk-based persistent vs. in-memory caching, etc.</p>
<p>This is another area where your knowledge is expected to be broader the more experienced you are. If you’re senior enough, you should be able to talk about the different areas I mentioned above at least at a high level. Those are fairly standard concepts in software engineering that come up in many large-scale systems.</p>
<h2 id="talk-about-productionizing-the-system">Talk about productionizing the system</h2>
<p>Finally–and this is the part inexperienced people trip up on–talk about getting the system to production. Hopefully <a href="/2020/03/02/are-you-asking-candidates-to-read-your-mind.html">your interviewer clearly asked for this</a> when presenting the problem, but if not, make sure you clarify if this part is something you need to talk about.</p>
<p>This is where you talk about monitoring and logging, error handling (though some of that may have come up earlier), gradual rollouts to address concerns like cache warmup periods, graceful degradation in case of unexpected traffic spikes, etc. Specifically, monitoring and error handling are two areas <em>every</em> system deals with, so I would lead with those.</p>
<p>This part of the interview is where you show you not only can design a theoretical system, but you have the real-world experience to know what problems such a system will encounter in production. If I were to make you a tech lead, would I have the confidence you’ll think about these concerns <em>before</em> we launch? It’s also a reason why you need to be streamlined about the overall system design, so you have time to address this section.</p>
<hr />
<p>The last tip I have is minor, but it’s worth a quick mention: be ready to show your design as you build it. If you’re doing the interview in person, be prepared to draw out block diagrams on the whiteboard. If the interview is virtual, pick a drawing tool and practice with it. That could even mean getting your own whiteboard for yourself! Just make sure it’s visible from your camera.</p>
<hr />
<p>When done correctly, system design gives you, the experienced engineer, an opportunity to showcase (at least a subset of) your skills as a technical lead for a project. However, since you’re trying to fit in your experience into just one hour, having a script for the interview means you can show exactly the skills that inspire confidence in your abilities.</p>Avik DasA complex system has many parts working together. Image by Timelab Pro from UnsplashWhat’s still wrong with tech hiring2021-02-15T00:00:00+00:002021-02-15T00:00:00+00:00https://hiringfor.tech/2021/02/15/whats-still-wrong-with-tech-hiring<figure id="cover-img">
<p><img src="/assets/images/posts/2021-02-15-whats-still-wrong-with-tech-hiring.jpg" alt="A pencil snapped in half" /></p>
<figcaption>
<p>Tech hiring is still broken, but it doesn’t have to be. Image by <a href="https://pixabay.com/users/moritz320-1260270/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=1203982">moritz320</a> from <a href="https://pixabay.com/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=1203982">Pixabay</a></p>
</figcaption>
</figure>
<p>Last year, I set out with <a href="/2020/02/03/whats-wrong-with-tech-hiring.html">a head full of disconnected thoughts about hiring</a> and a vision to share those thoughts with a wider audience. The response has been positive and overwhelming, with the Hiring For Tech newsletter at over 50,000 subscribers as of today!</p>
<p>I’m only one person, so I haven’t yet changed the world of tech hiring yet. Plus, with hiring slowed down last year due to COVID, companies haven’t always invested in improving their process. We still have the same problems we always did:</p>
<ul>
<li>
<p>Companies are looking for weaknesses, instead of strengths. Weaknesses tend to be coachable, but strengths represent potential. Until we, as an industry, shift our focus, <a href="/2020/02/10/false-positives-and-false-negatives.html">our hiring processes will always exclude good people</a>.</p>
</li>
<li>
<p>Companies treat interviews as a competition, instead of a collaborative exercise. This puts candidates in a defensive position, instead of allowing them to <a href="/2020/03/16/were-in-it-together.html">show how they would work with their future colleagues</a>.</p>
</li>
<li>
<p>Interviewers don’t invest in interviews, putting minimal effort into evaluating candidates. That includes not <a href="/2020/12/07/getting-to-know-the-candidate-before-the-interview.html">preparing ahead of the interviews</a>, and not being <a href="/2020/12/14/writing-good-interview-feedback.html">involved after the interview</a>.</p>
</li>
<li>
<p>Companies evaluate candidates based on criteria that don’t match day-to-day work. Algorithm interviews are a great example, when interviews could utilize <a href="/2020/05/04/the-project-interview.html">real-world projects</a> instead.</p>
</li>
<li>
<p>Companies don’t focus on hiring underrepresented groups, leading to perpetuating existing biases in their processes. The cycle has to be broken with <a href="/2020/02/24/if-you-want-diversity-you-need-targeted-hiring.html">targeted intervention</a>.</p>
</li>
</ul>
<p>If this feels like I’m repeating myself, it’s because I am. Over the last year, I’ve covered exactly how we need to improve hiring in tech, but we’re not making nearly enough progress. Now, there are two things that need to happen:</p>
<ul>
<li>
<p>People need to speak up. This means not making excuses for the terrible practices companies use, instead holding these employers and interviewers accountable. Talk about what companies are doing wrong, and what they should be doing instead.</p>
</li>
<li>
<p>Having written down many of my thoughts, I’m going to focus on compiling this information in an actionable form and push for change. This means less writing on this newsletter. Expect to see new articles less frequently.</p>
</li>
</ul>
<p>This is not the end of the journey for Hiring For Tech. The last year has only been the first step. Let’s making tech hiring better together!</p>Avik DasTech hiring is still broken, but it doesn’t have to be. Image by moritz320 from PixabayOne size does not fit all2021-02-08T00:00:00+00:002021-02-08T00:00:00+00:00https://hiringfor.tech/2021/02/08/one-size-does-not-fit-all<figure id="cover-img">
<p><img src="/assets/images/posts/2021-02-08-one-size-does-not-fit-all.jpg" alt="A row of blue and gold medals for the Boston Marathon" /></p>
<figcaption>
<p>It’s possible to accommodate different types of candidates, while still maintaining objective criteria. Photo by <a href="https://unsplash.com/@luchi_cheng?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">LUCHI CHENG</a> on <a href="https://unsplash.com/s/photos/medals?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a></p>
</figcaption>
</figure>
<p>I’ve talked about what seem to be two conflicting topics: <a href="/2020/06/29/fighting-bias-with-structured-interviews.html">standardizing your interviews</a> and <a href="http://localhost:4001/2020/12/07/getting-to-know-the-candidate-before-the-interview.html">accommodating different candidates</a>. So how can you be accommodating without introducing bias?</p>
<p>It turns out, you can give different candidates different questions, or even a different interview process, based on:</p>
<ul>
<li>
<p><strong>Comfort with in-person interviews.</strong> Interviewing is stressful, so if you want to find the best people, you’ll have to accommodate those who don’t perform well on the spot. For these candidates, <a href="/2020/08/10/how-fair-is-the-take-home-assignment.html">a take-home assignment is a good option</a>, as is <a href="/2020/08/03/reducing-interview-stress-with-independent-work.html">independent work</a>.</p>
</li>
<li>
<p><strong>Prior experience.</strong> Really good engineers have a solid foundation, and can learn individual technologies quickly. So if you’re looking for a Vue engineer, but your candidate has more experience with React, you’re still going to get a better signal by seeing how they work with React. Same if you let the candidate use <a href="/2020/07/27/let-the-candidate-choose-their-programming-language.html">the language they’re most comfortable with</a>.</p>
</li>
</ul>
<p>The important consideration is that all the options you provide and all the questions you ask are picked from a standardized pool your company has created ahead of time.</p>
<h2 id="maintaining-objectivity">Maintaining objectivity</h2>
<p>For the interview questions to be standardized, it’s important each one stand on its own. Tying this concept back to the examples above:</p>
<ul>
<li>
<p>An in-person interview question must have objective criteria for failure, success and excellence. Similarly, a take-home assignment must have objective criteria for failure, success and excellence. Don’t compare the two types of interviews, just how well the candidate did in their respective interview.</p>
</li>
<li>
<p>Evaluate how prior experience translates to applicability to the role. For an experienced web developer role, you’ll want someone who understands web development. But even if your company uses Vue, a candidate with React experience and a great React solution to your interview problem is a better fit that someone with Vue experience who does poorly with a Vue solution. Make sure each version of the problem is evaluated on its own merit.</p>
</li>
</ul>
<p>Both of these align with the principles of structured interviews. At the same time, being flexible with your requirements and providing different interview options means you can evaluate a wide range of candidates. <strong>Ultimately, <a href="/2020/10/19/looking-for-strengths-is-not-lowering-the-bar.html">you don’t have to lower the bar</a>. It’s just that the same height bar looks different for different people.</strong></p>
<hr />
<p>There isn’t a one-size-fits-all solution to hiring. But it is possible to create a process that maintains objectivity while accommodating different types of candidates. The key is to define evaluation criteria for each interview option you offer.</p>Avik DasIt’s possible to accommodate different types of candidates, while still maintaining objective criteria. Photo by LUCHI CHENG on UnsplashFormal interview training2021-02-01T00:00:00+00:002021-02-01T00:00:00+00:00https://hiringfor.tech/2021/02/01/formal-interview-training<figure id="cover-img">
<p><img src="/assets/images/posts/2021-02-01-formal-interview-training.jpg" alt="Students attending a lecture and taking notes" /></p>
<figcaption>
<p>Interviewing is a skill that needs to be taught formally. Photo by <a href="https://unsplash.com/@climatereality?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">The Climate Reality Project</a> on <a href="https://unsplash.com/s/photos/class?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a></p>
</figcaption>
</figure>
<p>A running theme in this newsletter is the idea that good software engineers don’t automatically make good interviewers. This is in contrast to the idea that <em>being interviewed</em> should not be a separate skill! As a result, <strong>formal interview training is a must for interviewers</strong>.</p>
<p>The problem is the required skills are not always taught to engineers, nor given their due respect. For example, interviewing skills are typically not taught in college, or in many cases, not even at the workplace. Some companies may provide training around avoiding bias, which is great, but it’s only one part of the puzzle. My hunch is companies provide this training for compliance reasons.</p>
<p>Lately, I’ve been thinking about what a good course on interviewing would look like, and I’d like to explore that today.</p>
<h2 id="what-every-interviewer-should-know">What every interviewer should know</h2>
<p>Drawing on my writing from the past year, I believe the following topics should absolutely be covered in a formal training course for prospective interviewers:</p>
<ul>
<li>
<p><strong>Principles of hiring:</strong> looking for strengths instead of weaknesses, accommodating diverse backgrounds and skill sets, and the inherent power imbalance between interviewers and candidates.</p>
</li>
<li>
<p><strong>Preparing to be an interviewer:</strong> practicing interview problems, familiarizing yourself with tools and technologies used by candidates, and other ways to be a strong interviewer.</p>
</li>
<li>
<p><strong>What to expect during the interview:</strong> pre-interview preparation, how to introduce yourself, how to conduct the interview, and how to write post-interview feedback.</p>
</li>
<li>
<p><strong>Apprenticeship:</strong> how the interview apprenticeship program works, and what is expected of both apprentices and experienced interviewers.</p>
</li>
</ul>
<p>These are topics I’ve learned about over the course of hundreds of interviews, and I’m sure many candidates have been negatively impacted by my lack of experience in the beginning. Good training could prevent so much of that negative impact going forward.</p>
<p>I’ve already written about every single one of these topics, but I’m sure there’s more to talk about. So here’s my prompt for my readers: <strong>what do you believe every interviewer should know before interviewing candidates?</strong></p>Avik DasInterviewing is a skill that needs to be taught formally. Photo by The Climate Reality Project on UnsplashInterview apprenticeship2021-01-25T00:00:00+00:002021-01-25T00:00:00+00:00https://hiringfor.tech/2021/01/25/interview-apprenticeship<figure id="cover-img">
<p><img src="/assets/images/posts/2021-01-25-interview-apprenticeship.jpg" alt="Two engineers looking at code together." /></p>
<figcaption>
<p>Engineers work together to learn from each others. Interviews should be no different. Photo by <a href="https://unsplash.com/@nesabymakers?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">NESA by Makers</a> on <a href="https://unsplash.com/s/photos/apprentership?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a></p>
</figcaption>
</figure>
<p>Software engineers are well-positioned to evaluate a candidate’s technical ability, but conducting an interviews is much more than evaluating code. Non-technical skills like the ones I’ve been writing about, and even <a href="/2021/01/11/technical-skills-every-software-engineer-interviewer-should-have.html">interview-specific technical skills</a>, are crucial.</p>
<p>Unfortunately, many software engineers are thrust into interviewing candidates without proper training. Just like engineers need mentorship for their technical skills, new interviewers need hand-holding and feedback. When done right, pairing interviewers of different levels plays a huge role in up-leveling junior interviewers.</p>
<h2 id="the-apprenticeship-model">The apprenticeship model</h2>
<p>The apprenticeship model transitions an engineer from a junior interviewer to an experienced one:</p>
<ol>
<li>
<p>First, an engineer is considered an apprentice interviewer. Every interview is scheduled with an experienced interviewer and up to one apprentice. At no point does an apprentice interview on their own.</p>
</li>
<li>
<p>After a sufficient number of interviews, the apprentice is designated as an experienced interviewer. At this point, they can interview a candidate on their own, or even with a new apprentice.</p>
</li>
</ol>
<p>However, any process is only as good as the culture that applies it.</p>
<h2 id="applying-apprenticeship-effectively">Applying apprenticeship effectively</h2>
<p>Companies need to focus on using the apprenticeship program as an opportunity to teach, not as a gate-keeping mechanism. To that end:</p>
<ul>
<li>
<p>Interviewers need to apprentice for different interview areas individually. For example, if the company has an algorithm section and a system design section, both require different skills. One interviewer can be experienced in one area and an apprentice in another. However, general interview skills carry over, so the second apprenticeship can be shorter.</p>
</li>
<li>
<p>Similarly, an apprentice should be paired with different experienced interviews over time. The way I’ve seen this done is each interview is scheduled with a different pair (though sometimes people cross paths multiple times). This way, the apprentice can observe multiple interview styles.</p>
</li>
<li>
<p>Train experienced interviewers to mentor apprentices. It’s not enough for an experienced interviewer to conduct the interview while the apprentice watches. Instead, the two interviewers should prepare together before the interview and de-brief after.</p>
</li>
<li>
<p>On the note of mentorship, apprentice should ask questions after the interview. “Why did you ask that follow-up?” “What went well, and what could have gone better?” An apprentice is present to learn, not just to fill a requirement.</p>
</li>
<li>
<p>The apprentice can start by observing, but over time, they should spend more time driving the interview. Before graduating from their apprenticeship, they should be driving the entire interview like an experienced interviewer.</p>
</li>
</ul>
<p>If this feels like a lot of work for an hour-long interview, realize that interviewing affects people’s lives. It’s important to take the job seriously.</p>
<hr />
<p>Pairing an inexperienced interviewer with an experienced one allows engineers to slowly learn how to interview effectively. Best of all, this is done without the candidates being negatively affected, as the experienced interviewer is always present to take the reins.</p>Avik DasEngineers work together to learn from each others. Interviews should be no different. Photo by NESA by Makers on UnsplashInterviewing and pattern matching2021-01-18T00:00:00+00:002021-01-18T00:00:00+00:00https://hiringfor.tech/2021/01/18/interviewing-and-pattern-matching<figure id="cover-img">
<p><img src="/assets/images/posts/2021-01-18-interviewing-and-pattern-matching.jpg" alt="An assortment of tools, like a hammer, plier and a wrench, lying on a wooden table." /></p>
<figcaption>
<p>A wide variety of readily-available tools is key to success in interviews. Photo by <a href="https://www.pexels.com/@energepic-com-27411?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels">energepic.com</a> from <a href="https://www.pexels.com/photo/tool-set-on-plank-175039/?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels">Pexels</a></p>
</figcaption>
</figure>
<p>For candidates, a full day of interviews is grueling, but in the context of demonstrating your technical skills and how well you’ll perform on the job, it’s a short amount of time. There’s not enough time to invent completely novel solutions, or to prototype multiple different approaches. Instead, you’ll have to rely on previous experience.</p>
<p>Given this time constraint, the single most effective trick for an effective interview is <strong>pattern matching on a toolbox of common techniques</strong>.</p>
<h2 id="rapid-pattern-matching">Rapid pattern matching</h2>
<p>Interviews become easier when you can look at a problem and quickly assess, at a high-level, what approach to take. Every problem is unique, but most are variations of the same common principles. It’s even okay to be wrong at first. When you go down one route and encounter some difficulties, just pattern match on the next technique based on those difficulties.</p>
<p>Let’s see how pattern matching plays out in a few scenarios:</p>
<ul>
<li>
<p><strong><a href="https://avikdas.com/2020/01/28/the-balanced-parentheses-problem.html">The balanced parentheses problem</a></strong>, specifically the third follow-up with arbitrary delimiters. Until that follow-up, you can go through the input string once in a for loop. But if you try that with arbitrary delimiters, you find you may not have enough information to tell if a particular character is an opening or closing delimiter. There’s ambiguity. At this point, you reach into your toolbox to find which technique deals with ambiguity: backtracking!</p>
</li>
<li>
<p><strong>A system design problem like <a href="/2020/05/11/system-design-practice-designing-a-payment-system.html">designing a payment processor</a>.</strong> Talking through the problem with the interviewer, it turns out the key requirements are reliability (ensuring every promise made to the user is fulfilled) and idempotency (the effect of each action happens only once). If you have a comprehensive toolbox, you know a queue-based architecture is appropriate and you can design the system around that queue.</p>
</li>
<li>
<p><strong>Design and implementing a lightweight chat application.</strong> Some of the tools in your toolbox to draw from include a client-server architecture, database modeling of domain objects like users and messages, and REST APIs. To support instantaneous delivery of messages, the tools you have include server-sent events, polling or even bi-directional channels like WebSockets. Even the composite architecture composed out of these tools is itself a common architecture, and therefore a pattern in your toolbox.</p>
</li>
</ul>
<p>In all these cases, you <em>can</em> build up the right techniques from scratch, often through trial and error. But if you can immediately pattern match to find the appropriate techniques, and <em>you can name those techniques</em> (“I’m going to use backtracking because we’re dealing with ambiguity”), then the interviewer quickly knows you’re on the right track.</p>
<h2 id="building-a-comprehensive-toolbox">Building a comprehensive toolbox</h2>
<p>An effective toolbox of techniques consists of:</p>
<ul>
<li>
<p><strong>Common algorithmic techniques.</strong> <a href="https://avikdas.com/2019/04/15/a-graphical-introduction-to-dynamic-programming.html">Dynamic programming</a>, <a href="https://avikdas.com/2020/02/25/a-tree-based-introduction-to-backtracking.html">backtracking</a>, <a href="https://avikdas.com/2019/08/13/practical-computer-science-connected-components-in-a-graph.html">graph algorithms</a>, to name a few. Having a formal computer science education helps, but practicing problems and reading up on the theory can make up the gap.</p>
</li>
<li>
<p><strong>Common types of large-scale systems.</strong> <a href="https://avikdas.com/2020/03/23/scalability-concepts-distributed-id-generation.html">Horizontal scaling</a>, <a href="https://avikdas.com/2020/04/13/scalability-concepts-read-after-write-consistency.html">consistency in distributed systems</a> and <a href="https://avikdas.com/2020/05/11/scalability-concepts-the-reliability-queue.html">queue-based architectures</a> are good examples. Unfortunately, experience working at scale really puts you ahead of the pack, but I’ve tried to write articles about these concepts to help those without the relevant experience.</p>
</li>
<li>
<p><strong>Common building blocks of practical applications.</strong> These are the tools you’ll use to implement a project, like web frameworks used to build REST APIs, common databases and interfaces to those databases, and UI libraries for the client portion of these projects. You don’t have to know every possible API or framework, but you should be able to build a full application in your area of expertise (client, server, full-stack, etc.).</p>
</li>
</ul>
<p>The latter two categories of tools become increasingly more important the more senior you are. Meanwhile, algorithmic techniques are more important for junior engineers with less industry experience.</p>
<p>The best way to build up this type of toolbox is to observe real-life applications, recognize the technologies and techniques used in those applications, and most importantly, <strong>understand why those technologies and techniques were used</strong>. Whether the application uses Kafka or RabbitMQ doesn’t matter, but the fact that a queue is used for reliability is key.</p>
<h2 id="is-this-the-right-approach">Is this the right approach?</h2>
<p>I don’t think an interview that relies only on pattern matching is ideal, though it’s not completely unfounded either.</p>
<p>Interviewers often talk about assessing a candidate’s problem solving skills. There’s the type of interview where you’re expected to not come up with a perfect solution, but to think through a hard problem from the ground up. To some extent, that type of interview is more reflective of a software developer’s day to day work. But some amount of pattern matching is important for any senior engineer, whose past experience plays a large part in making solid technical decisions.</p>
<p>Still, regardless of what interview style is ideal, pattern matching will still help you succeed in the types of interviews you’ll encounter <em>in practice</em>.</p>
<hr />
<p>Real-world development is done collaboratively over the course of weeks, months and years. Interviews need to evaluate candidates in a matter of hours. For that reason, candidates benefit from pattern matching problems to common techniques. By quickly recognizing the type of problem and what techniques are applicable, you can demonstrate to the interviewer you’re going in the right direction early on. Then, you can spend the rest of your time focusing on the particulars of the given problem.</p>Avik DasA wide variety of readily-available tools is key to success in interviews. Photo by energepic.com from PexelsTechnical skills every software engineer interviewer should have2021-01-11T00:00:00+00:002021-01-11T00:00:00+00:00https://hiringfor.tech/2021/01/11/technical-skills-every-software-engineer-interviewer-should-have<figure id="cover-img">
<p><img src="/assets/images/posts/2021-01-11-technical-skills-every-software-engineer-interviewer-should-have.jpg" alt="Green text going down the screen on a black background, like in the 1999 movie The Matrix." /></p>
<figcaption>
<p>More than even the candidate, the interviewer has a higher technical bar to meet. Photo by <a href="https://unsplash.com/@markusspiske?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Markus Spiske</a> on <a href="https://unsplash.com/s/photos/matrix?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a></p>
</figcaption>
</figure>
<p>There’s a lot of discussion about technical skills candidates need to have, like algorithms, systems design, technical communication. But I actually think the <em>interviewer</em> is the one with the greater responsibility.</p>
<p>Think of it this way. A candidate needs to demonstrate they are capable of the job they are being hired for. That means they need to have the technical skills they will use on the job and, in an ideal world, that should be enough. But the interviewer’s job is to assess if the candidate can succeed on the job, which is not an assessment that happens regularly with their coworkers. The interviewer has to perform this assessment for a variety of candidates with different skill sets and backgrounds.</p>
<h2 id="familiarity-with-different-technologies">Familiarity with different technologies</h2>
<p>Candidates come from diverse backgrounds. If you hire a capable engineer, you will train them on your particular tech stack, but that will take time. In the hour or so you have to evaluate an experienced engineer, the most valuable data point you can consider is how they perform using the tools they are familiar with. After all, that’s the way they’ll work on your team in the long term.</p>
<p>So, it’s up to you, as the interviewer, to accommodate different backgrounds:</p>
<ul>
<li>
<p><strong>An obvious one is <a href="/2020/07/27/let-the-candidate-choose-their-programming-language.html">programming language</a>.</strong> Two weeks into the job, the candidate will have re-familiarized themselves enough with Java to be productive. But for the last few years, they’ve been working in Python, and they’ll be best able to show the command of Object Oriented patterns and problem solving using Python. Your job is to have enough familiarity with common programming languages to understand the code they’re writing.</p>
</li>
<li>
<p><strong>Familiarize yourself with different tools in the same space.</strong> Your company uses Kafka, but the candidate is more familiar with RabbitMQ. If you understand the landscape of message queues, you can better evaluate if the candidate knows how a message queue fits into a bigger system. The more you know about RabbitMQ, the better you can assess if they understand the trade-offs of RabbitMQ, and therefore how well they’ll understand why your company chose Kafka. Finally, by understanding the technologies on the candidate’s resume, you’ll know what their area of expertise is, even if you’ve never personally used those technologies.</p>
</li>
<li>
<p>Lastly, <strong>recognize different approaches to the same problem</strong>. Different businesses make different trade-offs. Interview problems often have different solutions. Just because the candidate approaches a problem differently than you doesn’t disqualify them. What matters is they can justify their choices, and that you can intelligently understand those justifications.</p>
</li>
</ul>
<p>Only by having a strong grasp of different technologies can you engage candidates on their own areas of expertise. That is, after all, where you’ll get the most useful signals about their technical ability.</p>
<h2 id="quick-comprehension">Quick comprehension</h2>
<p>Think about how you review code. You have to comprehend the code, verify it solves the problem it claims to solve and find any issues with the implementation that automated tooling wasn’t able to find. Evaluating a candidate’s code during an interview is like reviewing code, but faster paced. And that makes sense: if the candidate is writing code under pressure, you have to review code under pressure.</p>
<p>The consequence of this is you, as an interviewer, have to be really good at reviewing code. You, of course, need to know the candidate solved the problem correctly, even if they used an approach or coding style you didn’t anticipate. If they didn’t solve the problem correctly, you have to find the error quickly so you can <a href="/2020/03/16/were-in-it-together.html">help them get back on track</a>, or simply to note how close they got to the solution. This is especially important if <a href="/2020/11/16/getting-the-candidate-to-the-finish-line.html">the clock is running out</a>.</p>
<hr />
<p>I still believe an experienced candidate should not have to prepare for an interview, because the goal of the interview is to see how they would perform on the job, not how they perform in the interview itself. To make this possible, it’s crucially important for interviewers to step up their game and be exceptional at conducting interviews. And that means being exceptional technically.</p>
<p>At the end of the day, a candidate has one set of strengths. But you have to know enough to recognize all the combinations of strengths different candidates bring to the table.</p>Avik DasMore than even the candidate, the interviewer has a higher technical bar to meet. Photo by Markus Spiske on UnsplashPrepare your story2021-01-04T00:00:00+00:002021-01-04T00:00:00+00:00https://hiringfor.tech/2021/01/04/prepare-your-story<figure id="cover-img">
<p><img src="/assets/images/posts/2021-01-04-prepare-your-story.jpg" alt="A typewriter with a blank sheet of paper in it." /></p>
<figcaption>
<p>Figure out how you want to present yourself before the interview. Photo by <a href="https://unsplash.com/@florianklauer?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Florian Klauer</a> on <a href="https://unsplash.com/s/photos/story?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a></p>
</figcaption>
</figure>
<p>If you’re planning on starting or continuing your job hunt this year, the beginning of the year is a good time to consolidate your past accomplishments. Doing so allows you to control your story and therefore shape how an interview will go, all by presenting the right information about yourself at the right time.</p>
<p>As a bonus, I’ll also include a section at the end with some tips for interviewers.</p>
<h2 id="the-resume">The resume</h2>
<p>(Or your LinkedIn profile, or other representation of yourself.)</p>
<p>As an interviewer, <a href="/2020/12/07/getting-to-know-the-candidate-before-the-interview.html">I look at resumes to understand what experience a candidate has</a>. By doing so, I can ask them questions based suited to that experience, especially as it relates to their role within a project and the layers of the stack they worked in. For that reason, it’s good for a resume to tell interviewers where you are in your career and what your areas of expertise are.</p>
<p>Early on in my career, I worked on whatever was available, with limited leadership responsibilities. Over time, I took on larger projects and did more on each project. You can see this on <a href="https://www.linkedin.com/in/avikdas1990/">my LinkedIn profile</a>, comparing the descriptions of earlier roles vs. newer ones. Either way, here are some ways to streamline your resume and online profiles:</p>
<ul>
<li>
<p>If you didn’t have a large role in a project, as is typical earlier in your career, don’t make it seem like you did. However, be specific about what you worked on, namely the technologies and areas you worked in. This is helpful to pinpoint what you already know.</p>
</li>
<li>
<p>For projects where you had a larger role, still highlight your areas of contribution. For example, I make it clear I work on the backend, on distributed systems. You should also clearly communicate your role on the project, as you probably did more than write code. Use industry-standard terms, like “tech lead” or “architect”, for clarity if appropriate.</p>
</li>
<li>
<p>Finally, <strong>clearly state impact</strong>, no matter the role. Did you release a product? Did you grow a team or a tech stack from the ground up? What did you accomplish at the end of the day?</p>
</li>
</ul>
<p>The other consideration is how to treat different types of documents and online profiles. I try to be very comprehensive and visual with my LinkedIn profile, linking my writing and videos of my public speaking. With my resume, I trim everything down significantly to fit on one page, highlighting what people need to know at a glance. And <a href="https://github.com/avik-das">my Github profile</a> is more about what I’m interested in, to show the breadth of my knowledge, as opposed to career accomplishments.</p>
<p>All of these documents and profiles are ways to communicate to recruiters and interviews what your expertise is. And if those people are doing a good job, you’re more likely to be matched with the right role and interview questions. (And if they’re not, then a good profile won’t help anyway.)</p>
<h2 id="introducing-yourself-in-the-interview">Introducing yourself in the interview</h2>
<p>Once you’re actually talking to people at a company, you have a chance to really set the narrative. As an interviewer, I make sure to read people’s resumes, so I ask, “Is there anything else you’d like me to know about you?”</p>
<p>Whether or not the interviewer has done their research, focus on the most important parts of your career. Often, this will be your current role, as the technologies and product areas you’re involved in currently are the ones that are freshest in your mind.</p>
<p>Above all, get your story straight before the interview, so you can confidently introduce yourself.</p>
<p>If I were hypothetically looking for a job, here’s my two-minute introduction as of January 2021:</p>
<blockquote>
<p>I’ve been working at LinkedIn for the last two years, and I’m a tech lead within the Messaging team. I work on both the foundational backend platform that powers messaging across multiple products at LinkedIn, as well as the APIs backing the flagship messaging product most people are familiar with. On the flip side, I’ve worked at small startups, building products and teams from the ground up. Even though my experience is primarily on the backend, I’ve worked on both web and native mobile apps, as well as in offline processing.</p>
</blockquote>
<p>Good interviewers will have a back-and-forth with you about your experience, so I would start by hitting the main points first, instead of trying to be comprehensive.</p>
<h2 id="what-about-the-interviewer">What about the interviewer?</h2>
<p>As an interviewer, this is a good time to reflect on your role within the company you’re interviewing on behalf of. After all, you also need to introduce yourself at the beginning of an interview.</p>
<p>A lot of the same advice as above applies, but focus on how you fit into the team and the type of the work goes on within that team. You’re representing your team, so your introduction isn’t solely about you anymore. Here’s my standard introduction during interviews:</p>
<blockquote>
<p>I’ve been at LinkedIn for the last two years, though I was here before, left to do some startups and came back. I work on the Messaging team, on two parts of the stack. First, I work on the foundational backend platform that powers messaging all across LinkedIn, which stores and delivers messages. However, I primarily work on the APIs backing the flagship messaging experience, which is what you see when you go to linkedin.com or open your LinkedIn app.</p>
</blockquote>
<p>I introduce the team and what the team does. The impact of the team is important, my specific contribution to the team less so. Finally, I give a little bit of my background so the candidate knows what experience I bring to the table, as well as give confidence that LinkedIn is a good place to work, given that I’ve come back after leaving.</p>
<hr />
<p>How you present yourself in an interview sets the framework for how you will be evaluated. For that reason, it’s important to reflect on your accomplishments and take note of the areas you have expertise in. If you present yourself as knowledgeable about certain areas, a good interview process can give you a better chance of showing your strengths in those areas.</p>Avik DasFigure out how you want to present yourself before the interview. Photo by Florian Klauer on UnsplashMy optimism for tech hiring in 20212020-12-28T00:00:00+00:002020-12-28T00:00:00+00:00https://hiringfor.tech/2020/12/28/my-optimism-for-tech-hiring-in-2021<figure id="cover-img">
<p><img src="/assets/images/posts/2020-12-28-my-optimism-for-tech-hiring-in-2021.jpg" alt="A road going off into the distance in front of the viewer" /></p>
<figcaption>
<p>The road ahead is not straightforward, but I see opportunities. Photo by <a href="https://unsplash.com/@aows?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">adrian</a> on <a href="https://unsplash.com/s/photos/motivation?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a></p>
</figcaption>
</figure>
<p>Last week, I talked about <a href="/2020/12/21/looking-back-at-hiring-for-tech-in-2020.html">what I’ve learned about tech hiring in 2020</a>. Again, because I expect lower than usual readership over the holidays, I’ll keep today’s edition light. Let’s talk about where I think tech hiring is headed in 2021:</p>
<ul>
<li>
<p>The COVID-19 pandemic changed how we work, and as the world slowly comes back to some semblance of normalcy, the tech industry has the opportunity to rethink how it hires. The measures put in place to accommodate remote hiring and a stress-filled environment can continue paving the way to accommodate all types of people in the future. My optimism is somewhat tempered by the prospect of the pendulum swinging in the other direction as a reaction, causing companies to become more cut-throat as previously unemployed workers re-enter the job market.</p>
</li>
<li>
<p>People have always been talking about hiring, but I see a lot of actionable advice floating around now. I’ve tried to compile other people’s perspectives in this newsletter, as well as offer my own actionable advice. I’m hoping to see even more people speak out about what effective hiring looks like.</p>
</li>
<li>
<p>Finally, putting these two points together, I’m looking to make a material impact in the future. Certainly, if I start a company or join a startup again, I’ll use the advice from this newsletter to set up an equitable hiring process. But even within a big company, as hiring slowly opens up, I’m talking within my team to see what changes we can make going forward.</p>
</li>
</ul>
<p>Tech hiring can get better in 2021, but only with deliberate effort. Without this effort, the setbacks we had this year will only get worse.</p>
<p>If you’re interested in making a change in your company, but don’t know how, reach out to me. I would love to help you implement the ideas in this newsletter in your organization.</p>Avik DasThe road ahead is not straightforward, but I see opportunities. Photo by adrian on UnsplashLooking back at Hiring For Tech in 20202020-12-21T00:00:00+00:002020-12-21T00:00:00+00:00https://hiringfor.tech/2020/12/21/looking-back-at-hiring-for-tech-in-2020<figure id="cover-img">
<p><img src="/assets/images/posts/2020-12-21-looking-back-at-hiring-for-tech-in-2020.jpg" alt="A person standing on a street, looking down at a puddle on the ground. The sky is reflected in the puddle." /></p>
<figcaption>
<p>The end of the year is a good time to reflect. Photo by <a href="https://unsplash.com/@marcojodoin?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Marc-Olivier Jodoin</a> on <a href="https://unsplash.com/s/photos/mirror?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a></p>
</figcaption>
</figure>
<p>Because many of my readers will be on vacation this week and the next, I want to keep these two editions light. I’ll be back in January with the usual content.</p>
<p>This week, I want to reflect on 2020. I wrote my first edition of Hiring For Tech <a href="/2020/02/03/whats-wrong-with-tech-hiring.html">back in February</a> when COVID-19-related restrictions hadn’t yet taken over the US. My goal was to look at each interview I conducted and find the gaps I knew were present in the hiring process. But within a month of launching the newsletter, I started working from home and the tech industry either stopped or slowed down hiring significantly.</p>
<p>Still, I’ve learned a great deal, so let’s take a look back at the last 10+ months of writing:</p>
<ul>
<li>
<p>Many of the tech industry’s inability to accommodate a diverse group of people have been highlighted this year. Whether it’s the <a href="/2020/05/25/letting-the-little-things-slide-remote-interview-edition.html">sudden stresses of the pandemic</a> and the shift to remote work, or the push to <a href="/2020/06/01/speak-up.html">dismantle system imbalances</a>, equitable hiring is more important than ever.</p>
</li>
<li>
<p>People see the need for a better system, and they’re speaking up. By setting out to write about tech hiring, I’ve found others who have published articles on the same subject, or <a href="/2020/08/03/reducing-interview-stress-with-independent-work.html">even done academic research</a>. The conclusion is the same: the current interview process excludes talented people, and that needs to change.</p>
</li>
<li>
<p>The same topics come up again and again in the discussions about tech hiring. Writing out my thoughts on a regular basis has given me a library of articles to reference whenever these conversations arise. My favorite moment was when a reader had some questions and thoughts about improving the hiring process, and I was able to link to past articles on each and every topic they brought up.</p>
</li>
</ul>
<p>In next week’s edition, I’ll outline where I see tech hiring going in 2021, and how I plan to be a part of that future. Until then, happy holidays!</p>Avik DasThe end of the year is a good time to reflect. Photo by Marc-Olivier Jodoin on Unsplash