DEV Community: Makoto Kinoshita

How I prepared for interviews

Makoto Kinoshita — Thu, 01 Oct 2020 19:25:02 +0000

Studying / Side Projects

Before I talk about the actual steps of applying for a position, let me talk about studying and side projects. When I was looking for my first job, I often went online and tried to find some advice on what I should focus on to prepare. I saw people saying I should go through a book about algorithms and practice some algorithm problems, but also work on side projects. The amount of work they suggested people do was overwhelming. After I experienced some job interviews and saw other candidates, I have a slightly different perspective: Focusing on studying algorithms might not be that effective, especially if you apply to a small startup.

How much companies care about algorithms varies

How much you need to study algorithms partially depends on what kinds of companies you want to work for. For example, if you want to get a job at a FAANG company (Facebook, Apple, Amazon, Netflix, and Google), then being able to solve algorithm challenges is important. They hire people from various backgrounds, and they are usually more open toward people without a CS degree. However, in order to be fair to everyone, they focus more on algorithms because it is easier to evaluate people. It is similar to why many college applications require standardized tests. At the FAANGs there are usually multiple rounds of algorithm questions.

However, if you want to get a job at a small to midsize company, then being able to solve a pure algorithm challenge is not that important. Smaller companies need more people who can be productive right away. They tend to look for people who can demonstrate that they can code, and being able to solve algorithm questions is not as important for them. They might have some sort of algorithm-related questions in their interview process, but not as much as FAANG companies do. If you want to know the exact interview process of a company, check on Glassdoor to see whether there is some information.

Have one well-thought-out side project

If you are looking for a job at a relatively small company and you don’t have a CS degree, then having a side project is important. As I said before, they are looking for people who can add value to a company immediately, and you have to demonstrate that you can do so. Some people think that their GitHub has to be full of side projects, but that’s not true. In fact, there are lots of senior engineers who don’t have any actively maintained projects. It also doesn’t have to be a huge project either. Here are two things I recommend doing if you already have a project you are working on.

Have a good README. It should at least have a summary of the project and the technologies you have used. Recruiters can only spend a few minutes on each candidate at the initial screening. They might only read the README, so it is important to have a presentable one.
Clean up your code. Follow a language-specific convention and remove unnecessary code. For example, it is a convention to use snake cases in Python. If your code uses snake cases and camel cases at the same time for no reason, it shows that you don’t care about details. You can find a list of best practices for a specific language or a framework, so read them and clean up your code accordingly.

If you don’t have any side projects, and you need more advice on them, then feel free to contact me. I can give you more detailed advice. But the most important thing is to work on something you are interested in, otherwise, it is hard to put your effort into it.

Practice algorithms while going through actual interviews

I found this piece of advice while I was applying for a job, and it changed the way I see job interviews. It takes months to study everything in an algorithms book, and I see some people wait to apply to jobs until they finish their studies. Companies are more likely to ask about certain topics than other topics. A good way for you to learn what companies like to ask is to actually go through technical interviews. I had experience with two companies who asked me to solve a really similar problem. Try to see interviews as practice. It also helps you relax in an interview.

If you are still worried about algorithms and would like to study them, here is a short list of resources that can help you get started.
Books

Algorithm Design Manual by Steven S Skiena If you have to pick one book to read about algorithms, I recommend this book.

Youtube

Mycodeschool: I didn’t know about this one until recently, but the creator is good at explaining complicated things. Watching this in your free time can help you to have a general understanding of data structures and algorithms.

Online Courses: I haven’t used either of these, so take these recommendations with a grain of salter.

Algorithm Specification by Stanford: I did some research on online courses, and many people recommend this one the most. I looked into the content, and it is more than enough for you to pass algorithm questions at an interview.
Intro to Data Structures and Algorithms: Another great online course for learning algorithms. The course is taught by Google. It might be more practical than the first option.

Github Repo

Coding Interview University: This is a comprehensive guide on how to study algorithms. However, please remember that doing everything on this list is unnecessary.

Websites

LeetCode: I used LeetCode to get some practice on algorithms when I had time. It is simple to use, and you can usually find answers when you are stuck.

Applying

Make a strong resume

The biggest problem I see with resumes is that there are lots of people writing more than a one-page resume. People who filter candidates cannot spend lots of time on one candidate. Recruiters can have automatic negative responses when they see an overwhelming resume. Having a really long resume rather hurts your chance of moving to the next step, so please do not go over one page.

Another common mistake I see is to list out all of the technologies you know. I made the same mistake when I applied to jobs, so you are not alone if your resume has too many technologies. You should instead pick certain technologies you know really well and you think can highlight your experiences. For example, if you are applying for a frontend position and know certain frontend frameworks such as React or Vue, then it is obvious that you know HTML and CSS and you don’t need to include them. I also don’t recommend including technologies you don’t know very well. Recruiters do not expect you to know 3 languages and 5 different new technologies especially if it is your first time getting a software engineering job. Having too many skills on your resume makes it look ingenuine.

On the other hand, there are a few things I would recommend putting on your resume if you know either of them: testing frameworks and infrastructure tools. The biggest difference between working in a company and programming in college or bootcamps is that people care about scalability and maintainability at a company. You might not have experience with testing or infrastructure tools, but if you do, it will be a big differentiator from other candidates.

Finally, you should do some research on a company’s tech stack. They are usually mentioned in job descriptions. For example, if a company is looking for a Python developer, then focus on highlighting your experiences with Python over other technologies. If you use it for a side project, then talk about what you have built with it in your resume. If you have a section listing out your skills in your resume, even putting Python at the beginning can help you to attract the recruiter's attention.

You can structure the content of your resume as you want, but many resumes for software engineering positions have these sections: education, experiences, projects, and skills. If you would like to see an actual resume, I’m happy to share mine. I don’t think it is a particularly good one, but it was good enough for me to get a job.

Touch up LinkedIn and AngelList profiles and your GitHub repo

Startups get a ton of applications. An easy way to filter out people is to look if their LinkedIn and AngelList profiles or their GitHub repo aren’t in good shape. This is just basic professionalism. If you can’t do these simple things, how could you be expected to be a good employee? When I say they have to be in good shape, I don’t mean that you have to have multiple side projects and internship experiences. Just fill out the basic information so that recruiters can easily tell who you are. You can copy most of the content from your resume.

Reach out to CTOs directly

It is not uncommon for CTOs to screen candidates directly in a small company. When they use some hiring platforms such as AngelList, the CTO’s inbox might be filled with emails from AngelList. How to stand out in this situation? If you can find a CTO’s email, you can probably send the email directly to him or her. However, this depends on the company’s hiring process. If a company clearly specifies how to apply for a position, maybe it is safer to follow the specified instruction. The smaller the company is, the higher the chance that the company does not have a standardized process for hiring and you can take advantage of that.

There is no perfect way to find a CTO’s email address. You might be able to find it on the company’s website but you might have to get more creative. Salespeople are really good at creatively finding email addresses. One of their favorite tools is called Email Finder. It can find a person’s email using their LinkedIn profile. It’s not perfect but it works most of the time. You can also just guess. Many companies use some combination of a person’s name and the company’s domain for employees’ email addresses. If you can find one employee’s email address, you can just apply the pattern to the CTO’s name to guess their email address.

Once you find a CTO’s email address, the next step is to actually send them an email. Try to make the email concise. No one wants to read a long generic email from a candidate. There are only two things you need to include in an email: why you want to work at that company and why you think you will be a good fit for both the company and the role. Try to make it as specific as possible. Also, don’t forget to attach your resume or any other additional materials you want them to check.

Don’t underestimate generic questions

Some companies have generic questions in their application. Don’t underestimate those questions and put unthoughtful answers. For example, if there is a question asking why you want to work for company X, don’t say I just want to get any job or leave it blank. There are surprisingly a good number of people who answer like this and immediately get rejected at the resume screening. You don’t need to spend lots of time coming up with clever answers. Just answer genuinely. It is also a good chance to show your personality. Companies would like to know who you are as a person and not just as an engineer. Cultural fit is a surprisingly important factor in the interview process.

Apply with referrals

I didn’t personally do this, but I have friends who tried to always apply with a referral. In case you don’t know, a referral is when someone at the company submits your application on your behalf. This is a completely normal part of recruiting. In fact, many companies give thousand-dollar bonuses if an employee refers someone who gets hired. If you’re referred, the chances that you get a response are vastly higher. To get referrals, ask people in your network. It’s best to reach out to the person, ask them to chat about the company, and then if the company and role still seem like a good fit, ask them to refer you. Don’t be shy about it. Again, it’s totally normal and the other person can make a lot of money really easily if you get hired. Everyone wins! Here is an email template that you can use:

Hi XXXX,

I hope you’ve been doing well since college! [Or some personal note or some reference to how you know the person]

I’m in the process of applying to software engineering roles. I saw that you work at [company], and there’s an open [job title] position that I’m really interested in. I’d love to hear about your experience working there to get a better sense of the company.

Do you have some time to chat?

Then in the call or in a follow-up email, you can ask for the referral like this:

It was great chatting with you! The company sounds like a great place to work. Would you be open to referring me for the position? If not, not a problem. I still appreciate you taking the time to talk.

If you have any questions, feel free to reach out to makoto@antcode.dev. Lots of people helped us with career stuff over the years, so I’m more than happy to give back.

Happy coding!

The 3 most important pieces of advice I got in my career

Makoto Kinoshita — Tue, 15 Sep 2020 19:50:38 +0000

Everyone wants to be a better engineer. Particularly when you have just started your professional career, you are eager to learn. You see a senior engineer in your team, and you wonder how you can be like the person. The answer is pretty simple: You need to learn and practice more. However, the most effective way to do so is often unclear. You don’t want to spend all of your free time outside work thinking about programming. If you want to, that would be great but at least I don’t want to. I struggled a lot when I first started working because there were so many things that I didn’t know and I didn’t know where to start. In this article, I will talk about 3 pieces of advice I got from my CTO at that time that helped me to figure out what to do to level up my skills.

Read Books

Reading books is arguably the most effective way to level up your skills when you are working. You write code at work, so you already have enough time practicing. What you need is more knowledge that you can apply when you write code. If you don’t know what to pay attention to, then it is hard to get better by just writing code. Interestingly, the fundamentals of software engineering have not changed that much in the last 20 years. You can still learn long-lasting fundamentals from a book written a long time ago. Since there are already lots of articles that recommend books, I will provide just 3 books that cover very different topics in software engineering.

Designing Data-Intensive Applications - Martin Kleppmann

You can’t really talk about modern software without data. If you want to scale your application, the amount of data your application has to handle can be the bottleneck of the app’s performance. It is not very difficult to build Amazon or Facebook that works for only dozens of people, but scaling it to millions of people is a different story. This book will give you an overview of different technologies and things to consider when you build data-intensive applications.

Clean Code - Robert C. Martin

This is a classic book about software engineering. It explains lots of fundamental principles that help you write clean code, as the title suggests. It was written 12 years ago, and the author mainly talks about OOP. If you don’t write Java, some of what he says might not be immediately applicable but I think there are lots of fundamental principles that can apply to your daily work. I would highly recommend reading this at least once in your career.

The DevOps Handbook - Gene Kim, Jez Humble, Patrick Debois, John Willis

You may wonder why the last book I recommend is specifically about DevOps. DevOps is about team culture. It is not just for a DevOps engineer, but all engineers should understand the core concept behind it. If your team doesn’t have a great DevOps culture, you will face a productivity issue at some point even if things are working fine at the moment. If you want to lead a team or start a company in the future, you need to understand how to build a good DevOps culture. Although the field of DevOps has been changing quickly, this book was published fairly recently and covers lots of basic principles of DevOps that are still applicable.

Learn a language with a different paradigm e.g. functional programming

The second piece of advice I got from my former CTO was to learn a functional programming language. At first, I was really skeptical and didn’t understand the point of it until I actually tried. I used JS and Python for my daily work, and I didn’t have a chance to use a functional programming language at work. To me, learning a new language that I don’t use for work didn’t seem that helpful. It took me a while to understand the benefits of it, but here are the things that I learned in the process.

It helps you to differentiate language-specific best practices from universal best practices.

When you write just one or two languages, it is hard to tell what are generic software best practices and what are language-specific best practices. For example, if you are a JS developer, people often tell you that fewer lines of code in one file are generally better. This does not apply to all languages. Fewer lines of code are generally preferred in JS because it reduces the chance of accidentally mutating an object. If you use a functional programming language, it is impossible to mutate an object by design. If you think I’m wrong, check out this video by the inventor of Elm. Learning a functional programming language broadened my perspective on programming languages and enabled me to critically think when I encounter a new design principle.

You can choose a language that is better suited for work.

Many modern systems are moving from monolith to microservices. Of course, there are disadvantages of taking a microservices approach and companies should not split a monolith for no reason. However, it is quite normal to use different languages for each part of an application these days. Learning different paradigms of programming languages helps you to determine the language that is best suited for a given task.

Build your own X

This might be obvious to many people, but if you want to be a better engineer, building something is the best way to learn new things. If you have something you are interested in, then you should build it. However, if you are like me and have a tough time coming up with what you want to build, then this is what usually helps me: Try to build the core logic of existing frameworks/applications from scratch. For example, if you are a front-end engineer using React, try to build your own virtual DOM program. If you’re interested in compiler optimization, then try to build your own interpreter or compiler. Understanding the core logic of an application helps you to understand the advanced topics around the application. Here is an awesome list that helps you to get started when you don’t have any ideas.

These are the things that helped me to grow as an engineer when I first started my career. Everyone has their own way to become a better engineer and I don’t have years of experience, so take these with a grain of salt. If you are working on your side project and want some feedback on your work, then check out Antcode to get reviews on your work from other people.

Mastering Curl: Going from junior to senior level debugging skills

Makoto Kinoshita — Mon, 07 Sep 2020 07:08:06 +0000

Debugging is just the process of creating hypotheses about what is causing a bug and then testing those hypotheses. One of the biggest differences between junior and senior developers is that senior developers are much better debuggers. They have a better sense of where a bug may be coming from and they have better ideas about how to test their hypotheses

If you are a full-stack engineer or a backend engineer, part of your job is to debug servers. In many cases, you cannot debug an API server unless you send a request to the server. There are many ways to do this: using fetch in a browser, using a third party application, or using cURL. Many great engineers who I have met can use cURL with ease. Being able to use it is not required to be a good engineer, but if you can use it comfortably, it will definitely help you to level up your debugging skills. In this article, I will explain a practical guide on how to get started with cURL.

What’s wrong with fetch or Postman?

Some people might wonder why you need to use a command-line tool in 2020. I have used Postman before, and I agree that it is a great application. In particular, being able to save the history of your requests is a neat feature. However, there is a big limitation. You cannot easily use it inside a Kubernetes cluster, VM, or Docker container. You sometimes have to go inside another machine and send requests from the machine. You cannot easily use fetch or a third-party application in this situation. On the other hand, you can install cURL with one command and start using it right away. cURL also supports many different protocols such as FTP and SMTP along with HTTP/HTTPS protocols. If you need to learn just one approach, then it is better to learn the one that you can use in any situation.

Utilize a browser’s network tab

If you are new to cURL and want to read the documentation, you can just type man curl on your command line. However, if you are not a big fan of reading documentation and prefer to actually start using a tool right away, you can start using cURL quickly by utilizing a browser:

Go to a page you want to debug
Open up the browser’s developer tools
Go to the network tab
Hover over a network request you want to get cURL command for
Right-click on the network and select “Copy as cURL”

Once you copy the request as cURL, then paste that in your command line. You will see something similar to the following image.

If you hit the Enter, it will send a request. If you look at the command closely, you will find that each line is followed by -H, which represents a header property. When you are debugging, you don’t need most of the header properties except for a few of them that I will talk more about later. In this case, you can simplify your cURL command to curl 'https://www.google.com/' and it works perfectly. Here is a general tip for beginners when you want to use a cURL command and don’t know it exactly: Copy a request as a cURL command from a browser and simplify the command by removing unnecessary header properties.

Basic usage of cURL

Now you know how to get started with cURL, so let’s look at the basics of cURL so that you don’t have to copy a request from a browser every time.

GET request

The first use case is sending a GET request, which is super simple.

POST, PUT, and PATCH request

Now let’s take a look at the case where you send a request with a body massage. There are multiple ways to do it, and how a server is implemented determines which method you can use.

1: When a server accepts application/json

If a server accepts JSON format, you can send JSON data by setting the header property Content-Type to be application/json.

2: When a server accepts application/x-www-form-urlencoded

Another popular way to send a request with a body is to use x-www-form-urlencoded format. Data you want to send will be transferred with the format of key1=value1&key2=value2.

3: When a server accepts multipart/form-data

When you send a request using the above 2 methods, you can only send one data type at once. However, a server can accept multiple data types. This is typically the case when you can upload files to the server. When you use multipart/form-data, you specify the data using the -F flag. In order to upload a file, you need to add @ at the beginning of the file path.

There are more content types you can specify, but knowing these 3 will cover most use cases. Sometimes the body message is way too long to type on the command line. In this situation, you can let a server read data from a file. I will talk more about this later.

Authentication

Another common use case is to send authorization information. Many services have an authentication system that requires you to be authorized to make a certain request. When you make a request from a browser, your authorization information is usually stored as a cookie and attached to requests. However, if you make a request outside of a browser, you need to attach authorization information to a request. What method works depends on how an authentication system is implemented on a server.

Basic Authentication

Basic authentications are one of the most popular authentication systems. They send user credentials encoded in base64. A request has an authorization header that contains encoded values of the username and password. When you use cURL, you don’t need to encode the user credentials on your own because curl will do it for you if you include the -u flag like the following.

Bearer Authentication

Bearer authentications are mainly used for OAuth 2.0, which are industry-standard for applications that send requests on behalf of a user. An example of OAuth 2.0 is a GitHub app that sends requests to the GitHub API server when a user performs a specific action. Bearer tokens are usually generated by a server in response to user authentication. Once you get a bearer token, you can send a cURL request like the following.

If you cannot authenticate correctly using the methods above, this page explains more about authentication using cURL. You might need to pass optional flags as described on the page.

Advanced usage

Now you know how to send requests using cURL. Once you get used to it, you can write up a command to send a request really quickly. However, in reality, you need to know a little bit more about cURL to debug like a pro. Here are some of the advanced usages that are really helpful when I debug a server.

Avoid SSL certificate error

When you send a cURL request using HTTPS, it performs SSL certificate verification. However, if your server does not have a certificate signed by the CA, then your cURL command will fail. This often happens when you send requests to a server with a self-signed SSL. If you want to know the details about SSL, CloudFlare has a good article about it. You can disable certificate verification by passing a -k flag.

Write the content of the body message in a file and pass the file

Your body message can be too big to write all of it in the command line. You might want to save the content for debugging purposes. In these situations, You can write a body message in a file and send the contents of the file as a body message. There are two slightly different ways to do it: The one on the top would strip all newlines in a file, and the one below does not. Choose an appropriate method depending on your use case.

Stress-test a server

cURL can be also used to stress-test your server. I have encountered a bug where a program worked fine when there were few requests to a server, but it broke when there were loads of requests. cURL is really handy in this situation. You can use [] to create dynamic URLs, and mimic the stress test. The following program sends the request 1000 times.

There is a lot more you can do with cURL, but now you probably know enough to explore cURL on your own! If you want to learn more about cURL, just type man curl in your command line. Mastering cURL will help you to debug more quickly.

If you like this post, we'd love it if you "Like" it and/or share it wherever and however you do your social media. You can subscribe here to get an email when we publish new posts. I'm on Twitter at @mkinoshita12. If you have any questions, feel free to reach out at makoto@antcode.dev.

If you're curious what Antcode is, you can check it out here.

How I Got a Software Engineering Job at a Growing YC Startup (Part 1)

Makoto Kinoshita — Fri, 04 Sep 2020 19:45:21 +0000

Intro

Working at a growing YC-backed startup is a great way to start your career. I cannot describe how much I learned in just the 2 years I spent working at one. Not only do you grow as an engineer, but you also get to learn many aspects of building a company. When I was applying for a job, I found almost no information about getting a job at YC-backed startups even though there is lots of information about how to get a job at big companies such as Google or Facebook. That is why I’m writing a step by step guide on how to get a job at a growing YC-backed company.

Trying to get a job for the first time can be scary. No one teaches you how to get a job, and you are essentially on your own. I know the feeling well. The most important thing is to remember that you can find your way in by approaching the interview process correctly even if you don’t have a CS degree or internship experience. Many of the guides about “how to get a software engineering job” focus a lot on studying algorithms, and they list an overwhelming number of resources. However, there is a lot more in the whole interview process than just studying algorithms. Studying algorithms is actually not as important as some people claim when you are applying to a startup. If you have ever felt overwhelmed while reading those interview study guideline articles, or have no idea where to start, this is the guide for you.

Job Search

Before I start talking about the job search, let me talk about why we are specifically targeting YC-backed startups and not just any startup. Determining whether a startup is growing or not is an extremely difficult process especially if the company is pre-series A. The fact that a company went through YC is one of the few variables you can take into account when you evaluate the chances of the company being successful. Another benefit to YC companies is that they are highly-regarded, so it's a big plus on your resume if you work at one. You will also get access to an amazing network. YC has more than 4000 founders, and founders have access to that network. If you work at a YC-backed company, you will also have access to the network via the founders. That being said, most of the things I will talk about in this article are not limited to YC-backed startups and some can even apply to big tech companies.

Where to find an open position

Main resources (Ordered high to low by how much I recommend them)

Keyvalues: This is a fantastic website if you want to find a YC-backed startup that could be a good fit for you. It categorizes companies with very unique metrics and gives you a great sense of what each company is like. I found my first company through this website.
Hacker News: Hacker News has a job directory where only YC-backed companies can post open positions. I highly recommend that you pay attention to the whoishiring thread. This is the thread where many companies including YC-backed ones post open positions at the beginning of each month. Here is the truth about early-stage startups: they don’t have that much time to spend on hiring. If you react faster than other people, there is a higher chance that they will at least look through your application.
AngelList: It is still the go-to place for a startup to post their open positions. Most startups are not experts in hiring. Especially if the company is pre-series A, it is likely that they don’t even have recruiters. There is a higher chance that they would use the most popular platform to post open positions.
StackOverflow: I actually didn’t use this when I applied for jobs, but I learned that it is also one of the most popular platforms where companies post open positions. They have a good search engine similar to AngelList, so it definitely helps to target specific positions that fit your criteria. Even if you are not active on StackOverflow, don’t worry about it because most of the employers don’t care that much about your StackOverflow score. In fact, it is common that even senior engineers have almost zero reputation on StackOverflow.
Glassdoor: Glassdoor’s main benefit is the honest information in the anonymous reviews by employees and interview candidates. This is super helpful when you are preparing for interviews, but I will talk more about this later. Since companies know that people check their Glassdoor reviews, they are usually active and post open positions on Glassdoor too.

Other resources

Startupers: This is similar to AngelList, and startups can post open positions. Their search engine is not very good, and it is hard to find a position that fits your criteria. Nonetheless, companies post open positions almost every day, so it’s worth checking it out.
GitHub: Yes, GitHub has a jobs board. Companies from all over the world can post their job openings here. GitHub has fewer listings than StackOverflow. If you are looking for a job in a specific location, there might not be that many listings for that particular place. One good thing about the GitHub jobs page is that it has an RSS feed so you can easily subscribe and get notified when there is a new listing.

In my experience, just focusing on some on the main resources is more than enough because the quality of websites in the “main resources” list is higher than those in “other resources”. Another great approach is to just read through tech news on Hacker News or TechCrunch, find an interesting company, and directly check the company’s website for open positions. Some people even get a job at a company where they don’t have an open position. I’m not saying that it is always the case, but if you hustle hard enough, there is a higher chance that you will find a way to get a job at a small company than at a big company. Later I will talk more about how you can make this happen.

How to determine whether a position is a good fit

Another important thing in the job search is to determine whether a position is a good fit for you or not. I think the growth potential of a company is one of the most important factors you should consider. But not everyone can have the experience of working at a company that is growing and that will be successful in the future. That experience itself will make you grow personally and will provide you more opportunities in the future. Therefore, I’ll spend the most time talking about how to determine the growth of the company, but I’ll discuss other factors too.

Growth
Predicting whether a small startup will grow is extremely hard. There is no special formula for it, and if it existed, every investor would make loads of money. An added difficulty is that when you are applying for a job, you have less information than what investors have. Although it sounds really risky to work at a startup, getting a second job is much easier than the first one, so it’s easy to transition from a failed startup to another one. Don’t get obsessed with finding a growing startup. Take these methods as just one way to guess how fast a company is growing.

Check Crunchbase: Determining a company’s funding situation is the first step. Crunchbase usually has some information about a company’s financials. You want to focus on the stage of the company, and how often the company is getting investments. Don’t focus too much on the company’s funding size. Small funding size doesn’t mean a company is not growing. Again, there is no golden rule here, but you probably want to avoid the extremes. Especially if a company is raising large rounds of founding frequently, then you should dig deeper. When a company raises capital, they usually secure funding for the next 12–18 months. If a company is raising money more frequently than once per year, this could be a red flag. People tend to think that the more investment a company has the better it is, but that is not true. Raising money means that investors expect more growth in return, and often companies cannot keep up with those expectations. Also, note that information on Crunchbase is sometimes outdated, so even if a company gets investment, the information might not show up.
Check employees’ LinkedIn: This helped me a lot when I made a decision about which companies to apply to. Almost every young adult has a LinkedIn account these days, and they often update their account when they leave a company and when they get a new job. Checking who is getting hired at which point gives you a general sense of whether a company is expanding or not. While scaling, companies need people with experience to make sure they do it right. If there are employees who have worked in successful startups before, this is a good sign. Checking employees’ LinkedIn also helps you to know what kind of people you will be working with, which is really important for your personal growth.
Use Web Archive to see how the company has changed over time: We should all thank Internet Archive for making Web Archive. It enables you to see the history of changes to the landing page of a company. By looking through those, you can understand how their business plan has changed over the years. Every startup is looking for product-market fit, and it is not a bad sign if a company is changing its business model. Just make sure that changes in their business model make sense to you. It might be a bad sign if a company is changing its business model too frequently. You should also check the team page of each version of the landing page, and see how often people are leaving. It is a good sign if there are a decent number of people who are sticking with the company for a long time.
Read articles about the company: Companies usually have some sort of presence in the media if they have gone through YC. You might find an article that talks about a company, its competitors, and the industry they are in. It is also a good opportunity to learn about industries. If you find competitors, you can also do steps 1 through 3 for them, which will give you a better understanding of where each company stands.

Growth is important, but culture is arguably more important. You will spend at least 40 hours a week in one company for a while. Working in a company whose culture doesn’t fit you is nothing but torture. However, the best way to determine the cultural fit is by actually having onsite interviews. You will learn a lot more through interviews than reading online reviews, so don’t worry too much about cultural fit when you apply. Here are two things I did to make sure I did not waste my time applying to the wrong companies.

Culture

Read Keyvalues: As I mentioned above, this is the most efficient way to learn about the culture of YC-backed companies. They don’t have all of the YC-backed companies, but if the company you are thinking of applying to is on the list, then you should definitely check it out.
Read Glassdoor: Glassdoor might have reviews on the company you are doing research on. All of the reviews are anonymous, so they tend to be honest and trustworthy. If there are more negative reviews than the positive ones, then you might want to think twice about applying to the company. Note that if a company is really small, then they might not have any reviews.

Interest
If you join a small startup, you will probably work more than you would at a big company. Every day is full of challenges. Some days you might have to stay up until midnight to ship a new feature, or you might have to get up at 3am because your code breaks the whole application. I’m not trying to intimidate you, but challenges are common in startups. That’s also what makes your work more fulfilling. Without an interest in a company’s vision and also in the industry the company is in, it can be hard to go through some of those challenges. If you are trying to get a job for the first time, I know you probably want to get any job because I was the same way. But try to take a moment and ask yourself whether you are actually interested in what a company is doing. Thinking about it will benefit you in the long term. You will gain industry-specific knowledge in a company that will help you to get another job in that industry. But if you don’t like the industry, it might not help you as much when you want to change industries in the future.

General Tips

Do not spend too much time searching for a company
Although I have listed lots of resources to find a company, I will emphasize that you should not spend too much time searching for the ideal company to apply to. Getting a job is somewhat a numbers game. It is likely that you will have more rejections than offers. It is okay because all you need is one great offer. It is much more efficient if you do a deep dive into a company once you get an onsite interview. That being said, I don’t recommend applying to every company you can find. You need to find a good balance between those two, and how much time you spend varies a lot among people. Personally, I applied to 3 or 4 companies a week over about 6 weeks. That pace felt pretty natural to me. In the next chapter, I will talk about what you should do once you identify a company you want to apply to.

Network, network, and network
As you search for jobs, you need to use and grow your network. Some experts say that 70% of jobs come from your network. You might be wondering how you can even expand your network when you don’t have any professional experiences. It turns out you actually can do it no matter your technical level. The first thing you can do is to use the network you already have. Reach out to someone who is in your college or high school network. If you have done a coding bootcamp, then reach out to the alumni of the program. People are usually generous with helping other people who are from a similar background. If you have exhausted your close network, then it is time to start reaching out to strangers on the Internet. We will talk more about this in the next section.

Recognize the uncertainty
There’s a lot of uncertainty in the entire job hunting process. Depending upon the kinds of positions you’re applying for and how selectively you pick companies, you can submit a handful of applications and get a response on every one. Or you can send out tons of applications and hear back from just a couple. I sent out about two applications a day for two weeks. For each application, I customized the cover letter and my resume to make the application as strong as it could be. I applied to almost 20 companies in total and I heard back from 8 companies. Judging by what I’ve heard about other people’s job searches, I think my job search was pretty efficient. I have a friend who sent out over 100 applications, but he only customized his resume and cover letter for a couple, and ultimately he heard back from just 4 or 5 companies. Different strategies are successful for different people. Just remember that if you’re trying to land a job and things aren’t going well, you only need one job offer!

After you find the companies you want to apply to, the next step is to put together your application and submit it. In the next post, we’ll go over how to do that so that you maximize your chances of getting responses.

If you have any questions, feel free to reach out to makoto@antcode.dev or otto@antcode.dev. Lots of people helped us with career stuff over the years, so I’m more than happy to give back.

Happy coding!

Junior v. Senior React Code: Using Flags with React Components

Makoto Kinoshita — Wed, 02 Sep 2020 03:03:03 +0000

This post is one in a series in which we take React code that a less-experienced developer would write and improve it so that it resembles more what a professional would write. In the first part of the series, we converted a class component to a function component.

Today we're covering best practices for naming and using flags that you pass into components. Please check out the first part of the series to see the junior code and the refactored code.

Passing a boolean into a function

Whenever you pass a boolean as an argument to a function, it is likely that the code can be better. The big reason is that it is hard to understand what effect that argument has on the function. This type of code is called a code smell. It is not a bug, but it indicates that there is a deeper problem in the program.

If you want to learn more about code smells, we would highly recommend reading the book Clean Code. You might disagree with some of the things he argues, but the book is worth reading once in your life. In the book, he lists lots of examples of code smells, and this type is called selector argument. If you encounter a situation where you want to use a boolean as a flag, you probably should split the function into two different functions.

Before I show you how to split this code into two functions, I will explain how you can make the code better if you want to keep using the boolean as a flag.

1. Create a variable

When passing a boolean into a function, one problem is that you don't know what that boolean means. The cheapest fix is to create a variable.

2. Use argument destructuring

es6 lets you unpack the arguments passed into a function, and we can leverage that here. This approach is a slight improvement because it takes one fewer line of code.

Creating separate functions

The above two solutions are okay when the function is super simple. However, a lot of people would argue that we should always have two different functions. They would reason that the getData function does two different things depending on whether it is the initial load or not, so it is better to split this function into two.

In the refactored, senior version of the code we split getData into loadInitialRandomCategoryImages and loadMoreSameCategoryImages. Now it is totally clear what each function is doing!

If you liked this post, we recommend you subscribe to the Antcode blog and follow us on Twitter at @o_nagen and @mkinoshita12 .

If you want to get reviews on your code and learn from reviews on other people's code, we recommend that you check out what we're building at Antcode and join our code review Slack group.

Happy coding!

The code review that changed my life

Makoto Kinoshita — Tue, 01 Sep 2020 23:53:00 +0000

One code review changed my career as a software engineer. It was around three months into my first job. On that day, I was working on a different part of the codebase that I had never touched before. Up to that point, I had worked almost entirely in JavaScript, but that part of the codebase was written in Python. It isn’t the language I am most comfortable with, but I had some experience using it for school work and my side projects. I implemented what was required, created a new PR, and asked one of the senior engineers to review it. He was a machine learning engineer with many more years of experience than me, and we had never worked on the same part of the codebase together. What he does was way beyond my understanding. I remember I was proud of the fact that I implemented something using a different language. At the same time, I was nervous about getting my code reviewed by him.

After about 30 minutes passed, I went to the bathroom and saw him starting to read my PR. This was good; he would finish the code review by lunchtime. I could merge the PR by early afternoon and could go home feeling good about myself. He didn’t finish the code review by lunchtime. By the time he finished it, it was already past 2 pm. He spent hours reviewing my code. I was somewhat confused and opened the PR. The comments were longer than my code. It made me frustrated and disheartened.

However, as I read the comments I realized that all of what he pointed out made total sense. His comments were thoughtful and never insulting. Some of them were stylistic comments, but what fascinated me were the comments about design principles or code smells. For example, he commented “If you have to pass a boolean as a flag, it is usually a code smell. It means that the function could be two separate functions.” I never paid attention to it until that moment, but it made so much sense. If he didn’t point it out, I would have kept writing the code the same way. All I needed was for him to point it out just once.

But that code review taught me something far more important than specific style tips. My attitude toward writing code had changed from that moment. I became more critical about my code. I started reading some books to learn software design principles. I even started reading reviews of other people’s PRs. After that code review, I began to understand what it means to be a software engineer. I no longer just wanted to ship functional code. I wanted to write code that is readable and maintainable. Software engineering is teamwork.

It’s been more than 6 months since I quit my first job to start a company with my friend. I have been coding as much as before, maybe even more than before. However, I’m noticing the difficulties of growing as an engineer without code reviews from more experienced engineers. Learning a new language is especially challenging. It is hard to know the best practices.

The main purpose of code reviews is to keep the quality of a codebase high, but it is also a great way to share knowledge among a team. Junior developers can learn a lot from code reviews. If you want to get code reviews outside of the work context, a popular way is to participate in open source projects. Open source is a great way to learn from other engineers, but it can be time-consuming and intimidating. Another issue is that some people like to build something on their own rather than participating in open source projects. They don’t have a chance to get their code reviewed.

I’ve seen engineers get rejected at interviews for lacking experience in a production environment. They don’t know how to contribute to a codebase in the context of a company. These people are stuck in a paradox. How can you expect a recent grad or self-taught developer to understand software engineering fundamentals if they have no prior work experience and the only place you can get the feedback on your code is at work?

I believe code reviews are too valuable to be accessible only to select groups of people. Everyone should be able to benefit from them. Even just one code review can unlock a whole new level of coding ability for someone like it did for me.

If you’re interested in code reviews, becoming a better developer, and/or helping other people become better developers, check out Antcode here. I'm trying to create a community where everyone has access to code reviews.

If you liked this post, we recommend you subscribe to the Antcode blog and follow us on Twitter at @o_nagen and @mkinoshita12 .

If you want to get reviews on your code and learn from reviews on other people's code, we recommend that you check out what we're building at Antcode and join our code review Slack group.

Happy coding!

JavaScript Objects: Going from Junior to Senior Code

Makoto Kinoshita — Mon, 31 Aug 2020 19:08:01 +0000

It is relatively easy to start writing Javascript code, but it is hard to write it well. If you are a junior developer who wants to level up your JS skills, it is essential to understand subtle differences and choose the right approach for a task. In this article, I’ll explore three subtle but important aspects of working with objects in JS.

1. Shallow copy vs Deep copy

Cloning an array in Javascript is pretty simple. You just have to use the slice function, and you can get a clone of an array. On the other hand, cloning an object in Javascript is a little bit more complicated. In order to shallow copy an object, you can use either Object.assign() or the spread operator (See below for more details). As you can see from this example, the category property is unchanged in all cases. However, the item property is changed when you clone an object using the spread operator, but not when you clone it using the deep copy methods.

Many people use JSON.parse(JSON.stringify()) to deep clone an object. However, the solution is not perfect. This approach loses the properties whose values are undefined. There are more cases where the approach does not correctly copy properties. You can find the full list here. The easiest way to deep clone an object correctly is to use a third-party library like lodash in my opinion. If you are writing JavaScript in Node.js, then you can implement deep cloning using native functions like: v8.deserialize(v8.serialize(obj)), but you cannot use this in a browser.

2. Take advantage of inline caching

The above two sets of code essentially do the same thing. The only difference is that the first example changes the shape of the object dynamically and the second example initializes the shape of the object at the beginning. These two approaches have different effects on compiler performance. In short, the first example creates lots of intermediate shapes of an object as you add more properties to the object. This makes it harder for JS compilers to apply inline caching. Especially if you are writing server-side code that frequently modifies the shape of the request object, then the effect on performance is not negligible. Whenever you find yourself adding a property dynamically, think about whether you can initialize the shape of an object. If you want to know more details about compiler optimization, you should read up on these resources:

3. Object.assign() vs Object spread operator

The differences between Object.assign() and the spread operator is really subtle, and I’m pretty sure there are senior developers who are not aware of the exact differences. The biggest difference is that the spread operator defines properties, and Object.assign() invokes the set operator. This statement is not really helpful to understand when you should use one and not the other. If you want to just shallow copy an object, just use the spread operator all the time. If one of the properties of an object is read-only, then Object.assign() does not let you shallow copy the object, but the spread operator does let you. If you want to learn more about the details, you should check out this blog post.

Objects are the basic component of Javascript because everything is an object in Javascript. Understanding the subtle nuances of handling objects in Javascript will help to bring you to the next level. If you have any questions or requests on what I should cover, feel free to leave a comment.

Happy Coding!

Junior v. Senior React Code: Class & Function Components

Makoto Kinoshita — Sun, 30 Aug 2020 21:53:36 +0000

Today we're covering transitioning from class to function components.
The junior code

Below is the component that we're going to refactor. Here is a link to an interactive version.

Below is the refactored version of the same code.

Click here for a live version.

The senior code

Transitioning from class to function components

There are 2 ways to create a React component: use a function or use a class.
Early on in React, the best practice was to use a function component whenever possible. Function components had 3 advantages over class components:

When function components are compiled using Babel, they are smaller. This decreases your bundle size and improves the performance of your app, especially the initial load time (source)
Function components are easier to read, understand, and work with. They are just simple functions. Simpler code is just generally better.
A function component made clear that it was stateless. A key design principle of building React apps is that you distinguish between presentational and stateful components. In a nutshell, presentational components handle appearance. Stateful components handle the state. In practice, it's hard to maintain this distinction. Stateful components often end up having some styling too. But the more you can maintain this distinction, the easier it is to change the appearance of your app. You can swap out presentational components and not have to worry about how all your state logic will be impacted. It used to be impossible to have an internal state in function components, which guaranteed that it was presentational. In programming, like in life, guarantees make your life easier.

If you needed to add a state or you needed lifecycle hooks, you would use a class component. If you've worked with React, you've almost certainly seen lifecycle hooks in class components. They are the methods that are named things like componentWillMount and componentDidMount. They are how you manage updates to the component at different points in the component's lifecycle. For instance, componentWillMount executes before the component renders and componentDidMountexecutes after the component renders.

Until React version 16.8 (released February 2019) you could only use lifecycle hooks inside a class component because they are methods on the component class that comes with React. Therefore, if you needed to use them, you needed to "extend" the React component class to create your component. (If this stuff about classes and extending them doesn't make sense, you should probably read up on object-oriented programming. This is essential programming knowledge. Here is a good place to start).

However, this whole function v. class component situation is kind of irrelevant since hooks were introduced. Hooks allow you to have an internal state and give you lifecycle hooks inside of function components. In other words, everything you used to only be able to do in class components you can now do in function components.

So is there even a point to class components anymore? Sure. You can still use them. The official React has said that, "there are no plans to remove classes from React." We would suggest trying hooks out and seeing how you like them. They seem like the future of React, but right now it's hard to say for sure.

Hooks are powerful and they do several different things. Covering them thoroughly would take a couple of blog posts. Here we're just going to cover one of the most-commonly used flavors of hooks: state hooks. Below is one of the state hooks we use in the new code:

const [urls, setUrls] = useState([]);

The useState function gives you 2 things: An array called urls that is part of the component's state. To use urls, just use it. No more of that this.state.urls stuff. The second thing you get is a function called setUrls. You use that function to update urls.

It's that simple to get started with hooks. We also introduce another kind of hook called an effect hook in the aptly named useEffect function. We'll let you explore that further on your own if you're interested.