Preparing for Success: A Frontend Engineer's Guide to Tech Due Diligence

Rate this content
Bookmark
Slides

Imagine being a knight preparing for a jousting tournament, but your horse is more interested in the fair's hay bales than your impending duel. That's what prepping your tech department for an investment round or exit can feel like sometimes. This talk provides an in-depth look into the role of a frontend engineer, especially working with React, in preparing a tech department for an investment round or an exit. Through a unique lens of tech due diligence, the presentation uncovers the importance of good practices, solid architecture, efficient documentation, and more.

32 min
08 Dec, 2023

AI Generated Video Summary

Tech due diligence is a thorough examination that can influence a product or company's future, involving analyzing technical architecture, code base, team culture, and more. Front-end engineers play a crucial role in bridging design and functionality. Automation, infrastructure, and documentation are key areas in tech due diligence. Best practices, clean code, and market connections are important for selling. Tech due diligence requires data access and security measures, and companies may be hesitant to fully cooperate.

1. Introduction to Tech Due Diligence

Short description:

Before we dive deep into the world of tech due diligence, let me share a bit about who I am and my experience in frontend engineering. Our role at Tech Miners is to guide and uplift businesses through data-driven tech due diligence. We will familiarize ourselves with the essentials of tech due diligence and provide practical insights on how to prepare for the process.

All right. Before we dive deep into the world of tech due diligence, let me share a bit about who I am and my experience in the realm of frontend engineering. And don't worry, I plan to keep things light. A nice change of pace from the more technical talks you might be used to during the React Day Berlin.

My name is Armin. Over the years, I have worked on various projects, using React extensively, and I have seen firsthand how the decisions we make as frontend engineers could shape the trajectory of a product, team, or even the entire company. So let's move to the larger picture here. What drives us at Tech Miners and how it lays the foundation for our today's talk. At Tech Miners, our role isn't just to evaluate, but to guide and uplift. Our unique approach to tech due diligence is data-driven, diving deep into processes, people, and technology. We have assisted countless businesses in preparing for significant milestones, from investment rounds to exits.

But all this talk about tech due diligence might have you wondering, what it is really? So let's demystify that. Our presentation today is structured into two primary segments. First, we will familiarize ourselves with the essentials of tech due diligence, what it is, and why it matters so much in our role, in our field role. Following that, we will dive deep into some practical insights on how we can effectively prepare ourselves for such a process. So by the end of our talk, I hope you will not only be understanding the tech due diligence better, but also you already have some ideas on how to improve your work, whether it could be your team or your product.

2. Tech Due Diligence Overview

Short description:

By the end of our talk, I hope you will understand tech due diligence better and have ideas to improve your work. Tech due diligence is a thorough examination that can influence a product or company's future. It is critical for investors to understand the technology's robustness and scalability. The process involves analyzing the technical architecture, code base, team culture, product scalability, tech stack, tech assets, product management, development roadmap, and legal/IP section. The outcome is a detailed report identifying strengths, weaknesses, opportunities, and risks. Red flags indicate serious problems that can impact a company's technology operations and business success.

So by the end of our talk, I hope you will not only be understanding the tech due diligence better, but also you already have some ideas on how to improve your work, whether it could be your team or your product.

So before we start, I want to ask you a question here. Hands up if you are already familiar with what tech due diligence is. Alright, five, six maybe? That's pretty cool. That's why I'm here. So don't worry. I expected that.

The truth is, in the fast-paced world of software development, whether you're part of a nimble startup, hungry for its first round of funding, or a key player in a well-established tech giant, considering it a strategic acquisition, the concept of tech due diligence is one you are most likely to encounter at some point in your career. We have various forms of due diligence, but today our spotlight is on TechDD, which directly involves us as software engineers.

So tech due diligence isn't just a box to tick. It's a thorough examination that can influence the future direction of a product or the entire company. Of course, on the other hand also, it is quite critical for investors, stakeholders, and potential buyers to understand the technical robustness, scalability, and future-proofing of the technology that underpins the company that they are really interested in.

A typical robust, let's say, TechDD involves several key steps, from starting with a kick-off session to define the scopes and objectives, to the thorough analysis of the technical architecture and code base. The process is usually spread over a few weeks to ensure an in-depth analysis without significantly interrupting the company's daily operations.

The areas which will be explored during a TechDD are tech team, team culture, of which are here, the product scalability, tech stack, of course, what frameworks they're using, languages, choice of tools. Tech assets, which is basically where we gain access to the data, get as much data as possible we can, and process them to extract some insights from. Product management, product development roadmap, maybe also even a competitive analysis. And lastly, legal and IP section, which could be quite critical for companies maybe in the sector of cybersecurity or insurance, let's say.

The outcome of a TechDD is a detailed report that provides insights into the technical health of a company. It identifies strengths, weaknesses, opportunities for improvements, and potential risks. Findings are almost the most important element of any TechDD report. In this context, a finding refers to a significant piece of information that has been uncovered during the TechDD process. Each finding is data-driven and often supported by visual aids, like charts for better understanding. They look at different things, like how serious a problem is, or whether it could be solved easily. This approach, of course, help us to sort out which issues are big deals and which ones aren't, and to spot any major concerns or red flags.

Red flags in TechDD diligence are essentially a combination of issues or findings that signaled potentially serious problems with a company's technology strategy or implementation. Red flags aren't just some simple alerts. They are evaluated based on how easily it can be fixed, the amount of effort and resources needed to address the issue, and the estimated duration for resolving the problem. Although it is not, I would say, although it is not relatively frequent for any company undergoing a TechDD to have a red flag, what's having a red flag is something to definitely vary off, because they could significantly impact a company's technology operations, and by extension, its business success.

Not that we have understood the concept of TechDD, you might wonder, where do I, as a software engineer, fit into this picture? So let's unravel that.

3. Front-end Engineers and TechDD Preparation

Short description:

Front-end engineers play a crucial role in bridging design and functionality. To prepare for TechDD, familiarize yourself with the process and understand the importance of code infrastructure. Real-world examples will provide insights into common issues. Remember that red flags and findings are relative. Now, let's dive into the critical area of dependencies and licenses, where open-source doesn't always mean unrestricted use. Understanding licensing and maintenance is essential.

Front-end engineers, like many of us here, are the bridge between design and functionality. Our role is pivotal, but how does it interwine with TechDD? You are all like, as if being a software engineer wasn't already like you walk in the park, endless coding, keep up with the ever-changing stack, like I'm talking about two major releases of Next, I guess, every six months, right? Yes, you are already familiar with that. But don't worry. You don't actually need to do too much extra to be prepared for a TechDD. That is, of course, if you're already doing things right. So let's get to the how to get prepared part.

Preparation is the key success in almost every endeavor. In the realm of TechDD, our code infrastructure lays the foundation. The examples which we're going to explore in the following few minutes are among the most significant or commonly overlooked issues based on our experience from the real-world TechDD. I believe this approach will help us gain a better understanding of how this looks like in practice and how they can impact the tech environment. It is crucial to remember, however, that red flags and findings are highly relative. Same issue or finding could be in the situation of one company a really big deal, a huge case, but the same problem could be like nothing really important, of course, again, based on the company situation. So that's why each situation demands a tailored response, considering unique characteristics and needs for the company. So let's get prepared. The very first part of getting prepared for anything is to get to know the thing itself. Here is also no exception. Luckily, we are already familiar with the essentials of TechDD diligence, like its steps, goals, and what it looks for. So the first step is already done. It wasn't hard, right? So till here, a quick recap. We do TechDD. You learn what is TechDD. Now we're going to see some real-world examples from our TechDDs, and that will help us getting prepared better for such a process, or generally getting better in that thing. Now, let's dive deep into our first section, dependencies and licenses.

This is critical area in TechDD diligence, especially for SaaS products. The key thing here to remember is open-source doesn't always equate to free to use without any restrictions. Misunderstanding this can lead to significant legal risks and potentially turn into a red flag all on its own. That was a little bit of a delay. All right. So it's not just about using them. It's about understanding the licensing, keeping track of their updates, and knowing their maintenance status.

4. TechDD Example, Automation, and Documentation

Short description:

Consider a scenario where over 40% of a project's dependencies require major updates. This chart not only flags potential security risks but also indicates a need for the development team to enhance their monitoring and update processes. The choice of open-source licenses needs careful consideration. Let's put our attention to automation and infrastructure. Monitoring, license automation, and pre-commit hooks are crucial. Shortcomings are expected, but unsolvable issues in the future are a concern. Thorough and accessible documentation, especially technical onboarding material, is essential.

Actually, let's have an example here. Consider a scenario where over 40% of a project's dependencies require major updates. What does this chart tell us about? If you'll see it, it's like this chart not only flags the potential security risk within a product, while we have like 40 more than 40% of the libraries needing major updates, but also indicates a need for the development team to enhance their monitoring and update processes. Moreover, the choice of a certain open-source licenses needs careful consideration. That's because using some licenses without a solid reason can be risky, potentially affecting business operations and compliances. So we watch out that part.

We all might just know about MIT license, which we use daily, but it's definitely helpful to get to know some other open-source licenses and their implications. Moving forward in our How to Get Pre-Purchased series, now let's put our attention to automation and infrastructure. The goal here is almost clear, like to automate as much as possible. The benefits of automation in tech is well known for all of us. Efficiency, consistency, scalability. However, there are certain aspects that can raise red flags.

First, let's talk about monitoring. Is the company's approach reactive or proactive? Do they have real-time messaging systems in place to notify them immediately of problems? Because this is of course really crucial for timely responses to the issues, right? Circling back to licenses, automating license monitoring is definitely a smart move. That's because licenses not will change, but can change during the time, and the change actually can affect our product really very heavily. So let's keep that in mind. Some ports appear could be implementing pre-commit hooks in pipelines. This can prevent many issues by ensuring that the code meets some certain standards before it's getting merged. Lastly here, I see it important to mention that in a tech D.D. process, some shortcomings are totally expected and acceptable, of course depending on the company situation. But the thing is, it's not about not having any issues. It's about not having unsolvable issues in the future. Interestingly, if a startup appears too perfect, itself could turn also into a red flag.

Now let's shift our focus to documentation. This old saying perfectly captures the often overlooked importance of thorough and accessible documentation in technology processes. How many of us here rather write code than documentation? Hands up. See, we all agree with that. This often leads to a scenario where in startups, documentation might be almost nonexistent, which is acceptable in some cases. But surprisingly, even in larger companies, it's not uncommon at all to find significant gaps in technical documents. I'll say, one of the most critical types of documentations is technical onboarding material. Considering how frequently startups change their teams, it's ideal for a onboarding document to be comprehensive enough so that a new engineer could start meaningfully contributing to a product within the first month or two.

5. Documentation, Frameworks, and Code Quality

Short description:

While tools like Google Drive and Google Docs have their place, they fall short in searchability and indexing. Documentation should be centralized for knowledge accessibility and availability. Choosing frameworks and tools requires informed choices based on justifiable reasons and consideration of maintenance costs. Code quality relies on consistency, automated tools like ESLint, and avoiding hard-coded values and configurations for security and maintainability.

While these tools have their place, of course, they fall short in areas like searchability and indexing. Too often we see important documents dispersed across platforms like Google Drive, Google Docs, which make it hard to find information when needed. If you're asking us about ideal approach, when it comes to documentation, it's all about knowledge accessibility and knowledge availability. Documentation should be centralized, ensuring that there is there when we need that. Assigning an owner to each document can definitely help maintain accountability and keep the information up to date. And even we can integrate documentation creation into your development process. Maybe even put it in your definition of done in your tickets and stories. I'm pretty sure that would be a perfect place for that.

Next up is a choice of frameworks and tools. Typically, the choice of frameworks or language isn't itself a big deal, as most have long-term supports. For instance, even a language like COBO, seemingly outdated, isn't an automatic red flag. However, the rationale behind choosing such older technology is what matters. Is there a strong justifiable reason for its use? Or if it's outdated, is there a plan in place for migrating to more modern technologies? Let's put our attention to another example in this area. Imagine a case that a company should choose between native mobile application development compared to hybrid solutions like React Native. If the company, in this case, goes for the first option, it needs to be backed by solid reasoning considering higher maintenance costs of the native mobile application development compared to hybrid solutions. So after all, beyond just picking a library or framework or a package, it's about making informed choices. Generally speaking, it is best to avoid reinventing the wheel and opt for well-established, widely supported frameworks, unless there's a compelling need for something more cutting-edge or older, let's say.

All right, we have reached the last step. In the last step, let's turn our attention to code quality in our take to diligence preparation. A critical aspect of a code quality is ensuring consistency across the board. This is where automated tools like ESLint become invaluable. Coupled with Comethooks, these tools help maintain a consistent coding style throughout the team, making the code more readable and of course more maintainable. We often come across the issue of hard-coded values and configurations. This includes case like customer-specific hard-coded configurations or hard-coded secrets within the code. Although it's a very common frequent problem, we see that a lot, it's the one that could be really, really easily fixed, yet frequently overlooked. For front-end development, maybe us front-end engineers, we remember that any secrets used on client-side devices can pose a security risk, considering that most front-end applications are being built and served on the client-side. Of course, there are some exceptions. I love tools like Next.js, Remix, BigFan. But generally, if you try to keep the secret as far as possible from the client-side, you should be safe. So the focus here is not just on writing a good code, but on writing secure, scalable and maintainable code.

6. Tech Due Diligence and Findings

Short description:

Always remember the importance of taking diligence seriously. Differentiate between software development best practices and tech due diligence. Tech due diligence ensures the robustness of a company's technology operations. Best practices contribute to a healthy product. Findings in the report are data-driven, backed by charts and examples. The oddest finding during tech due diligence was copy-pasting jQuery in React.

And just to keep things in perspective, always remember this piece of advice. The next person reading your code might not be a junior, but a senior serial killer, and he knows where you live. With this amazing news, we have reached the end of our journey. I hope this session provided you with a clear perspective on the importance of taking the diligence and unrolling it. Thanks for your time and attention.

Where do we want to start? Maybe let's differentiate between software development best practices and take due diligence.

Of course. Where is the difference? Because this could also be like, hey, best practices for software development.

Sorry, I didn't get your question. I mean, all of that stuff also applies for like a general software development. If I don't want to prepare like an acquisition.

Exactly. So yes, the whole thing about taking due diligence is like, I mean, when we do take due diligence, because we want to know if a technology is robust, which is, I mean, the technology operations of a company is robust enough to invest or acquire or whatever. Or even a take due diligence could be a health check. Just for example, a CEO or a CTO wants to know if everything is going right within their company, right? Mostly CEOs. And of course, having a healthy product, I mean, best practices are there for that, right? And that's the whole purpose of having best practices.

And when you write the report, how do you actually formulate like some findings you have? Do you say, OK, well, the code base looked a bit odd and they didn't follow the practices?

Basically, well, I would say each company does take due diligence a little bit different. But generally what we do actually is, as I mentioned also in the talk, all findings are data driven. So we either have like proper data or proper case to show or examples. And they are mostly coming with some charts provided by our in-house tools and amazing data engineers.

And if you write the report, like what's the oddest stuff you did find during take due diligence?

Ah, that's a good question. First of all, I need to clarify here that I myself don't do take due diligence because in order for you to be able to do it, you need to have like really a huge experience behind you. Right. So what we do actually, we have like an amazing SCA team which have like more than 50 years of CTO experience. And they are actually the main leader of each take due diligence, because in order to like, by looking at the chart or data and insights, they just have a gut feeling of if everything goes fine or not. So it definitely needs a really rich background. What I do actually, I am mostly working on the in-house tools that we have and engineering. But I definitely face cases, I would say maybe, I don't know, something is top of my mind, copy pasting jQuery in your React. Okay. I just remember that at the moment.

7. Tech Due Diligence Process and Best Practices

Short description:

Take due diligence is highly relative and involves data analysis as well as in-person interviews with senior software engineers, tech leads, and managers. Best practices for tech due diligence may vary depending on the niche market and location, but striving to be the best is important. When it comes to documentation placement, prioritize accessibility and availability. The responsibility of driving tech due diligence within a company can fall on engineering managers or CTOs, depending on the company's situation. Gaining more experience in tech due diligence involves following best practices and researching documentation and infrastructure automation.

Okay. And if you find that like, how do you respond to it? And do you try to like improve the situation with like the clients? I mean, as I mentioned, take due diligence is highly relative on the company, right? I mean, it's not just that we get access data and we analyze them. There are also lots of interviews, as you've seen in the processing slides. SDAs will actually have, they have in-person interviews with like senior software engineers, tech leads, managers. So it's not just data that we have, but if they see something in the data and the code base, they would definitely, will discuss it in the interviews. And if they are not convincing yet, of course something is wrong. Yeah.

And you mentioned that it's highly dependent on the company, but is there any agreed on best practice to do this and how much do they differ? I would say not really, because it's, it's, it's a really niche market, right? I mean, you don't expect, I mean, it depends on where are you working actually, what is your market, but it's, it's not a really huge market and therefore there aren't also like many big players out there. But we try to do our best, we try to be best, at least in Europe. That's a good, good thing.

And maybe we can move on to some practical examples. Sure. Like, like do we have like a guideline on where to actually place the documentation, what should stay in the repository and what should get, go into some company wiki? I would say it's whatever works best for your team and again, data should be accessible and available when you need it. I think by just having these two points, everything should be fine. Like it doesn't matter actually what tools you're using. Of course, if it's a, if it's a tool that has a, like, I don't know, huge learning curve and all of your teams cannot keep up with that, that's a problem. But generally, yeah.

About keeping up with stuff, like you should drive the tech TV stuff within the company, it should be like an engineering managers to make sure that it's all followed or should it be the singular developers? And how do you educate the rest of your company about like best practices related to that? You can also read the question, because I didn't get your question. Like, could you elaborate more on that? Yeah. So I think like a lot of us are wondering, like, who should drive this in the company? Should it be a grassroots effort from the engineers? You mean, you mean the very person which is the first point of contact in the process of take due diligence? There are usually like CTOs. And so the CTO should ensure like long term that his company is ready for that? Actually, it depends. Like if they are, if they expect to raise some funds in their future. I mean, based on their situation, as I mentioned, again, it's highly relative everything here. That's why super experienced guys living every tech TD with lots of like background and being in industry for like, you know, 10 or 20 years. But yeah, actually, that's the reason. So it's highly relative. But again, if they expect something like that, they could be prepared. And what's the best way to get more experience there? If you want to like move up into that path? I mean, it wasn't like something magical happening there. It was all the points that I mentioned, you can easily find them if you search like best practices about documentation or best practices about, I don't know, infrastructure automation.

8. Selling Best Practices and Data Privacy

Short description:

It's important to follow best practices, have clean code, and prioritize market connections and networking. Companies often undergo technical diligence to secure funding. Automation tools like Dependabot and Sonar can help with license checks and monitoring. In terms of data privacy, companies share information necessary for the due diligence process, and measures are taken to ensure data is used appropriately.

It was all the points that I mentioned, you can easily find them if you search like best practices about documentation or best practices about, I don't know, infrastructure automation. Or basically, there are like tons of articles out there about best practices. And what I just mentioned in this talk was like the points that we frequently face. And it wasn't just wanted to like mention, because we can also like feel that better. But generally, it's following best practices, have a clean code, like I'm in this like, among the things that we all know as principles of being a software engineer, right? So it's not something magical happening there.

And how would you sell that non-magical stuff happen to non-technical people in the company to me to make sure that they are like, willing to spend the business? That's a good question. I mean, I mean, I thought we have engineers here. But I'm joking. Basically, sometimes I mean, I don't know if it's correct to say most of the times or not. But this market connection and networking is really important. And most of the times you have like a client, which is maybe a VC want to invest and a target company, which wants to for example, in this case, imagine that wants to raise some funds. So the target company has no other choice if they want the fund, they need to undergo technical diligence. And how do VCs choose us? Maybe because we're the best maybe. Well, I mean, I guess no other choice then. And I guess you just said that there might be some developers in the audience. I think we all as developers, we love automation and tools. And there's definitely tools for like doing license checks and stuff. And do you have any recommendations there? And do you also have like a general tool recommendation how to track your own?

Yes, again, again, if you can search for those tools, there are like, lots of them out there, you can actually compare and choose the one based on your situation that fits your company the most. But the most famous things out there for example, depend upon maybe it's a, it's a, it's a bot that you can integrate in your GitHub workflows. And it will just check if you have like any outdated dependencies and it will just create automated PR so you can review and merge that. Making things much more easier, you don't need to always check everything. And anywhere there it will say you if for example, this update has some fixing some critical security vulnerability or not so lots of good inputs there. We can include other tools like Sonar maybe in your, if you're already aware of that, in your development pipelines, it's also like tons of features, one of them could be monitoring. Okay, and let's close with like one last question. Especially in the EU like data privacy is getting more and more and more important. And you said like you actually analyze data for companies you're looking into. So like what are the companies allowed to share with you? And how do you make sure that that data is like only used for your process? Again, I would like to mention that. I mean, if a company for example, imagine a case you have a company you want to raise some funds, raising funds is not easy, right? And if you find a VC and the VC wants you to undergoing a Tech TD, and then finds you, you will definitely undergo Tech TD. So it's like, somehow, most of the times, it's for the best undergoing Tech TD. And therefore, they have to like cooperate.

9. Tech Due Diligence Data Access

Short description:

Some companies may be hesitant to cooperate fully, but we ensure data security and anonymity through NDAs and strict European regulations. In tech due diligence, we aim to access as much data as possible, including source codes, ticketing systems, organizational charts, and more. Automated processes help us analyze large codebases and identify important files and business logic. If you have further questions, please proceed to the speaker Q&A.

And of course, some companies, they, for example, don't cooperate, like in a good way. Maybe they don't want to give up some critical data. But I mean, we are signing NDAs, everything is legal. There's no concern about like data leakage or anything like that. Everything is anonymous. I mean, we are living in Europe, right? We have strict rules about that.

But generally, if speaking about, if you want to know what datas we usually get access to, in the best case, I would say everything possible, like from access to all the source codes, every process source codes. And we have like lots of different data engineering processes out there, which can extract some amazing datas and insights. From ticketing systems, there are like valuable insights hidden into ticketing systems. We can like gather much knowledge about that. And an organizational chart, maybe the salary structure, like basically everything may be in between of a Tech TD process. Also, STAs could ask for a significant documents, maybe again, to ensure about something. So anything would be, I mean, the more data, the better we can. Well, that's probably 25th century. The more data, the better.

One last question from me there. You're saying you also want the source code, but how deep do you actually go into like single lines in the source code analyzer? Do I need to like be thinking, be scared that Amin's going to come around and check my Monday morning source code? Actually, I mean, sometimes a company either going to Tech TD could have like tons of repositories, millions lines of codes, and it's definitely not quite efficient to go over all of them, right? So we have automated processes like automate, we are actually going through codes like within the data processes that we have, and we gather some insights like, for example, I don't know how detailed I am allowed to go, but for example, we can understand maybe which file could be like hotspots maybe, or generally even STAs. I mean, if you're an experienced guy, you could like figure out somehow which file is important, which is not, which contains some business logic, important business logic, and have a look at that. That would reveal so many things.

That sounds super interesting, but we need to close down here. But if you have more questions, you can go to the speaker Q&A now.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Summit 2022React Summit 2022
27 min
Impact: Growing as an Engineer
Becoming a web engineer is not easy, but there are tons of resources out there to help you on your journey. But where do you go from there? What do you do to keep growing, and to keep expanding the value you bring to your company? In this talk we’ll look at the different kinds of impact you can have as a web engineer. We’ll walk through what it means to take on bigger, more complex projects, and how to scale yourself, and grow the community around you. By driving our own development we can all grow our impact, and in this talk, we’ll discuss how to go about this.
TechLead Conference 2023TechLead Conference 2023
25 min
On Becoming a Tech Lead
Tech lead sounds like a lot of work. And not the fun coding kind either. Why would you ever want that? What does it feel like when you get it?In this talk Swizec explains why he took the step towards technical leadership, how his priorities changed, and why it means he’s doing more engineering than ever. A whole new world where writing code is the easy part.
10 min
Emma Bostian: I landed my dream job by sharing my blogs on Twitter
Featured Article
Software engineer, lecturer, podcast host, author — is there something Emma Bostian hasn't done? She moved from America to Sweden, started working at Spotify, and took up a few challenges along the way. And now she has some career tips to share.

What led you to software engineering? 
I was raised in the ecosphere of tech because my dad is a software engineer at IBM, and my mom was a designer there, too. My dad always encouraged me to join STEM and take a look at computer science — however, I was convinced I wanted to be a medical doctor. In my first year of college, I declared a biology major and quickly realized I was not too fond of it. In my second semester, I switched to an actuarial science major where I took Introduction to Computer Science, and the rest is history. In my second year of college, I declared a computer science major and began my journey from there.
What is the most impactful thing you ever did to boost your career?
Writing blog posts and documenting my learning journey on Twitter has far been the best career boost. I wrote purely for myself to reference the things I learned over time, and I even utilized my design skills in Figma to create custom graphics depicting difficult concepts like CSS specificity. By sharing my blogs on Twitter and engaging with the people reading them, I was able to grow an audience extremely quickly. I began receiving conference speaking opportunities, podcast requests, and course invitations to teach with LinkedIn Learning and Frontend Masters.
Ultimately, I landed my job at Spotify through Twitter, too, when a friend and follower of mine asked if I would be interested in interviewing. Now I live in Stockholm working my dream job. It still blows my mind how tweeting about my blog led me to some of the most amazing career opportunities.
What would be your three tips for engineers to level up their career? 
First, be patient. I often see posts on Twitter or LinkedIn about developers who were promoted to a senior position after a year. And while this is wonderful, I think we forget that each company has a different standard for what constitutes a senior developer, and everyone's journey will be different.
Second, don't be afraid to ask questions. If you try your best to solve a problem or answer a question you have, but you can't figure it out after a reasonable amount of time, ask a team member or mentor for help.
And lastly, invest in the right resources for learning. When I started my journey, I didn't know which platforms worked for me to learn. Now, I have a few trusted platforms such as Frontend Masters, Free Code Camp, or Level Up Tutorials that I go to when I need to learn a new skill.
You're currently working as a software engineer at Spotify. What does a typical day of yours look like there?
I begin my day answering emails. Then we have a team breakfast and a standup remotely as we're all still remote at Spotify. After that, we might have a web tech sync with the other squads in our business unit. The day usually includes some form of pair or mob programming, depending on the work stream. 
My team always has Fika, a traditional Swedish coffee break, scheduled every afternoon. Every couple of Fridays, we have team games planned to release some stress. 
Also, I tend to have a lot of free time to focus, which is nice but makes for a boring answer to this question!
Do you have some rituals or tools that keep you focused and goal-oriented?
I'll admit that I've been struggling with staying motivated in the time of remote work. I've been remote with Spotify since onboarding a year ago, but my team is wonderful, and they help me when I'm down.
Apart from that, I use Todoist to keep track of my tasks, and, naturally, I listen to Spotify while working. But other than that, not really. Maybe I should adopt some new tools to keep me on track!
My current favorite Spotify playlist is Brand New Chill: https://open.spotify.com/playlist/37i9dQZF1DX6uQnoHESB3u?si=380263b3c853442e
I also love Chillout Daily: https://open.spotify.com/playlist/7ozIozDp260fjNOZy1yzRG?si=66d6c839ec9b458a
You wrote a book called De-coding the Technical Interview. What was the impulse to do it?
I wanted to give the community a manual of the essentials of computer science knowledge to ace the technical interviews. The book covers data structures like stacks, queues, or linked lists, tackles algorithms, and deals with systems design. You'll also learn about the interview process from start to finish, get tips on how to submit an amazing take-home project, or understand how to problem solve. You'll also gain knowledge on the frontend coding skills needed to excel at a frontend interview.

If you could stress one piece of advice on surviving a technical interview, which would it be?
Do not lie your way through an interview. If you don't know the answer to something, just admit it. There's no shame in admitting you don't know the answer to something. There is shame in faking it and pretending like you do know the answer.
What's the single best practice everyone who writes code should follow?
Remember that while you are technically writing code for computers, you're also writing it for humans. Your code should be readable and have as little complexity as possible without sacrificing accessibility or performance.
In addition to the book, you co-host the Ladybug Podcast. What inspired you to enter this field, and what are the podcast's main topics?
We talk about everything tech and career on the podcast, from Java and GraphQL to how to start a business and cross-cultural communication. The podcast is a way for me and my co-hosts to share our experiences in tech, having taken different paths. And I'm really glad for doing it — it has allowed me to meet so many incredible people, learn many new things, and support my dream of teaching.
What pieces of your work are you most proud of?
My technical interview book was a huge feat for me as well as my courses with LinkedIn Learning on building a tech resume. I enjoy creating things that help other people advance their careers, so I'm also proud of my courses with Frontend Masters on design systems and CSS.
***
Follow Emma on Twitter
14 min
Kent C. Dodds: Consume, build, and teach — and level up your career
Featured Article
Even though his bio offers quite a hefty reading, he only applied for one job in his career. The rest came along as he was building his name as a renowned speaker, teacher, and a prolific figure of the open-source community. How did Kent do it? “Commit to creating high-quality content,” he says.


What led you to programming?
I had a friend when I was a teenager who was really into it, and he tried to teach me. But I just couldn't get it — it didn't make any sense to me. So I never really thought I'd get into programming, but I liked computers a lot, and I ended up going to school for electrical engineering. 
Well, that didn't work because I'm not good at math. But right when I started the program, I got a job at a company uploading videos to YouTube and that sort of thing. The work was tedious, so I decided to write a computer program to automate lots of the work I was doing with the knowledge I had about programming. And that was the first spark of things for me to use programming to solve real-world problems. 
What is the most impactful thing you ever did to boost your career? 
Committing to creating high-quality content. That might sound obvious because I'm a full-time educator now, but I would not have gotten my job at PayPal if I hadn't been so active with my blog. In fact, lots of my jobs came out of me being involved in the community around meetups, conferences, or open-source projects. 
How do you choose topics for the content you create, be it for your blog or podcast?
I don't think too much about the content other people are creating. And I don't often consume it. My ideas come from the things that I'm working on, things that I'm learning myself, or — when I was working with a team of developers — the things that I had to remind people of in code reviews regularly. Anytime that I would have a code review comment that was pretty long to describe my position, that was an excellent opportunity for a blog post. Also, if people ask me about a topic regularly, I'll make a blog post rather than answer that question multiple times.


What would be your three tips for engineers to level up their career? 
The number one thing I tell people is to be a nice person. I know that sounds fluffy or silly, but it cannot be overstated. You will get so much further in your career and just in life in general if you're a nice person. That doesn't mean that you take people being jerks lying down, but how you interact with others is out of kindness. You could be the best engineer in the entire world, but if you're not a nice person, you will not reach your full potential or accomplish your goals, whatever they may be.
Second, it's just as important to decide what you are not going to learn as it is to decide what you are going to learn. You could jump into countless things — and there are successful people who are polyglot programmers, but I can't speak to that a whole lot. All I can tell you is that in my experience, focusing on specific things that I want to be truly good at has worked out great for my career. That doesn't mean that I closed myself off to other things. With my website rewrite, I have been doing a lot of dev ops-related work and a lot of back-end stuff that I've typically not been involved in. You want to keep your head up on what's going on outside of what you're doing so that you know what direction to go in when you come across problems you need to solve. However, finding a focus on what you want to be good at has helped me a lot. That way, you feel a little less stressed.
And the third one? 
Learn how to learn effectively. It's a three-step process: you consume, build, and teach. The consumption of newsletters and Twitter and whatever inspires you, but you don't want to spend too much time doing that — implementing it into actually building something matters. This happens naturally if you work at a company, but maybe you're not making the things you want to learn, so you may want to start a side project. The building phase is where you get experience, but you also want to solidify that experience. How? You start teaching. You don't necessarily have to teach it to people, it could be stuffed animals. The goal of the teaching is to retain in your mind what you've learned through the building process.
What are you working on right now? 
The big thing I'm working on right now is a rewrite of my website. It'll be much more than just a developer portfolio — I'll have user accounts, and there'll be fun things that you can do with it. And because it's more than just a website, I'm using Remix, a new cool framework in the React ecosystem. I'm also working on updating my material on TestingJavaScript.com and a TypeScript course as well. 
So, whatever I'm working on, it ends up resulting in lots of opportunities for content.


Do you have some rituals that keep you focused and goal-oriented? 
I have a notepad where I keep all of my notes of what I'm going to do for the day so that when I'm checking things off, I'm not distracted notifications. I've tried apps for that, and that does not work well for me. 
I also am a firm believer in inbox zero. I have my work inbox and my personal inbox, and I keep them both at zero. And I kind of use that as a to-do list. 
And if I'm not feeling excited about working for some reason, I will often hop on my Onewheel, which is an electric skateboard that only has one giant wheel in the middle. It's just a total blast, and I'll hop on that with my backpack and a charger, and I'll go to a Starbucks or a park just to declutter my mind.
What things in the React universe are you excited about right now?
React version 18 is coming out soon. The experimental version is out there, and it's fun to play with. I'm just really thrilled that it's no longer a concurrent mode but concurrent features that you can opt into. Cool things like that will enable React server components in the future. 
But the biggest thing I'm excited about is Remix. That's huge. It eliminates a lot of problems that are solved well other tools, but when I'm using Remix, I don't have those problems, so I don't need those clusters.
You already said that teaching is an integral part of the learning process, and you stand your word since you're also a full-time educator. What inspired you to enter this field?
I have been a teacher for as long as I can remember. I grew up in a church where you talk in front of your peers from a very young age, and my mom was an elementary school teacher, so teaching has just always been a part of me. 
I really just enjoy sharing what I'm learning with others. As far as teaching technical topics, I gave my first workshop when I was still a student at Brigham Young University. With my fellow, we taught how to use AngularJS, and I got Firebase to sponsor pizza so they would show up, and that was pretty fun.
Then I started teaching on the side at egghead.io right after I'd graduated. That was when I first got a paycheck for teaching. And I realized that teaching could be quite lucrative and support my family and me as a full-time endeavor. So I did it — I quit my job. I'm a very risk-averse person, so I'd done teaching as a side hustle for four years just to verify that I could make this work.
When TestingJavaScript was released, and I got that paycheck, I realized that I didn't need my PayPal salary anymore. I could just focus my daytime on teaching and give my evenings back to my family, which was a nice trait.


Apart from that, how has teaching impacted your career? 
Earlier I mentioned that pretty much all of my jobs came because I was perceived as an expert. After the first job, where I was an intern and then converted into full-time, I never applied to another. I worked for four different companies, and they wouldn't have recruited me if they didn't know who I was and what I was doing. My content is how they knew who I was — I just made it easy for them to find me. Teaching made that impact. It made my career. 
We talked about React and Remix. Are there any other open-source projects that you'd recommend keeping an eye on or contributing to?
I have some myself. React Testing Library is probably the biggest one that people are familiar with. And if React isn't your jam, then other framework versions of the testing library. 
React Query is also really popular. If you're using Remix, you don't need it, but if you're not, I strongly advise using React Query cause it's a stellar, fantastic library, and Tanner Linsley, the creator, is a stellar and fantastic person. 
What pieces of your work are you most proud of? 
Probably the biggest thing I've ever done is EpicReact.Dev. It has helped tens of thousands of people get really good at React, improve their careers and make the world a better place with the skills that they develop. My whole mission is to make the world a better place through quality software, and I feel like I've done that best with Epic React. 
There are things that I've built at other companies that are still in use, and I'm proud of those cause they've stood the test of time, at least these last few years. But of everything, I think Epic React has made the biggest impact.
***
Follow Kent on Twitter and listen to his favorite Spotify playlist
TechLead Conference 2023TechLead Conference 2023
36 min
Effective Communication for Engineers
Your communication skills affect your career prospects, the value you bring to your company, and the likelihood of your promotion. This session helps you communicate better in a variety of professional situations, including meetings, email messages, pitches, and presentations.
React Advanced Conference 2022React Advanced Conference 2022
24 min
A Career As Software Engineer
Typically I talk a lot about deeply technical concepts like TypeScript, type systems, (im)mutability, MobX, Immer etc. But this time it's going to be personal and I'll share lessons, good and bad, about growing as an engineer. I've been leading open source projects, short lived projects as a freelancer and I went through the transition of engineer to tech lead twice. Both at a young startup and at Meta. This talk will be about personal experiences, unpopular opinions and even actions, and anything else that might be counterintuitive. Join for some take-aways for anyone aiming at an engineering focused career. Probably I will be wrong about most things, so don’t miss the opportunity to follow up afterwards!

Workshops on related topic

React Summit 2022React Summit 2022
75 min
How To Design A Sustainable Freelance/Contracting Career + Speedcoding Challenge
WorkshopFree
Ready to kickstart your freelance career or just getting started on your freelance journey? You’re in the right spot. Learn from the world’s largest fully distributed workforce in the world.
The independent talent movement is the future of work. If you’re considering leaving full-time employment for a career as a freelancer, now is the time to find your successful space in the independent talent workforce. More people are working freelance today than ever before, with the freelance marketplace now contributing $1.2 trillion to the US economy. Some of the most in-demand roles for freelancers right now are senior developers with professional experience in React, Python, Blockchain, QA, and Node.js.
This workshop will help you design a sustainable and profitable full-time (or part-time) freelancing/contracting career. We will give you tools, tips, best practices, and help you avoid common pitfalls.
At the end of the workshop there will be a Q&A session with a Freelance Developer who can answer your questions and provide insights and tips into their own success.
During the Workshop break, we will be running a speed-coding challenge! At the end of the workshop, we will award a prize for the winner and display the leaderboard.
We will have you login to our portal and complete the challenge as fast as you can to earn points. Points are assigned based on difficulty and the speed at which you solve the tasks. In case you complete all tasks, you get extra points for the remaining time. You’ll see your score, ranking, and the leaderboard once you complete the challenge.
We will be giving away three Amazon Gift Cards ($200, $100, $75) for the top three winners.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Designing A Sustainable Freelance Career
WorkshopFree
Would you like to pursue your passions and have more control over your career? Would you like schedule and location flexibility and project variety? Would you like the stability of working full-time and getting paid consistently? Thousands of companies have embraced remote work and realize that they have access to a global talent pool. This is advantageous for anyone who has considered or is currently considering freelance work.>> Submit your interest on becoming a freelance engineer with Toptal and get a call with Talent Acquisition specialist <<

Freelancing is no longer an unstable career choice.

This workshop will help you design a sustainable and profitable full-time (or part-time) freelancing career. We will give you tools, tips, best practices, and help you avoid common pitfalls.
Table of contents

Module 1: Dispelling common myths about freelancing
Module 2: What does freelancing look like in 2021 and beyond
Module 3: Freelancing choices and what to look for (and what to avoid)
Module 4: Benefits of freelancing from a freelancer + case study
BREAK
Module 6: How to get started freelancing (experience, resume, preparation)
Module 7: Common paths to full-time freelancing
Module 8: Essentials: setting your rate and getting work
Module 9: Next steps: networking with peers, upskilling, changing the world
Module 10: Freelancer AMA
React Summit Remote Edition 2021React Summit Remote Edition 2021
121 min
Landing Your Next Developer Job
WorkshopFree
Renaud Bressant (Head of Product), Nathanael Lamellière (Head of Customer Success and Solution Engineer), Nouha Chhih (Developer Experience Manager) will be looking at the different developer jobs that you can accounter when looking for your next developer role. We'll be explaining the specifics of each role, to help you identify which one could be your next move. We'll also be sharing tips to help you navigate the recruitment process, based on the different roles we interviewed for as recruiters, but also as candidates. This will be more of an Ask Us Anything session, so don't hesitate to share your thoughts and questions during the session.