Forem: Oliver Jumpertz

The Ultimate Guide To GraphQL Error Handling

Oliver Jumpertz — Wed, 08 Nov 2023 21:34:28 +0000

Error handling in GraphQL is often not easy. It’s actually pretty hard. This is why many developers struggle to build a really usable GraphQL.

If this sounds like you, you are not alone. If it doesn’t sound like you, you might still stumble upon these issues soon.

A good API can be a game-changer, especially if the product you build does not only want to rely on a user interface you provide. Even if it’s only your own product that suffers from difficult error handling, any frontend engineer (and even yourself) will thank you if you make handling errors as simple as possible.

There are gladly a few strategies that you can apply to improve the error handling of your GraphQL API, which will make it an overall more pleasure to use and work with.

None of these are difficult to implement, they just require some careful thinking and planning before you can implement them.

The Issue With GraphQL And Errors

GraphQL is an amazing API technology, but it has its “flaws”.

It’s great to enable your clients to simply retrieve only the data they really care for (while leaving out all the additional burden of the 321 properties they will never need in their lifetime). But if you use GraphQL over HTTP (yes, that is really a thing because GraphQL is protocol-agnostic and the whole spec doesn’t mention a required protocol even once), you might (or might not. If so, I’m happy I can tell you about it!) have realized that any well-formed GraphQL response usually has to respond with an HTTP 200 status code.

Other status codes are reserved for very specific use cases, and this usually leaves you only with an HTTP 200, which does not help at all when encountering errors.

This is why GraphQL introduces the optional “errors” array into any GraphQL response, which looks like this:

{
  "errors": [
    {
      "message": "This somehow didn't work out well. Sorry.",
      "locations": [{ "line": 2, "column": 9 }],
      "path": ["thanks", "for", 1, "reading", "thisArticle"]
    }
  ],
  "data": {
    "article": {
      "title": "The Ultimate Guide To GraphQL Error Handling",
      "author": "Oliver Jumpertz",
      "text": "..."
    }
  }
}

Errors can always be appended to a GraphQL response, even if data is returned. Everything the presence of the errors array states is that something went wrong while processing the request.

The above can be boiled down to the following:

If errors are absent, everything went fine
If errors are present, something went wrong, and many clients will throw an error, even if data was returned

Errors in GraphQL are specified, but not strictly. The three properties message, locations, and path are conforming to the standard. Adding additional properties is not a violation of the specification, but it is highly discouraged. Many client libraries still expect only these three properties to be included within an error object. Adding anything else might give your users or colleagues a hard time using your API.

To battle this inflexibility, the GraphQL specification introduces the extensions object into any error object. Within these extensions, you can put anything you want, without giving clients a hard time interpreting your responses (technically, you only leave it up to them to discover and interpret them).

The error example from before can be extended with extensions like this:

{
  "errors": [
    {
      "message": "This somehow didn't work out well. Sorry.",
      "locations": [{ "line": 2, "column": 9 }],
      "path": ["thanks", "for", 1, "reading", "thisArticle"],
      "extensions": {
        "code": "INTERNAL_ERROR",
        "timestamp": "Su May 21 14:33:09 UTC 2023"
      }
    }
  ],
  "data": {
    "article": {
      "title": "The Ultimate Guide To GraphQL Error Handling",
      "author": "Oliver Jumpertz",
      "text": "..."
    }
  }
}

The extensions object can contain anything. There are no boundaries to what you can put there. It allows for a lot of flexibility, but it also has one huge issue: You cannot type it reliably.

Unlike entities in your GraphQL schema that can be strictly typed by deriving a type system from the schema, error extensions are (conceptually) only like a Map<String, Any>. There is nothing you can send within your response (except for some very nasty hacks like putting a whole JSON schema into each error’s extensions) to help clients generate type-safe code for your API’s (hopefully) standardized extensions.

Error extensions also have a second, smaller issue: It’s more difficult to access them. Unlike the usual GraphQL response that can easily be accessed from your favorite GraphQL client library, you need to put extra work into extracting the errors and their extensions to make them usable within a client’s logic.

When errors are difficult to handle in GraphQL, what then? What is it that you can do to improve the situation and make your API as usable as possible? How can you prevent a night full of coffee or energy drinks with Netflix running on the side while trying to come up with a suitable way to use your API?

You can first try to classify common errors and see whether you can apply different patterns to different kinds of errors because as you will see, not all errors need to be treated with all of someone’s energy.

Classifying Errors

It makes a lot of sense to first think about which types of errors (on a very high level) your API can actually experience. But which classifications make sense?

There are many ways to classify errors, from the lowest level to the highest one available, but in reality, there is one specific classification that makes the most sense: Classifying errors by their (un-)planned impact.

If you think about this for a moment, you will probably realize that it’s a good idea to think of errors as either wanted or unwanted states of your system.

Some errors are always unexpected. They just happen although you might not be happy about it. An upstream API may be unavailable, your database might be down, or sometimes the math your API performs just doesn’t add up.

Other errors are planned. Users aren’t logged in, there might be legal reasons that prevent you from showing content to users in certain regions (geo-blocking), or a user might simply need a subscription to view a specific page.

Now, you might look for names to give to these errors (given that planned and unplanned somehow don’t please you well, and I feel you), but we can come up with two very fitting names:

Technical errors and Business errors.

But before we go deeper into how to handle each class of errors, we should first take a look at the error classification and specify what technical errors and business errors really are.

Technical Errors

Technical errors originate from technical issues. Upstream APIs that are down, a faulty database, or even your API running out of memory are all errors that can be boiled down to technical issues. The list can be extended infinitely but you probably get the idea by now.

These kinds of errors are always unwanted. You can plan for them but never exactly tell when they will occur.

Errors like these are a necessary evil and you can usually not eliminate them. They belong to the product you build like every line of code you chew out.

Thankfully, they make up their own category and can all be handled just the same, which makes it easier to process and handle them in a way that also suits any client.

Technically, there is not much a client can do when such an error occurs. It can retry the request and see whether it gets another response that time, or it can simply show a banner with an error message and say sorry to the user, asking them to retry the action again later.

The important point about technical errors is that they can usually only be handled implicitly.

Business Errors

Business errors originate from the need of the business to create error states. Although your business analysts or product managers and owners or even yourself might not call them errors, technically they still are.

Errors like these are planned for. You expect and want them to happen in very specific circumstances. In these cases, there is simply no other way than to force the user to do something or deny them a specific action.

When a user encounters such a state, there is usually a plan for what should happen next (there really should be one). If some content is behind a paywall, there is often a process to make it as easy as possible for the user to upgrade to a paid plan. This usually involves a whole flow within your software, which in the end, brings the user back to the actual resource they tried to access after they spent money on your product.

At least theoretically, errors like these feel more like responses that lead to very specific actions, and this distinguishes them from technical errors. Unlike technical errors, business errors trigger specific actions. Or in other words: Business errors always need to be handled in a very explicit way. You want to force the client to do something based on that very specific response.

Handling Technical Errors

Going back to our initial definition of technical errors as errors that simply happen out of your control and the fact that you can’t do too much about them, there is one very convenient way to state their existence: An error object within the response.

As you can’t do very much about them, and given the fact that their occurrence usually hinders users of your API to proceed with whatever they wanted to do, an error object is the best way to make use of how most GraphQL clients handle errors by throwing some kind of exception.

If you encounter a technical error within your API, you can usually just throw an exception yourself and let the framework pick it up, map it into an error object within the response, or simply add it yourself.

Going back to the original, extended example, such a response can look as follows:

{
  "errors": [
    {
      "message": "This somehow didn't work out well. Sorry.",
      "locations": [{ "line": 2, "column": 9 }],
      "path": ["thanks", "for", 1, "reading", "thisArticle"],
      "extensions": {
        "code": "INTERNAL_ERROR",
        "timestamp": "Su May 21 14:33:09 UTC 2023"
      }
    }
  ],
  "data": {
    "article": {
      "title": "The Ultimate Guide To GraphQL Error Handling",
      "author": "Oliver Jumpertz",
      "text": "..."
    }
  }
}

Most clients will pick this response up, realize that there is an error nested within the response, and then act accordingly. Some clients will throw an exception that you have to catch and process, others will give you hints in other ways (but they all usually point you in the right direction).

The only thing you can then do is to at least extract the error message and display it in a popup, toast, banner, or wherever else you have planned to notify users of unsuccessful operations. This is the implicit error handling we talked about earlier (implicit because often, it is even enough to let a general exception handler do something about the error you don’t even care to handle yourself). There is just not much more you can do about it.

Handling Business Errors

After you have tackled the easier part of handling errors in GraphQL, it’s time to jump into deeper water: Handling business errors.

Let’s quickly look at a partial definition of business errors again:

They are planned for. They are expected. If they occur, you usually want clients to do something very specific to solve the issue.

In other words: You want to force the client to do something and not just ignore the error.

If you are only a little like me, you might already think about how you can do this: Force clients to do something. And you, like me, will probably realize that GraphQL already has the best way to force clients to do what you want: The schema.

Whatever you put inside the schema becomes the reality of the API. Entities, properties, types, etc. All that is already being enforced. GraphQL schemas can even be picked up by code generators and transformed into strictly and dynamically typed code.

Code and types are exactly what you need to solve this mystery. Especially types can force you to do so many things that you would usually (be honest. I’m also guilty!) just ignore and let be.

Unions in many languages, for example, are a great way to state that a type is either this, that, or that, or that, or…wait a second…Unions! That’s the specific answer to the problem of making business errors explicit.

A query with a potential business error means: Your query is either successful or unsuccessful. That’s a union with two possible types: Success and Error. And this is exactly how you can tackle the problem at hand. (Imagine borrowing the concept from Rust’s Result enum).

If any of your queries or mutations can have potential business errors, you can introduce a union to model all potential outcomes of the call. As unions don’t have a hard limit on how many member types they can carry, they are flexible enough to serve the use case.

Let’s look at a basic example of an API schema of an e-commerce system. For now, it only has one query that allows users to fetch a list of products:

type Query {
  productsByCategory(category: String!): [Product]!
}

type Product {
  id: ID!
  category: String
  name: String
  description: String
}

The query productsByCategory allows clients to fetch all products by a specific category. This implies that there also might be no products at all for a given category.

If no products are found, the list will simply be empty, which is enough for the client to handle this specific case. But what about some more exotic (and a little constructed) use cases? What if some of these products can not be sold worldwide? Trade and regional laws often differ, and sometimes, things that you can consume or buy in country A are simply banned in country B.

There are two ways to deal with this constructed case:

You simply leave the products out of the list
You tell people that these products are not available for legal reasons

If you go for the first case, you are instantly done and don’t need to spend more thought on this case. If you want to stay with me for a little longer and just assume for a second that the second case also isn’t far from reality, continue to read.

Let’s assume that the second case is exactly what your business wants. You can still give customers a hint that these products exist, and perhaps there are some relatives somewhere else that could potentially order these items and send them over (come on, we’ve all done this already. There is so much US food banned in Europe that is actually quite tasty…). Why should your business throw away this opportunity?

If you want to solve exactly this case, you can make use of a union with two member types:

A Product
A geo-restricted Product

The first one is the usual entity, while the second one can have other properties (but doesn’t necessarily need to). The second entity type however forces any client to handle this case right within its code, either through a simple if-statement, an instanceof check, or else.

Applying this to the schema, you end up with a schema that looks something like this:

type Query {
  productsByCategory(category: String!): [ProductResult]!
}

union ProductResult = Product | GeoRestrictedProduct

type Product {
  id: ID!
  category: String!
  name: String!
  description: String
}

type GeoRestrictedProduct {
  id: ID!
  category: String!
  name: String!
  reason: String!
  availableCountries: [String!]!
}

Instead of directly nesting a Product within the list, productsByCategory now returns a list of ProductResult‘s. The latter is a union that has two members: Product and GeoRestrictedProduct.

If a product is geo-restricted (and ignoring that some laws might prevent us from doing this…damn you legislature!), a client can explicitly handle this case and additionally render why a customer can’t order this product and in which other countries they are still available.

You can generally apply this pattern to all other use cases that potentially come to your mind. But we can do one more example to give you a better idea of how broadly applicable this pattern is.

Let’s look at Medium, the popular blogging platform. It allows you to post articles and additionally monetize them (if you sign up for it). This presents two potential cases to users:

A user is a subscriber and can pass the paywall
A user is not a subscriber and can thus only read an excerpt, with a call to action to subscribe (let’s ignore the two/three articles per month free thing here but we all use incognito tabs nevertheless, okay?)

If you want to model this in a GraphQL schema, you can come up with something close to the following:

type Query {
  article(id: ID!): ArticleResult
}

union ArticleResult = Article | RestrictedArticle

type Article {
  id: ID!
  title: String!
  author: String!
  text: String!
}

type RestrictedArticle {
  id: ID!
  title: String!
  author: String!
  excerpt: String!
}

When a user requests an article, the API can check whether they are logged in and subscribed to Medium. If so, the API returns an Article and the user can go on reading. If not, a RestrictedArticle is returned that only has an excerpt in it.

Any client is forced to handle the case of a RestrictedArticle without having to check the status of the user itself. Everything is left to the backend to decide. In case of Medium’s main page, the user is presented the usual view of an excerpt of an article with a call to action to upgrade if they want to continue reading.

This is the power of this pattern. It allows you to force clients to do something explicitly. Even if someone else decides to implement their own client for your API, you can still dictate to them what to do in certain circumstances without having to directly communicate with them. It can all be done through the schema of your API.

With this issue solved, there is only one border left to conquer. Something for companies that take GraphQL very seriously and spend a lot of money on flexibility, technical toys (and sometimes nightmares): Federated GraphQL.

Handling Business Errors In Federated GraphQL APIs

Apollo Federation is an addition to the GraphQL specification. Its idea is to allow multiple GraphQL backend services to be composed into a single API surface, without the need to implement an API monolith.

To make this happen, Apollo Federation extends the GraphQL specification and adds new directives that are used by a central service, called Router (or older Gateway), to derive a query plan for incoming requests.

In federated Graphs, entities can be shared and referenced among individual GraphQL services (called subgraphs). It’s easy for one subgraph to add a property pointing to an entity that is served by another subgraph because the Router takes care of fetching the data before a unified response is sent back to a client.

This system, however, has limits. One of these limits is the fact that unions cannot be referenced and shared between subgraphs. This is simply for the reason that unions cannot be uniquely identified by a type and an id.

You can still make this pattern work in such a federated graph by extending it and adding a layer of indirection, which does not look very beautiful (to be honest), but does its job well.

Let’s first look at a very simple API for a blog. It serves articles and authors through one, unified API, and its schema looks as follows:

type Query {
  article(id: ID!): Article
}

type Article @key(fields: "id") {
  id: ID!
  author: String!
  title: String!
  text: String!
  author: Author!
}

type Author @key(fields: "id") {
  id: ID!
  name: String!
  articles: [Article]
}

Each Entity (Article and Author) is served by a different subgraph and defined in its schema. When both schemas come together, the result is what you see above (ignoring the fact that federated API schemas usually have a lot of boilerplate code, like directives and such, inside them).

Let’s now go back to the paywall example from before (because we all want to earn money somehow, don’t we? I’m not judging you! Content creation is a serious business and takes more time than many of us would like to admit.).

Let’s also assume we want the following to happen:

Authors should always be viewable publicly (Who puts authors behind paywalls anyway?!)
Articles can either be behind the paywall or free

An issue now arises from the fact that we (as the good engineers we are) have modeled a real graph where both sides of an entity relationship have a reference to the other side (Article references Author, Author references multiple Articles. You can navigate in both ways.).

Applying our previous solution would result in Article becoming a union called something like ArticleResult. But unions can’t be referenced by other subgraphs. The Author subgraph would lose its reference, which is nothing you should favor. So, what now?

You can add a (relatively ugly but necessary) indirection into the schema to make the whole system work again. Even if a union cannot be referenced by other subgraphs, a wrapper entity that contains a property that points to a union can (this sounds more complex than it actually is). If the Author subgraph references that entity, a client can then unpack the nested result union (with more code), but still be forced to handle all possible cases.

Let’s look at the resulting schema, so you better understand where this is going:

type Query {
  article(id: ID!): Article
}

type ArticleWrapper @key(fields: "id") {
  # same as the nested
  # entity's id
  id: ID!
  article: ArticleResult!
}

union ArticleResult = Article | RestrictedArticle

type Article {
  id: ID!
  author: String!
  title: String!
  text: String!
  author: Author!
}

type RestrictedArticle {
  id: ID!
  author: String!
  title: String!
  excerpt: String!
  author: Author!
}

type Author @key(fields: "id") {
  id: ID!
  name: String!
  articles: [ArticleWrapper]
}

Article has lost its @key directive. This is because it no longer needs it. Only entities that can be referenced by other subgraphs need such a directive. Instead, ArticleWrapper is now the entity that can be referenced by other subgraphs. Nested within it is the union you already know, and within that union, both possible types are present. (I told you it wouldn’t be beautiful). An Author now references an ArticleWrapper instead of an Article.

This small workaround allows you to keep all the benefits of this pattern while enabling the use right within a federated schema. Clients are still forced to explicitly handle scenarios you want them to handle, and you only pay a small (depending on how you view it) price with one further indirection (which bloats code a little, but nothing a dedicated API lib cannot solve).

Summary

Writing good GraphQL APIs is no easy task and handling errors puts an additional burden on you. But there are ways to handle especially errors in a way that benefits both you as an API’s creator and your users (or colleagues) who implement clients for it.

By first classifying errors into two categories, technical and business errors, you open up a way to handle each category as best as possible.

Technical errors are errors that you usually don’t want to happen, but they happen nevertheless. You can’t circumvent them but still somehow need to deal with them. Their impact, however, is often larger because they hinder people from progressing further in your software. Still, you can often only handle them implicitly by catching and presenting some form of error message to your users.

Business errors are errors you expect to happen because they belong to the design of the flow of your API or software. Geo-blocking, paywalls, or else are usually examples of these kinds of errors. You want to handle them explicitly because their occurrence usually leads to a different flow in your application. You also often want to force users of your API to react to them without too obvious ways to circumvent handling these cases.

In case of technical errors, you can use the errors within the GraphQL response and give general directions on what happened and leave a message for users to read. General catch blocks can then pick up the errors forwarded by GraphQL clients and do something with them.

In case of business errors, you can use techniques to design your schema in a way that forces anyone who uses your API to take care of these kinds of errors when they occur. You can achieve this by using unions that model results, which are types that can be either this or that or even more.

In federated environments, you have to put in a little more work to make the pattern of presenting business errors feasible. This is achieved by adding an indirection and a further abstraction in the form of a wrapper that then contains the already-known union type that models the actual response. This ensures that entities can still be referenced by other subgraphs without further technical limitations.

How to Write Files in Rust

Oliver Jumpertz — Fri, 19 May 2023 21:06:01 +0000

All software has to write data to the file system at some point. This is also true for programs written in Rust. Log messages need to be persisted (as long as they are not just written to stdout), and data needs to be saved for later, or else. Naturally, writing data is the opposite of reading data.

There are multiple ways to deal with writing data to files in Rust. Some of these ways are easier than others, but all have their justification. Sometimes you directly want to write text into a file, and other times you write some kind of binary format. No matter your use case, Rust probably has a way to deal with it.

In this article, you will learn about common ways of how to write files in Rust.

Just in case you enjoy YouTube videos more than an article, you can also watch the video above instead!

Writing All Data to a File at Once

Regularly, you only want to persist data that you already have in memory. In this case, this method is one of the most straightforward ways to deal with it.

It allows you to write all data at once, and it doesn’t matter whether your data is a String or already in binary format. Additionally, a file is conveniently created for you if it does not exist yet.

Its advantages include:

It is convenient to use
It is merely one line of code
fs::write takes care of everything for you

As usual, this method also has a few drawbacks, which are:

It always overwrites the file
Its performance highly depends on the size of your data – the more data you write, the longer it takes

If this is what you are looking for, then take a look at the following code as an example of how to write all data to a file at once:

use std::fs;

fn write_string_to_file(path: &str, data: &str) -> Result<(), Box<dyn std::error::Error>> {
    fs::write(path, data)?;
    Ok(())
}

fn write_data_to_file(path: &str, data: &[u8]) -> Result<(), Box<dyn std::error::Error>> {
    fs::write(path, data)?;
    Ok(())
}

Writing All Data to a File at Once With the fs::File API

The method above is just a convenient wrapper around this method, which gives you a bit more control over how you deal with a file and its contents.

The only difference here is that there is no convenient under-the-hood conversion of Strings into binary. This is something you need to do yourself, in this case.

The advantage of this method is the following:

It is still convenient to use
It only takes a few lines of code, depending on how you do it
It’s flexible to extend and alter

And its drawbacks include these:

It always overwrites the file – no appending
Its performance highly depends on the size of your data – the more data you write, the longer it takes

If that’s okay for you, you can take the following code as a starting point for your own implementation:

use std::{fs, io::Write};

fn write_string_to_file(path: &str, data: &str) -> Result<(), Box<dyn std::error::Error>> {
    let mut file = fs::File::create(path)?;

    // You need to take care of the conversion yourself
    // and can either try to write all data at once
    file.write_all(&data.as_bytes())?;

    // Or try to write as much as possible, but need
    // to take care of the remaining bytes yourself
    let remaining = file.write(&data.as_bytes())?;

    if remaining > 0 {
      // You need to handle the remaining bytes
    }

    Ok(())
}

fn write_data_to_file(path: &str, data: &[u8]) -> Result<(), Box<dyn std::error::Error>> {
    let mut file = fs::File::create(path)?;

    // You can either try to write all data at once
    file.write_all(&data)?;

    // Or try to write as much as possible, but need
    // to take care of the remaining bytes yourself
    let remaining = file.write(&data)?;

    if remaining > 0 {
      // You need to handle the remaining bytes
    }

    Ok(())
}

Appending Data to a File

You don’t always want to overwrite your files. Sometimes, you process things in a loop and don’t want to create a huge String or byte array before you dump your data. Such methods also help to keep the memory profile of your Rust binary low.

If you want to append data to an existing file, there is a convenient method for it. It uses fs::OpenOptions which allows for granular control over how the file is opened.

The advantages of this method include the following:

You gain full control over how the file is handled
It still only takes a few lines of code, depending on how you do it
The performance of this method depends on you size the data you write

As usual, this method has some drawbacks, as well:

Every call is a potential system call
Every call writes to the file system, which can be costly if the data size is not optimal

If this method seems like something you want to use, you can see an example below:

use std::{fs, io::Write};

fn append_string_to_file(path: &str, data: &str) -> Result<(), Box<dyn std::error::Error>> {
    let mut file = fs::OpenOptions::new().create(true).append(true).open(&path)?;

    // You need to take care of the conversion yourself
    // and can either try to write all data at once
    file.write_all(&data.as_bytes())?;

    // Or try to write as much as possible, but need
    // to take care of the remaining bytes yourself
    let remaining = file.write(&data.as_bytes())?;

    if remaining > 0 {
      // You need to handle the remaining bytes
    }

    Ok(())
}

fn append_data_to_file(path: &str, data: &[u8]) -> Result<(), Box<dyn std::error::Error>> {
    let mut file = fs::OpenOptions::new().create(true).append(true).open(&path)?;

    // You can either try to write all data at once
    file.write_all(&data)?;

    // Or try to write as much as possible, but need
    // to take care of the remaining bytes yourself
    let remaining = file.write(&data)?;

    if remaining > 0 {
      // You need to handle the remaining bytes
    }

    Ok(())
}

Writing and Appending Data to a File with BufWriter

All previously presented methods have one thing in common: They always try to write everything you give them at once, and they offer no flexibility in this regard.

If you are looking for a way to write large chunks of data consistently without impacting the performance of your program, you can use a BufWriter. Internally, a BufWriter buffers the data it receives and tries to optimize the way it writes it to the file system.

This method requires not many new concepts and even uses the APIs you have already learned about above. Additionally, it also has a few advantages:

You have full control over how the file is handled
It gives you a lot of flexibility
A BufWriter optimizes access to the file system under the hood

Gladly, there are only two drawbacks to this method:

It can be a little more difficult to use
It takes a little more code to implement

If you want to use the most flexible way to write data to files, check the code below for an example:

use std::fs;
use std::io::{BufWriter, Write};

fn append_string_to_file(path: &str, data: &str) -> Result<(), Box<dyn std::error::Error>> {
    let file = fs::OpenOptions::new().create(true).append(true).open(&path)?;
    let mut file = BufWriter::new(file);

    // You need to take care of the conversion yourself
    // and can either try to write all data at once
    file.write_all(&data.as_bytes())?;

    // Or try to write as much as possible, but need
    // to take care of the remaining bytes yourself
    let remaining = file.write(&data.as_bytes())?;
    if remaining != 0 {
        // handle...
    }

    // You definitely need to flush a BufWriter
    // as it cannot guarantee emptying its buffer
    // when it goes out of scope
    file.flush()?;

    Ok(())
}

fn append_data_to_file(path: &str, data: &[u8]) -> Result<(), Box<dyn std::error::Error>> {
    let file = fs::OpenOptions::new().create(true).append(true).open(&path)?;
    let mut file = BufWriter::new(file);

    // You can either try to write all data at once
    file.write_all(&data)?;

    // Or try to write as much as possible, but need
    // to take care of the remaining bytes yourself
    let remaining = file.write(&data)?;
    if remaining != 0 {
        // handle...
    }

    // You definitely need to flush a BufWriter
    // as it cannot guarantee emptying its buffer
    // when it goes out of scope
    file.flush()?;

    Ok(())
}

Summary

While developing software, you often have to write data to files. As usual, Rust is no different than other languages when it offers multiple ways to perform these kinds of operations. In this article, you learned about four different ways to write files in Rust.

Like always in life, everything you do can have both advantages and disadvantages; thus, the concept is no different in this regard. You always have to spend a few thoughts and think about which way is the best for your specific use case.

Writing all data at once is a great way to perform the action with as little code as possible. Additionally, you don’t have to worry too much about the format of the data. This convenience comes at a cost, though. The more data you need to write, the larger your memory grows, and there is no control over preventing an existing file from being overridden.

Writing all data at once with the File API is another way to perform the action of dumping all your data onto the file system. Unlike its wrapper API, it offers you more flexibility in handling this process. You also lose the flexibility of a convenient API that does conversion if you deal with Strings. Additionally, the problem with large data blobs remains. A lot of data means a lot of memory.

Appending data to a file with the OpenOptions API brings even more flexibility than all previous methods. Here, you don’t have to worry about the size of your data. You append data to a file as you process it and can keep a lower memory profile. This method needs some fine-tuning, though. Appending data often leads to system calls that are sometimes pretty costly, so there is still room for improvement.

Finally, using a BufWriter gives you the most flexibility, but it’s also a relatively low-level approach to performing write operations. The BufWriter itself does at least buffer the data for you, but its effectiveness still depends on your usage. If you don’t take care while implementing your write operations with a BufWriter, you can also quickly sabotage all your efforts at improving the performance of your program.

How to Read Files in Rust

Oliver Jumpertz — Sun, 07 May 2023 18:01:44 +0000

Reading files is one of the most common operations you can come across in software development. Loading configuration files, processing files, and more are often part of the use case of the software you build.

Like in any other programming language, there are multiple ways how to read files in Rust. However, all have their advantages and disadvantages. This is why it is crucial also to understand which method to use in which case.

In this article, you will learn about Rust’s most common ways to read files.

Just in case you enjoy YouTube videos more than an article, you can also watch the video above instead!

Reading an entire File into a String

Reading an entire file into a String has its advantages. You don’t need to worry about anything other than handling the file and processing its content. This is an excellent choice for files that:

Contain String content
Can be processed as a whole at once

On the other hand, this method also has its drawbacks:

Files too large might have severe performance impacts
The larger the file, the larger the memory consumption of your program
Files that do not contain String but binary content can’t be processed this way

The following example shows how to read a whole file into a String:

use std::fs;

fn read_file_content_as_string(path: &str) -> Result<String, Box<dyn std::error::Error>> {
    let string_content = fs::read_to_string(path)?;
    Ok(string_content)
}

Reading an entire File into a Byte Vector

Reading an entire file into a byte vector is the way to go if you don’t necessarily have to deal with String content but some form of binary format you need to process. This method still works for String content, though. Instead of directly receiving a String from the method call, you have to instantiate it yourself. You don’t have to do that if you don’t deal with String content.

This method is a great choice for files that:

Contain any form of content
Can be processed as a whole file at once

Still, some of the same drawbacks that also affect reading an entire file into a String apply. These are namely:

Files too large might have a severe performance impact
The larger the file, the larger the memory consumption of your program

The example below demonstrates how to read a whole file into a byte vector:

use std::fs;

fn read_file_as_bytes(path: &str) -> Result<Vec<u8>, Box<dyn std::error::Error>> {
    let byte_content = fs::read(path)?;
    Ok(byte_content)
}

If you still want to convert the byte vector into a String yourself, you can do it as follows:

use std::fs;
use std::str;

fn read_file_as_bytes(path: &str) -> Result<String, Box<dyn std::error::Error>> {
    let byte_content = fs::read(path)?;
    let string_content = str::from_utf8(&byte_content)?;

    Ok(string_content.to_string())
}

Reading a File Line by Line

As stated above, reading an entire file at once can lead to problems if you deal with large files. In cases like this, it’s best to process these files with a line-by-line approach. This is, of course, something mostly applicable to files with String content.

Rust gladly has a convenient struct in its standard library that also takes away some lower-level details, called BufReader. This method is a solid choice for files that:

Contain String content
Are too large to be processed at once

This approach, however, also has a few drawbacks that need to be mentioned, and these are:

It only works for files with String content
Implementations can quickly become more complex
Depending on the formatting of the file, you might have to buffer lines yourself if not everything you want to process is placed on the same line

The following example shows how to read a file line by line:

use std::fs::File;
use std::io::{BufReader, BufRead};

fn read_file_line_by_line(path: &str) -> Result<(), Box<dyn std::error::Error>> {
    let file = File::open(path)?;
    let reader = BufReader::new(file);

    for line in reader.lines() {
        match line {
            // line is a String
            Ok(line) => process_line(line),
            Err(err) => handle_error(err),
        }
    }

    Ok(())
}

Reading a File in Single Byte-Steps

While the previous approach allowed you to read a file line-by-line, this one allows you to read individual bytes from the file you want to process with a BufReader. It is one of the most basic approaches as you put away nearly all guard rails the standard library gives you. It does, however, give you some of the most flexibility.

Use this approach if you:

Need complete control over what happens with the content of a file
Are perfectly fine to implement a lot of the content handling yourself
Have to deal with large files that would make your memory consumption explode if read all at once

Although already mentioned, it is still a good idea to talk about the drawbacks of this method, as well. Its drawbacks include:

You have to work with raw data. In this case, its even single raw bytes
You probably still need a buffer to temporarily save single bytes until you can merge several of them into something more meaningful

The following example demonstrates how to read a file in single byte-steps:

use std::fs::File;
use std::io::{BufReader, Read};

fn read_file_as_single_bytes(path: &str) -> Result<(), Box<dyn std::error::Error>> {
    let file = File::open(path)?;
    let reader = BufReader::new(file);

    for byte in reader.bytes() {
        match byte {
            // byte is exactly one byte
            Ok(byte) => process_byte(byte),
            Err(err) => handle_error(err),
        }
    }

    Ok(())
}

Reading a File in Byte Chunks

You can use BufReader to read chunks from a file if you want more flexibility. To be completely honest, BufReader also does optimizations under the hood and doesn’t read each byte individually when you use its .bytes() method. It reads them in chunks and then returns single bytes from the Iterator.

That doesn’t help much when you want to process chunks yourself, though. You can, of course, buffer the bytes manually when using bytes(), or you simply follow this method.

Reading the content of a file in byte chunks has advantages and disadvantages like any other method. Its advantages are:

You gain complete control over how you deal with the contents of a file
It gives you the most flexibility, as you can adjust the chunk size dynamically and react to specific circumstances
You can use it if you have to deal with large files that would make your memory consumption explode if read all at once

Of course, there are once again a few known drawbacks that apply to this method:

You have to work with raw data. All decoding and processing is up to you
It might take a few attempts to optimize the buffer size for specific scenarios
If you make the chunk size too small, you might actually hurt the overall performance of your program (too many system calls)

The example below shows how to read a file in byte chunks:

use std::fs::File;
use std::io::{BufReader, BufRead}

const BUFFER_SIZE: usize = 512;

fn read_file_in_byte_chunks(path: &str) -> Result<(), Box<dyn std::error::Error>> {
    let file = File::open(path)?;

    let mut reader = BufReader::with_capacity(BUFFER_SIZE, file);

    loop {
        let buffer = reader.fill_buf()?;

        let buffer_length = buffer.len();

        // BufRead could not read any bytes.
        // The file must have completely been read.
        if buffer_length == 0 {
            break;
        }

        do_something_with(buffer);

        // All bytes consumed from the buffer
        // should not be read again.
        reader.consume(buffer_length);
    }

    Ok(())
}

Summary

Reading files is a common operation when developing software. Like any other programming language, Rust offers several ways to deal with it. This guide covered five common ways to read files (both as Strings and in raw binary format) in Rust.

All methods presented have advantages and drawbacks, and you need to choose the one appropriate for your specific situation and use case.

Reading an entire file into a String is a great choice if you have small files and deal with String content. On the other hand, the method is not the best if your files become larger or you don’t deal with String content at all.

Reading an entire file into a byte vector is a good choice if you have small files and deal with arbitrary raw content. It is lacking if your files become larger and you have memory constraints, though.

Reading files line by line is an excellent choice if you deal with String content and don’t want your memory to grow too much. The method falls short if you don’t deal with String content, and have files that spread the content you want at once over multiple lines, which requires you to buffer lines yourself.

Reading files in single byte-steps is one of the most basic methods. It’s a great choice if you want flexibility and need a lot of control. On the other hand, you need to work with raw data and also have to probably buffer data yourself if you need to merge multiple bytes into something more meaningful.

Lastly, reading a file in byte chunks is a little more flexible than reading each byte individually. It offers full control over the processing of the data and can also be adjusted dynamically. But once again, you need to work with raw data, and it might take some time to fine-tune the chunking.

Your Guide To Computer Science Fundamentals

Oliver Jumpertz — Wed, 23 Nov 2022 10:29:07 +0000

Computer science fundamentals are the foundation of any software developer's job. Starting with how a computer works, over logic, maths, algorithms, and data structures, and ending with networking and I/O. Any developer should at least have basic knowledge about these fundamentals. This is why Your Guide to Computer Science Fundamentals exists.

Many of the concepts presented in this guide are things you will just use on a day-to-day basis as a developer, others are used less frequently. The important part is still having some knowledge about them in the back of your head.

This guide comes with a mix of practical advice and a collection of learning resources you can use to advance your knowledge in the respective fields. While this guide can probably be read within a few minutes, you will need way longer to fully understand all the topics covered.

What Fundamentals are And why they are Important

Fundamentals are concepts, and maybe even techniques, that you can apply in multiple areas and multiple programming languages. They are not tied to anything specific and are sometimes pretty theoretical.

The importance of these fundamentals comes from the fact that they build the structure the rest of your programming and development knowledge is based on. Without knowing how a computer works, it becomes more difficult to understand what a programming language actually is and why the instructions you type in are the way they are.

It can take a long time to learn all the fundamentals there are, and it can cost a lot of energy to stay motivated. In the end, however, every piece of fundamental knowledge you acquire speeds up the learning process for everything else that is based on it.

Too many young or inexperienced software developers jump right into frameworks when they learn how to program. Later, they face problems that are not solved that easily if they don't know how the underlying technology or concept works. Just take networking as an example: It is very easy to perform remote requests these days, but if the underlying network has problems, you might be clueless as to why your requests are never successful. Knowing at least that a network exists and how it approximately works can help with the debugging process.

The Most Important Fundamentals

Here is a list of the most important ones:

How a computer works
What a programming language actually is and does
Logic
Math
Algorithms
Data Structures
Networking / I/O

This list seems long and contains many very broad topics, but if you get broad knowledge in these topics, your chances are high that your programming and software design skills will profit from it a lot. And in return, you will learn new frameworks faster, your code will become better, safer, and more resilient (because you know what awaits you).

This guide will go through these fundamentals a little more in-depth soon, so don't worry that you are left with only a list of topics you have to dive into yourself. Just know that these exist for now.

How to Learn the Fundamentals

There are multiple strategies for learning something. One approach might be to just try to learn everything at once and then jump into more advanced topics. Another approach might be to learn as you go. Overall, there is no overall correct approach. There is only the approach that suits you best.

No matter what way you take, there are a few key concepts that can help you along the way.

1. Use curiosity to your advantage

No matter whether you try to learn everything up front or along the way, always give in to your curiosity.

Dive a little deeper whenever you become curious because you don't know something yet. Make a small list and note down all the topics or questions you discover. This ensures you can take care of learning more about it at a later point.

As long as you are curious, chances are high that you are willing to go even down a rabbit hole, and your brain will most probably be more welcome to consume the information you find. This can also have a positive effect on your motivation.

2. Don't overwhelm yourself

It might often seem tempting to learn everything at once, but most people do best when they learn one topic at a time. This is where a list of topics and questions comes in handy. You always have something to return to later without fearing that you forget what topics you want to research.

You should also make sure to take frequent breaks. There are studies that show that frequent breaks only help you refresh your energy faster and thus enabling you to learn more in less time. The worst thing to happen is not remembering everything from a 2-hour hardcore study session on a complex topic.

3. Revisit topics regularly

Repetition is one major key to learning efficiently and effectively. Reading something once is not enough to build long-lasting connections in your brain. Revisiting topics regularly, especially if you don't come in contact with them often, helps you keep the crucial knowledge you worked hard for.

If you work with a list, like already proposed, don't throw it away as soon as you are done. Try to keep it and think about persisting it (Notion, a Todo app, etc.) while additionally attaching your notes to each point. This gives you a great personal learning resource you can revisit again and again whenever you see the need arise.

4. Connect with peers or a mentor

There are many more developers who still need to cover computer science fundamentals. If you have a chance, try connecting with them and learning together. You can exchange your learning materials, explain concepts, and motivate each other to continue this interesting journey. A short weekly call where you talk about your last week of learning and share important discoveries can already be enough.

Another way is to find a mentor. That is usually a developer with more experience than you, who already knows their way around these fundamentals. Admittedly, finding a mentor is difficult these days, but if you can find one who is willing to help you, take the chance. A mentor can help you in many ways. They can guide you, provide you with explanations, share learning material with you, and much more.

Now that you are prepared with crucial knowledge of what fundamentals are, why they are important, and how you should approach learning them, it is time to get into them.

How A Computer Works

The most basic knowledge of a software developer is understanding how a computer works. The level you work at is already so far away from the current running through wires and circuits inside your computer that it is often hard to even imagine how this can work at all.

This knowledge doesn't benefit you directly as modern operating systems and programming languages hide these details from you perfectly, though, but it is also foundational knowledge to understand how information travels through networks (and especially the internet as a network on a global scale).

Next to knowing that bits and bytes exist, knowing how they are stored in your computer's memory (and even in your CPU's cache) or on your hard drive is crucial information for any developer. It helps you understand that certain ways of storing information are slower than others and can indeed affect the performance of your software.

Finally, it's always incredible to be able to explain in detail how someone's smartwatch works at parties, isn't it? Because conceptually, a smartwatch and a smartphone are also just smaller computers, and most people will probably be quite happy (actually not) if you tell them everything they always (hint: they probably didn't) wanted to know about their devices.

What you should know

There is a whole lot to know, and knowing everything probably won't benefit you (except if you are really into hardware engineering and design), but a few key concepts are a necessity for developers:

How current and transistors actually bring your PC to life
What a CPU is and how it works
What memory is and how it works
How an operating system makes a computer usable for ordinary people and what it provides to developers

Where you can learn about computers

Many resources on the internet can teach you a lot about computers and how they work. It would probably take ages to list them all here. The following list is thus only an excerpt and a starting point for you to dig deeper and learn more (if you wish to):

Computer Fundamentals by Javatpoint

This is an excellent guide for beginners by Javatpoint, and it covers the most important points (and even a bit more). It's a great starting point to learn everything you can about computers.

Introduction to Computers by the University of Rhode Island

This is another great entry guide to computers by an actual university. The only drawback to it is that you can only navigate by iterating over the resources (Reading01.html -> Reading02.html -> Reading03.html -> etc.).

Learn Computer Science

This is an online course on how computers work. If you prefer a whole guide, including videos, this might be the right one for you.

What A Programming Language Actually Is And Does

When you have a basic understanding of how a computer works, you need to understand that the high-level languages most of us work with do a lot to abstract away low-level details.

There are many different programming languages nowadays, and every one of them has a special purpose (even the esoteric ones, although they often prove a specific point instead of being created for a specific purpose).

A crucial thing to understand with programming languages is that all of them end up as machine code in one way or another. And that machine code is somehow mapped to a processor's instructions. Some code results in more machine code than others, and some results in less. At least understanding why this is the case and how it can affect the performance of your software is knowledge that can come in handy depending on where you end up working.

What you should know

You should at least understand the following:

A programming language is a set consisting of
- A specification
- Tools
- Sometimes a runtime
Why different programming languages exist
What purpose different programming languages have
What manual memory management is
How a garbage collector works

Where you can learn more about programming languages

You can search for days and find new articles and guides on this topic. The internet is just a vast place of information. To give you a general direction, though, here are some resources that you can start with:

Programming language by McGill University

A small introduction to programming languages, what they are, and what they do.

Programming Language by Javatpoint

A good introduction to programming languages at a higher level.

Memory Management - Wiki Books

This a good entry into memory management and why it is necessary.

Fundamentals of garbage collection by Microsoft Learn

A guide on garbage collection that helps you understand what these garbage collectors actually do and how they manage memory for you.

Logic

Logic is an integral part of programming. Although it is actually a subarea of mathematics, it has a crucial place in any developer's tool belt, which is why it is mentioned separately.

Without logic, there would be no way to write effective software. Everything would run always or never, without any middle way. If this happens, then do that is just a fundamental construct. It is so important that every language has at least one construct (if, else if, else, and often also switch) to enable working with it.

Once you have conditions, you are confronted with Boolean algebra. That is another subarea of math (and of logic, which makes up the algebra of operations. With boolean algebra, you can evaluate and simplify your statements and much more.

What you should know

If you plan to stay in software development for longer, you should try to learn as much as possible about logic and boolean algebra. At least you should learn the following:

What mathematical logic is
How mathematical logic works
Set theory
Boolean algebra
Operators

Where you can learn more about logic

There are a few noteworthy resources that you should definitely take a look at:

Khan Academy

Khan Academy is a free learning platform that aims at teaching many subjects, including STEM. It has a well-curated section on math and logic, which is why it must be listed here.

Logic Matters

Peter Smith has done a great job at writing a book about mathematical logic for beginners. It is well worth downloading and reading.

Boolean Algebra & Logic Gates by Study.com

A few videos are never bad in a study mix. If you are more the kind of a visual learner, these lessons might be great for you.

Math

Computers are pretty good at math. This is why a lot of software deals with math problems (with difficulties ranging from easy to insane) every day. Every frontend, for example, does regularly need to calculate the position of certain UI elements, and a lot of business software takes care of accounting tasks and needs to calculate costs or else.

Sooner or later, every software developer is confronted with a more or less simple math problem. Thus, having some maths skills doesn't hurt at all. It simplifies many tasks and can often also help with designing efficient algorithms.

Even if you never stumble upon a math-related problem in all your career (and I highly doubt it), you will probably need to calculate an average or median at some point (especially when evaluating the performance of your software) or sum up a few numbers and find the standard deviation.

What you should know

Math is an ultra broad topic with many subareas that themselves are probably deeper than the mariana trench. It is thus really difficult to state how much you should know. Generally speaking, you should try to learn as much as possible, but if math really is not for you, you should at least focus on a few key areas:

Basic algebra
Calculus
Linear algebra (especially useful in the frontend but also for UI work in general)

Where you can learn more about math

As usual, the internet is full of resources, but if you only have the time and resources to visit just one resource, let it be the following one:

Khan Academy

You probably already know Khan Academy from the section on logic. It is really an incredible resource if you want to learn math, and it thus deserves a second spot in this guide.

Algorithms

Algorithms are the bread and butter of any software developer. Each line of code you write contributes to an algorithm, even if it only prints a single statement to the console. Without algorithms, there would be no software at all.

An algorithm is a way or a set of instructions the computer follows to get an expected result. If you think about this for a moment, you probably understand that everything you do is an algorithm. The computer always follows your instructions precisely to get the output you intended (or not - nasty bugs) to get.

Additionally, practicing your algorithmic skills also trains your own brain to think more like a developer and how to approach certain problems with a computer, which often differs fundamentally from how you would approach them in the real world. The more you practice, the better you become at solving problems. The better you become at solving problems, the easier it becomes for you to create solutions.

What you should know

You should touch a few basics at least once in your career because other software craftsmen spent years discovering these basic techniques. Next to that, you should, of course, also train your skills outside of these well-known fields.

To give you a general idea, here is a (non-exhaustive) list:

Backtracking
Greedy Algorithms
Divide & Conquer
Branch and Bound
Dynamic Programming
Randomized Algorithms
Brute-force or exhaustive search
Simple algorithms without any special technique
- e.g., just a sequence of statements to solve a specific problem

Where you can learn more about algorithms

Algorithms usually come together with data structures, which is why you will probably cover a good chunk of the next section with this one. Nevertheless, algorithms themselves are not mutually tied to data structures, as you have already learned, and thus learning algorithms on their own definitely is a good idea. A few good resources to get started are the following:

Courses on algorithms on edX

edX is a learning platform dedicated to bringing university-level education to anyone. They have a large section on algorithms, and a few of those courses are well worth taking.

Algorithms on geeks for geeks

Geeks for geeks is a big platform these days, with many resources on nearly everything related to software development. Their section on algorithms is a good entry point to get started.

Data Structures

Data structures are often dreaded because many companies still or used to ask questions about them in technical interviews. Many of those interviews involve reimplementing common data structures on a whiteboard or paper. Although this practice is questionable, it has done a lot to make many developers fear this special area of software development.

Generally, data structures are just a common way to collect and interlink data. Like a drawer where you probably store a few important documents, data structures store data that a developer wants to access sooner or later. Every data structure has advantages and drawbacks. Some take longer to insert data, some take longer to retrieve it again.

Knowing the characteristics of data structures is important for a software developer because it influences the runtime of algorithms and software as a whole. A wrong data structure chosen for a specific task can make the difference between an instant response or having to wait a second.

What you should know

A good software developer should know which classes of data structures exist and what types there are. You should also know the most important characteristics of those data structures and their runtime behavior. Being able to implement them by yourself is also a great goal because if you can do that, you probably know everything about them, but it is not an absolute must.

Generally speaking, you should look at the following data structures that all of their own sub types:

Arrays
Lists
Sets
Queues
Stacks
Trees
Graphs

Where you can learn more about data structures

You already know that algorithms and data structures are usually interlinked and taught together. This is why you will find the same type of resources here as for algorithms:

Data structures on edX

You probably already know edX from algorithms. No wonder they also have a section on data structures.

Data structures on geeks for geeks

The same as above. Geeks for geeks has a good section on data structures, as well. If you liked their guides on algorithms, you will probably also like their guides on data structures.

Networking / I/O

Depending on how deep you already dug while learning about how computers work, you might probably already have touched this topic. No matter whether you did or not, networking and I/O are crucial aspects of modern software.

Chances are high that you view this article in a browser on one of your devices (a notebook, a desktop PC, a smartphone, a tablet, or whatever else). This means that the content of this guide was transferred to your device over the internet. Its contents were probably read from a database (that stores data on a hard drive and in memory), sent over your local network to your router, through many more routers and switches until it reached your own router, and through your local network until your device's browser was able to render the page.

Most modern software uses some form of I/O these days. It either reads from or writes to files or accesses servers elsewhere in the world. With all this I/O, a whole new class of issues can arise, and it also leads to interesting design challenges for software. If you know how all this works at least approximately, you can save a lot of time trying to solve issues that you will face while developing software.

What you should know

Networking and I/O are both pretty broad topics. You can basically learn everything from fundamental concepts down to how routers and switches route packets. As a software developer, however, you don't need to know everything in-depth. A few basics like the following are enough, but the deeper you dig the better:

How a network works
How routing works
How hard drives work

Where you can learn more about networking and I/O

As usual, the number of resources is overwhelming, but here are a few you can start with:

The Fundamentals of Networking by IBM

This guide by IBM is not the largest, but it comes with a good level of detail and can be a starting point for you to search further.

How a Hard Drive Works by Stanford

Hard drives store your data. Software regularly needs to access this data, and this resource comes with a great video that explains the fundamentals to you.

Wrap Up

This is the end of this guide. If you prepared yourself well, you now hopefully have a list of topics you can use as a starting point for your learning journey. If not, quickly prepare one (you will thank me later).

Slowly start to work through these topics and fill the gaps you discover accordingly. And don't worry if you take longer to understand something. Computer science is far from easy. Sometimes it takes several tries or a longer break to finally grasp a complex concept.

Always keep in mind that you might not get the reason for learning some of these topics immediately. One day, you might be thankful for having something in the back of your head, though.

The Ultimate Smart Contract Developer Roadmap

Oliver Jumpertz — Mon, 07 Feb 2022 09:10:03 +0000

2022 could be the year you get into smart contract development. The market has a high demand for developers knowing their way around Solidity for Ethereum, and this is why the following roadmap could potentially help you get your foot in the door. Furthermore, with average salaries of around $150k for remote positions, Solidity developers can earn pretty well, even working from home. And even better, by learning Solidity and this development stack, you become proficient on multiple blockchains at once. From Ethereum, to Polygon, Binance Smart Chain, Avalanche, and more, Solidity covers them all.

This roadmap is a long-term investment. It's nothing you finish in one day and are then good to go. But by following the path presented here, you will learn all the basics, including advanced concepts, and become ready for a job after a while.

Without further ado, let's get into it.

(This article was originally posted on my personal blog)

CS50: Introduction to Computer Science

Depending on where you currently stand in terms of your skills, it might be that you first need an introduction to CS overall.

Harvard offers its CS50 for free, and it'll take you a while, but it's worth it. Fundamentals are crucial, especially as many of the advanced concepts you will learn later build on top of them.

freeCodeCamp

JavaScript is the basis of many tools in the Ethereum ecosystem. You should know JavaScript relatively well before you get into Solidity later.

Do at least the JavaScript courses here, including quality assurance. This will also take you quite some time, but knowing JavaScript well also helps you learn Solidity later.

Public Key Cryptography

At the heart of a blockchain lies public key cryptography. You should understand what it is, how it works, and why what you'll do later makes sense.

This video is a great introduction. Go through it a few times if you need to. Don't forget to take a few notes.

Cryptography Digital signatures

With cryptography, you can begin to sign messages and verify identities. Blockchains use it a lot. Without signing messages, there would be no secure transactions.

This article will give you a better idea of how transactions are initiated, for example, and why that is secure.

What is Hashing on the Blockchain?

Hashing is a core concept that blockchains use. And as a smart contract developer, you will probably also use it a lot.

This video is an excellent introduction to hashing and its use in blockchains. Like before, take notes. At some point, you will be thankful for having them ready.

Blockchain Definition: What You Need To Know

Now that you know what cryptography is actually about, it's time to learn more about blockchains in general. The blockchain will be your place of work, so you better know well what you'll work with.

How does Ethereum work, anyway?

Knowing Ethereum is pretty essential, primarily as you work toward being able to code with Ethereum-like blockchains in the future. When you're done with this article, you'll have a general understanding of Ethereum.

This is the last theory material for now. When you are done with this, you'll be able to get into the code again. And this time, it's Solidity you will work with.

The Hitchhiker's Guide to Smart Contracts in Ethereum

Time to finally dip your toes into the waters of Solidity. While already a little older, this guide is a great way to finally implement your first Smart Contract.

Take your time to go through this guide. Solidity is probably new for you, and so it's way better to really digest the learning material until it sticks.

Crypto Zombies

CryptoZombies is a game, but one that teaches you Solidity. In this tutorial, you'll write more advanced logic and get comfortable with the language.

You can also take your time with Crypto Zombies. Do a few lectures here and there, and don't try to rush through it. You'll learn many basic and advanced concepts throughout this course.

Time-locked Wallets: An Introduction to Ethereum Smart Contracts

Time for even more practice. This tutorial walks you through creating a full dApp, including your own ERC 20 token.

Take this course as an opportunity to learn Solidity even more profoundly and apply what you previously learned. Practice is everything, so all chances for you to code in Solidity are valuable.

Ultimate Introduction to Ethereum Ðapp Development

This one is a great video series on dApp development. Concentrate on the Smart Contract videos, and you'll get even more valuable practice with Solidity.

Once again, it's all about applying Solidity. You might begin to notice that you already know a few of the concepts, but don't let this hold you back. The more often you do something, the higher the chance that this knowledge doesn't vanish again.

Ethernaut

Ethernaut is another game that teaches you Solidity. This one primarily focuses a little more on security, a topic that will be very important to you as a smart contract developer.

Security is actually one of the biggest issues in smart contract development these days, and this is why you should pay very close attention to the matter and take many notes. The industry loves developers who know what they are doing, and they will highly value candidates with experience in smart contract security.

ethgas

Every line of code you write has an impact on your users. They pay gas to call functions of your smart contracts. Time to learn about the what, why, and how of gas.

You are back at some theory now, but a pretty important one, to be honest. Understanding the concept of gas and why it is both good and bad helps you to value good code design higher, and it will hopefully trigger different thought processes in you when writing Solidity.

Blockchain Oracles, Explained

You won't be able to do everything on the blockchain. Time to learn about oracles, a way for Smart Contracts to communicate with the outside world.

Oracles are an advanced concept but one that every Solidity developer should understand. Knowing about Oracles is a considerable advantage. Depending on what projects you work on later, you will have more or less contact with them. But as soon as you understand that you already need an Oracle when you want a random number, you will see that learning a lot about them helps you a lot.

Contract ABI Specification

Every smart contract has an ABI. When someone wants to use your contracts, they need to know their ABIs, and you should also know what you actually create there.

After you have already built quite a few contracts by now, it's time to learn what you actually create. ABIs are at the core of blockchain client usage. Without an ABI, no clients would be able to call your contracts on-chain.

Keccak

Keccak is the important hash algorithm for Solidity developers. You'll work with it a lot, so you better know what you are using there.

Hardhat

The time has come to choose the stack you will use from now on.

My recommendation for your development environment: Hardhat.

Go through the documentation and learn more about this Ethereum development environment. You will probably understand by now why you had to learn JavaScript in the beginning. Hardhat is - like many other Solidity tools - implemented in JavaScript.

Waffle

Tests are crucial, especially for Smart Contracts.

My recommendation: Waffle.

Waffle is the engine that drives your tests. It enables you to write JavaScript and test your smart contracts as a client.

ethers.js

Next to Waffle, you will also need a client library to invoke your contracts.

My recommendation: ethers.js.

ethers is the library that slowly completes your stack. You will use ethers in your tests a lot.

OpenZeppelin

Smart contract development is like traditional development, and you should not try to reinvent the wheel every time. OpenZeppelin provides many useful standards already implemented.

See what the library has to offer and learn to use it. Many professional projects use OpenZeppelin a lot, so why shouldn't you later?

Ethereum Improvement Proposals

Ethereum has defined many standards, especially for tokens. Standardized A(B/P)Is are crucial to making the ecosystem work. Go through them all, and learn the most important ones, like ERC20, ERC721, etc.

Solidity Patterns

Now that you can freely build things without a browser, it's time to build and learn important Solidity patterns along the way.

Patterns can be applied in certain places and help you to achieve specific things in a recognizable and maintainable way. You will see many of them regularly when reading code, and you will hopefully also apply them a lot. This is the last thing you should learn really well before you branch out to build your own projects and use your own imagination.

What's Next?

You should be a pretty competent Solidity developer by now. Your skills, however, are still pretty general.

From here on, build a lot of stuff, experiment even more, and see what fields you might like. You can definitely specialize from here on.

Look into:

NFTs
Currencies/fungible tokens
DeFi
DAOs

Learn more about all of them, and see whether you like a field specifically.

Another topic you can now begin to research is decentralized computing. You won't always be able to do everything within your smart contracts (remember learning about Oracles?). Look into Chainlink as a beginning.

After that, you can also try to become comfortable with Functions as a Service in JavaScript and such because sometimes, you will have to write code outside of the blockchain. The more you research, the more interesting platforms and applications you will find.

Before You Leave

Do you like written content like this? If so, you will probably love my newsletter.

Iteration Three is the Web 3 newsletter I would love to get into my inbox each week.

From the latest news in the industry, opportunities, analyses, and development tips, to showcases of interesting new projects, this newsletter tries to give you everything you might have missed or did not even know existed.

Thirteen Incredible GitHub Repositories To Leverage Your Blockchain Learning

Oliver Jumpertz — Sat, 01 Jan 2022 18:44:16 +0000

The internet is a beautiful place of knowledge. You can find educational material nearly everywhere, and GitHub is no different. This article focuses on showcasing thirteen incredible GitHub repositories to you, all packed and filled with learning resources and opportunities to make you better at blockchain development. From Bitcoin to Ethereum, from Python to JavaScript or Solidity, there's something in here for everyone.

(This article is based on a thread I released on Twitter.)

1. Awesome Blockchain Resources

Visit the repository.

This repository contains an awesomely curated list of resources related to blockchain. It contains tutorials, guides, articles, papers, and books. Many of your questions are already answered here.

2. Awesome Blockchain Collection

Visit the repository.

This repository contains a tremendous amount of learning resources. They range from tutorials covering the implementation of your very own blockchain to articles and books. There is something in for everyone.

3. Awesome Blockchain Curated

Visit the repository.

This repository does not contain the classical learning materials as many of the other repositories listed here. Instead, it has many real-life examples of applications working on the blockchain, for you to analyze and get an idea about. Sometimes, the best way to learn something is to see how others do it.

4. Blockchain Learning Path

Visit the repository.

This learning path covers everything, from theory to practice. It guides you from the basics to the advanced concepts and is a great path to follow if you want to cover Bitcoin and Ethereum.

5. Learn Blockchain In 2 Months

Visit the repository.

Learning blockchain in 2 months is a challenging task, but not impossible. This repository does not seem like much, but it covers all the resources you need to complete that task in chronological order. Follow this path, and you will be pretty up-to-date after only two months.

6. Ultimate Solidity, Blockchain, and Smart Contract - Beginner to Expert Full Course | Python Edition

Visit the repository.

The repository to the great freeCodeCamp YouTube course on blockchain with Python. If you don't know that course yet, it covers over 16 hours of in-depth knowledge and everything you need to use Python for smart contract development. It contains a lot of code that helps you to understand what's going on for sure.

7. A simple blockchain implementation in Python

Visit the repository.

Learn to build a blockchain in Python by analyzing this implementation. It is the accompanying repository to another book that contains all explanations you need to understand the whole code. This repository is especially interesting because it shows you that even Python, a language not usually used for blockchain clients, is still a very good choice and gets the job done.

8. Learn Bitcoin From The Command Line

Visit the repository.

A complete guide to interacting with Bitcoin and learning more about it through its CLI. This one is not directly tied to implementing logic, learning about cryptographic primitives, or peer 2 peer networking. Instead, it focuses on you learning to interact with Bitcoin through its CLI client. Using the major blockchain out there also helps you to understand blockchains themselves.

9. Learn How To Build A Blockchain With Go

Visit the repository.

If you ever dreamed of implementing your own blockchain in one of the most popular programming languages for blockchain development out there, this repository might be exactly what you look for. Go is the language most Ethereum clients and nodes and many other blockchains are implemented in. Why not use it to implement your very own?

10. The Bitcoin Book

Visit the repository.

Bitcoin is still the blockchain. It might not be a smart blockchain like Ethereum or Solana, but it definitely is the father of many modern implementations. It is always worth it to learn about Bitcoin, especially as Layer-2 solutions begin to emerge and add capabilities to Bitcoin itself.

11. The DeFi Developer Roadmap

Visit the repository.

DeFi (decentralized finance) was one of the first, and still is one of the most important applications of blockchains. This curated Ethereum developer handbook contains everything you need to become a DeFi developer on Ethereum, sidechains like Polygon, and derived chains like the Binance Smart Chain.

12. Build Your Own X

Visit the repository.

A general-purpose repository containing curated resources for multiple purposes, including Blockchain/Crypto. You get material for JavaScript, Python, Go, and some more languages. All learning materials are of high quality and good to follow.

13. Build A Blockchain With JavaScript

Visit the repository.

JavaScript is a great language, and although it is not one of the major languages used to implement blockchains, it still can. This repository shows you how you can implement one for yourself and even comes with a UI that helps you to explore what happens under the hood better.

Before You Leave

Do you like content like this? Why don't you follow me on social media for a daily dose of education?

Join me on Instagram and get a daily dose of educational content right in your feed, soon also including short educational videos.

10 Important Array Methods In JavaScript Explained

Oliver Jumpertz — Tue, 21 Dec 2021 20:42:56 +0000

I recently read a great article by Marko Denic about array methods. Inspired by this, I thought to myself that it might be a great opportunity to explain them thoroughly and show you what you can use them for, and how you could implement them yourselves.
Without further ado, let's get into it.

1. filter()

filter is the method whenever you want to, well, filter out values. Only want positive values? Only looking for objects that have a certain property? filter is your way to go.

The following is the signature of the filter method:

filter(function (element, index, array) {
  // element is the element within the array
  // index is the index of the element in the array
  // array is a reference to the array filter works on
}, thisOverride);
// thisOverride is a way to override the semantical this within the callback function.
// If you set it to another object, calling this.anyThing would access anyThing within that
// object, and not the actual array.

Example Use Case

Imagine that you have an online shop. And now you want to send a discount code to all customers that live in a certain area.

const getElibigleCustomers(customers, zipCode) {
  return customers.filter(
    (customer) => customer.address.zipCode === zipCode
  );
}

getElibigleCustomers returns all customers that have an address stored with a zipCode, which is the same zipCode you look for. All other customers are filtered out of the array.

Reimplementing filter

If you want to understand filter even better, let's try to reimplement it.

function filter(callbackFn) {
  const newArray = [];

  for (let i = 0; i < this.length; i++) {
    if (callbackFn(this[i], i, this)) {
      newArray.push(this[i]);
    }
  }

  return newArray;
}

Array.prototype.filter = filter;

Attention: Bear in mind that you should never replace a prototype method of a built-in type yourself. But this is just to show you how a possible implementation might look.

As you see, filter is nothing else than a loop that executes a callback function for each element. All elements the callback function returns false for, are filtered out.

2. forEach()

forEach is a functional way to loop over array elements and execute some logic for each element. The method itself doesn't return a new array.

The following is the signature of the forEach method:

forEach(function (element, index, array) {
  // element is the element within the array
  // index is the index of the element in the array
  // array is a reference to the array forEach works on
}, thisOverride);
// thisOverride is a way to override the semantical this within the callback function.
// If you set it to another object, calling this.anyThing would access anyThing within that
// object, and not the actual array.

Example Use Case

Let's stay with the example of the online shop. Now, you want to print all names of the customers you previously filtered out.

getElibigleCustomers(customers, '123456')
  .forEach(
    (customer) => console.log(`${customer.forename} ${customer.surname}`)
  );

When forEach executes, the console prints the full name of all customers that were previously filtered out.

Reimplementing forEach

Let's reimplement forEach so you better understand how it works.

function forEach(callbackFn) {
  for (let i = 0; i < this.length; i++) {
    callbackFn(this[i], i, this);
  }
}

Array.prototype.forEach = forEach;

Once again, bear in mind that you should never replace prototype methods of built-in types in a real app, except you really know what you are doing.

You probably begin to notice a pattern by now. forEach is, once again, nothing else than a loop. And within this loop, the callback function is called. The result isn't interesting and thus thrown away.

3. some()

some is a special array method. It tests whether at least one element within the array tests positive for a specific condition. If so, some returns true, otherwise, it returns false.

The following is the signature of the some method:

some(function (element, index, array) {
  // element is the element within the array
  // index is the index of the element in the array
  // array is a reference to the array some works on
}, thisOverride);
// thisOverride is a way to override the semantical this within the callback function.
// If you set it to another object, calling this.anyThing would access anyThing within that
// object, and not the actual array.

Example Use Case

Back to our online shop example. Imagine that you now want to test whether at least some of the customers you filtered out are underage. If so, you want to show them another deal, because everyone else gets a discount for alcoholic drinks. But you don't want to support underage children drinking, of course.

const eligibleCustomers = getElibigleCustomers(customers, '123456')

const containsUnderAgedCustomers = eligibleCustomers.some(
  (customer) => customer.age < 18
);

When some executes, it checks each customer's age property. If at least one is below 18, it returns false.

Reimplementing some

Time to reimplement some.

function some(callbackFn) {
  for (let i = 0; i < this.length; i++) {
    if (callbackFn(this[i], i, this)) {
      return true;
    }
  }
  return false;
}

Array.prototype.some = some;

some loops through all elements of the array until it finds an element where the callback function returns true for. In this case, the method returns early, because for some elements to satisfy a condition, one is already enough. Only when no element matches, false is returned.

4. every()

every is the counterpart of some. It tests whether all elements satisfy a condition. Only then, the method returns true. If only one element fails the test, false is returned.

The following is the signature of the every method:

every(function (element, index, array) {
  // element is the element within the array
  // index is the index of the element in the array
  // array is a reference to the array every works on
}, thisOverride);
// thisOverride is a way to override the semantical this within the callback function.
// If you set it to another object, calling this.anyThing would access anyThing within that
// object, and not the actual array.

Example Use Case

Many customers who received your discount code have ordered by now. To save on shipment costs, you want to send it out all at once. But first, you need to check whether all those customers have valid address data saved.

const customersWhoOrdered = getCustomersForOrder('discount1234');

const allCustomersHaveValidShipmentData = customersWhoOrdered
  .every(
    (customer) => hasValidShipmentData(customer)
  );

When every executes, it passes each customer to a function that checks whether that customer has valid shipment data stored. If only one customer has invalid data, the whole function returns false.

Reimplementing every

Time to reimplement every.

function every(callbackFn) {
  for (let i = 0; i < this.length; i++) {
    if (!callbackFn(this[i], i, this)) {
      return false;
    }
  }
  return true;
}

Array.prototype.every = every;

every loops through all elements of the array until it finds an element where the callback function returns false for. In this case, the method returns early, because not all elements satisfy the condition. One is already enough. Only when no element matches, true is returned.

You might even have noticed that every is not very different from some. At some specific points, true is replaced with false, and the check with the callback function is negated. These small changes are already enough to make the method do exactly what you want.

5. includes()

includes is a method that checks whether an array contains a specific element. It's good for a quick check, but it also has its drawbacks, which we talk about in a minute.

The following is the signature of the includes method:

includes(function (searchElement, fromIndex) {
  // searchElement is the element you look for
  // fromIndex is the index the search should start at
});

Example Use Case

includes is special. It actually tests for strict equality, which means: It either searches for a value that is strictly equal to the search element, or it looks for the exact reference of an object.

Let's say you want to check whether the customers orders include a very specific order, like this:

const allOrders = getAllOrders();

const containsSpecificOrder = allOrders.includes({
  customer: 'John Doe'
  zipCode: '54321'
});

You would probably be surprised to find out that include returns false, even if the array contains an object with the exact same properties. This is because it looks for strict equality, and objects are only strictly equal if they are the same reference. JavaScript does not know an equals method.

This reduces includes' use cases to primitive values. If you, for example want to check whether an array of numbers contains a specific number like this:

const numbers = [1, 2, 3, 4, 5];

const includesFive = numbers.includes(5);

Here is a rule of thumb: If you deal with an array of primitive values, use includes. If you deal with objects, use some because it allows you to pass in a callback with which you can test objects for equality.

Reimplementing includes

Time to reimplement includes.

function includes(searchElement, fromIndex = 0) {
  if (fromIndex > this.length || fromIndex < 0) {
    return false;
  }

  for (let i = fromIndex; i < this.length; i++) {
    if (this[i] === searchElement) {
      return true;
    }
  }

  return false;
}

Array.prototype.includes = includes;

The guard statements at the beginning are there to make the method execution a little safer. A negative fromIndex makes no sense, as well as an index larger than the array's max index. The rest is just a loop testing each element for strict equality with the element searched for.

6. map()

map is one of the most important array methods out there. Whenever you want to transform all values within an array, map is the way to go.

The following is the signature of the map method:

map(function (element, index, array) {
  // element is the element within the array
  // index is the index of the element in the array
  // array is a reference to the array map works on
}, thisOverride);
// thisOverride is a way to override the semantical this within the callback function.
// If you set it to another object, calling this.anyThing would access anyThing within that
// object, and not the actual array.

Example Use Case

Let's jump back to the point where you had all eligible customers filtered. Now, you want to send their orders off and need to get all their addresses. This is a great use case for map:

const eligibleCustomers = getElibigleCustomers(customers, '123456');

const addresses = eligibleCustomers
  .map((customer) => customer.address);

map iterates over all customers and then extracts all addresses. These are put into a new array and returned from the function.

Reimplementing map

Time to reimplement map.

function map(callbackFn) {
  const newArray = [];
  for (let i = 0; i < this.length; i++) {
    const mappedValue = callbackFn(this[i], i, this);
    newArray.push(mappedValue);
  }
  return newArray;
}

Array.prototype.map = map;

map iterates over all elements of the array. For each element, it calls the callback function and expects a new value to be returned. This value is then pushed to a new array. That array is returned in full, resulting in an array of the same size as the original one, but with probably different elements in it.

7. reduce()

reduce is the most powerful array method existing. It can be used to reimplement all existing array methods, and it's the most flexible one. Talking about all the advantages it offers would definitely need an article on its own, but you will get a glimpse of it soon.

The following is the signature of the reduce method:

reduce(function (accumulator, currentValue, currentIndex, array) {
  // accumulator is the result of the last call, or the initialValue in the beginning
  // currentValue is the value currently processed
  // currentIndex is the index of the current value within the array
  // array is a reference to the array reduce works on
}, initialValue);

Example Use Case

Remember when you wanted to find out whether there were underage customers? Another way to deal with this problem is to group all your eligible customers into two groups. Those of legal age, and those who are underage.

const eligibleCustomers = getElibigleCustomers(customers, '123456');

const customerGroups = eligibleCustomers
  .reduce((accumulator, customer) => {
    if (customer.age > 18) {
      accumulator[0].push(customer);
    } else {
      accumulator[1].push(customer);
    }
    return accumulator;
  }, [[], []]);

reduce can be pretty difficult to understand but we can go over the above code together and see what it does. In this case, the accumulator is a 2-dimensional array. Index 0 contains all customers >= 18 years of age. Index 1 contains all customers who are underage. The first time reduce runs, it sets accumulator to the empty 2-dimensional array. Within the method, the code checks whether the age property of the customer is above 18. If so, it pushes the customer to the first array. If the customer is underaged, they get pushed to the second array. In the end, the 2-dimensional array with the grouped customers is returned.

Reimplementing reduce

Time to reimplement reduce.

function reduce(callbackFn, initialValue) {
  let accumulator = initialValue ?? this[0];
  for (let i = 0; i < this.length; i++) {
    accumulator = callbackFn(accumulator, this[i], i, this);
  }
  return accumulator;
}

Array.prototype.reduce = reduce;

reduce iterates over all elements as all the other array methods do. In the beginning, the method needs to decide whether an initialValue was supplied. If not, the first element from the array is taken as such. After that, the accumulator is replaced with the result of calling the callback each time, and then returned in its final form in the end.

8. sort()

The name of sort already says it all. Whenever you want to sort an array, this is the method you need to call.

The following is the signature of the sort method:

sort(function (firstElement, secondElement) {
  // firstElement is the first element to compare
  // secondElement is the second element to compare
});

Example Use Case

Whenever you need to sort something, you found a use case for sort. Let's, for example, try to sort your customers by age. For such a case, sort allows you to pass in a comparator function that you can use to tell sort how to properly order them.

const customers = getCustomers();

customers.sort((a, b) => customer.a - customer.b);

The callback function must return a number based on the order of the elements. It should return a value < 0 if a comes before b, 0 if both are equal, and a value > 0 if a comes after b.

Reimplementing sort

Reimplementing sort is a little difficult because, under the hood, runtimes are allowed to implement any sorting algorithm they seem fitting. There are only a few requirements, like that the algorithm must be stable. Usually, runtimes implement at least QuickSort, though, and sometimes change the implementation based on the elements within the array.

function partition(array, left, right, compareFunction) {
  let pivot = array[Math.floor((right + left) / 2)];
  let i = left;
  let j = right;
    while (i <= j) {
        while (compareFunction(array[i], pivot) < 0) {
            i++;
        }
        while (compareFunction(array[j], pivot) > 0) {
            j--;
        }
        if (i <= j) {
            [array[i], array[j]] = [array[j], array[i]]
            i++;
            j--;
        }
    }
    return i;
}

function quickSort(array, left, right, compareFunction) {
  let index;
  if (array.length > 1) {
      index = partition(array, left, right, compareFunction);
      if (left < index - 1) {
          quickSort(array, left, index - 1, compareFunction);
      }
      if (index < right) {
          quickSort(array, index, right, compareFunction);
      }
  }
  return array;
}

function sort(compareFunction) {
  return quickSort(this, 0, this.length - 1, compareFunction);
}

Array.prototype.sort = sort;

This is only an exemplary implementation of sort, in this case, QuickSort. But it should give you a general idea.

9. find()

find is your search function. Whenever you look for something within an array, you can use find to retrieve the first element from the array that satisfies your conditions.

The following is the signature of the find method:

find(function (element, index, array) {
  // element is the current element
  // index is the current index
  // array is a reference to the array find works on
}, thisOverride);
// thisOverride is a way to override the semantical this within the callback function.
// If you set it to another object, calling this.anyThing would access anyThing within that
// object, and not the actual array.

Example Use Case

Imagine you try to find a customer with a specific name within all your customers.

const customers = getCustomers();

const customerJohn = customers.find(
  (customer) => customer.forename === 'John'
);

In this case find returnS the first user within the array that has the forename John. The important part is that find won't return all customers with that name.

Reimplementing find

Time to reimplement find.

function find(callbackFn) {
  for (let i = 0; i < this.length; i++) {
    if (callbackFn(this[i], i, this)) {
      return this[i];
    }
  }
  return undefined;
}

Array.prototype.find = find;

find iterates over all elements as all the other array methods do. For every element, it checks whether the callback function returns true. If it does, it returns the element at that position. If it doesn't return early, it returns undefined at the end.

10. findIndex()

findIndex is a method that you can use to get the index of an element within the array. Like find, it stops at the first element that satisfies the condition. It will thus only ever return the index of the first element satisfying the test.

The following is the signature of the findIndex method:

findIndex(function (element, index, array) {
  // element is the current element
  // index is the current index
  // array is a reference to the array find works on
}, thisOverride);
// thisOverride is a way to override the semantical this within the callback function.
// If you set it to another object, calling this.anyThing would access anyThing within that
// object, and not the actual array.

Example Use Case

Imagine you have all your customers sorted by age, and now you want to find the first customer with a forename of John.

const customers = getCustomers();
const customersSortedByAge = sortByAge(customers);

const indexOfJohn customersSortedByAge.findIndex((customer) => customer.forename === 'John');
const customerJohn = customersSortedByAge[indexOfJohn];

In this case findIndex returns the index of the first user within the array that has the forename John. The important part is that findIndex won't return all indices of customers with that name.

Reimplementing findIndex

Time to reimplement findIndex.

function findIndex(callbackFn) {
  for (let i = 0; i < this.length; i++) {
    if (callbackFn(this[i], i, this)) {
      return i;
    }
  }
  return -1;
}

Array.prototype.findIndex = findIndex;

findIndex iterates over all elements as all the other array methods do. You should notice the similarity to find. Instead of returning the element, only the index is returned when an element is found. Instead of undefined, if nothing is found, -1 is returned.

That's It

You have now learned a little more about 10 of the more popular and important array methods in JavaScript. As you've learned, many of them are pretty similar, and they all have in common that they loop a lot. Other than that, they all have their similarities and differences, but this is what makes them so interesting to explore and learn.

Before You Leave

Do you like content like this? Why don't you follow me on social media for a daily dose of education?

Join me on Instagram and get a daily dose of educational content right in your feed, soon also including short educational videos.

Why talking about your current salary with recruiters and in interviews is a horrible idea

Oliver Jumpertz — Mon, 23 Aug 2021 13:52:59 +0000

Interviews are never easy. We often feel like beggars hoping to get a well-paid job. Although this is actually not the reality, especially for tech workers, interviews stress our nerves, make us sweat, and we usually don't feel well doing them. We are constantly graded and evaluated, classified, and then deemed worthy or not. Interviews are full of questions we have all already heard of. There are classics, clever questions, riddles, whiteboarding, and what else.

One of those classics that's asked more and more, especially by recruiters, is the following one:

"What is your current salary?"

This is one of the most critical and morally questionable questions to ask a candidate, and here is how you deal with it.

Determining the value of work

Before we talk about the question and how to handle it, we need to talk about how the value of work is determined. With this knowledge, you will understand the catch of this question and why answering honestly puts you at a disadvantage. To completely cover a topic as deep as how to value work, it would definitely need a whole article or even a book on its own. We will thus go with a pretty simplified version that gives you at least a basic idea of how it works.

The value of work is individual.

It is partly based on:

Supply
Demand

in the global, but even more in the local markets.

Chances are high that no two employees doing the same job, even at the same company, are paid the same. Companies earn different amounts of money each month and year. They have different operating costs, and they have different leadership. All businesses, however, have in common that they try to minimize costs while maximizing profits, at least up to a certain extend.

When a company starts to hire, it creates a budget. This is basically what they are willing to pay a new employee for a certain job. This amount is based on experience, supply and demand in the local markets, and more factors. Beginning with a certain salary, there will be interest in a position. Going below and no one will want to work for this company, going too high, and the company gives away too much money they could have spent on other things. This means that a company tries to find a sweet spot to get enough candidates to choose a suitable one from. It only needs one suitable candidate to fill a position—multiple ones to fill multiple positions.

Multiple hires probably won't earn the same. Although a company has a salary range in mind, they will still try to negotiate your pay based on the outcome of the interview, your previous experience, and what you have in mind. If you ask for less than what they had in mind, that's awesome for them.

Why this question is a trick

As you learned, a company that wants to interview you usually has a certain salary or better range in mind. Often, they don't state this range publicly because it would weaken their position for negotiations. And this is where this tricky question comes in. If you currently earn $100k a year, why should they suddenly pay you $150k for a similar job? Stating what you currently earn weakens your own position for all future negotiations. Often, recruiters try to sell you this question because they "need to see whether you fit in the company's salary expectations," but this is largely a stupid excuse. They could easily have asked for your salary expectations then. For a company, it's easy to say that a 50% raise is "too much" and that they "can't see anything that justifies this jump in pay." Suddenly, they have a point to focus on. It doesn't even matter anymore that you are currently underpaid for all the work you do. Even a 20% raise would already be a huge win for you, wouldn't it? No. It wouldn't.

The value of work is subjective and depends on the individual company. The same work you do at company A can bring this company fewer or higher profits than company B. It's not all about you. It's also about their marketing and sales teams, the size of their customer base, their customer's will to pay a certain amount, etc. If company B can sell your work for more than company A, the first one can easily afford to pay you more, even for the same work. It's as easy as that. You deserve a slice of the cake. This is what you show up for every day.

Dealing with this question

If an honest answer isn't a great option, what then? Circumvent it and state your salary expectations instead. No matter what a recruiter or an interviewer says, don't state your current salary and don't lie about it. Really, please don't lie about it. If you ever happen to tell someone what your previous salary was, and this information finds its way to your manager or HR, there is a slight chance that you won't have an easy time negotiating for a raise in the foreseeable future.

You both (the company and you) want to find a base for further negotiations. If your expectations don't align with the company's, this specific job isn't for you. You might have to look for another job then, but that's still better than underselling yourself in the end. In my experience, everyone who ever honestly gave their current salary away had a way harder time negotiating for a fair salary afterward. This is why you should politely decline to answer this question and offer your salary expectation instead.

A good example of an answer

"I am sorry, but I think that my current salary is not of interest here. I understand that you need a number to figure out whether our expectations align, though. I can tell you that I currently look for positions that pay in the range of around $140k to $170k. I am sure that we can narrow this down further as soon as we have talked deeper about what your expectations for me are and when I could show you what I am capable of. I believe that you will see that I am well worth this money, and I can promise you not to disappoint during our coming interview rounds. Is this range something you can live with? Do both our expectations align here?"

This is a great example of an answer. It politely declines to talk about your current salary and instead states your own expectations. But it still shows that you respect the company's need to determine whether they are willing to pay enough. It provides a range and not only a single number. This shows them you are willing to negotiate, based on how well you both align. What they expect of you might be different from what your current employer expects. After this, the answer shows that you are self-confident enough to promise to deliver in the interviews. The next important point is that this answer shows confidence that you are worth the money you ask for. It awakens the assumption that you thought about your salary expectations well enough to build this confidence. And lastly, the answer gives an exit. If the company can't live with this amount of money, they are free to decline at this point.

One counter-question, just in case

If you doubt that you can decline to answer this question, or if a recruiter or company should ever insist on you telling them your current salary, here is what I have done in the past and would recommend you to do.

Ask them how much they charge one of their large customers on a custom plan. They will most likely decline to answer this question because this is company-internal information. Next, ask them whether they would give this information to another customer if they asked. I can already tell you they would never do that. Custom plans are always negotiated. Why should a company give any customer at least a hint that they might try to charge them more than other customers? Correct. They should and would never. Your current salary is the last customer, and now they want you to give them a hint they would never, themselves, give one of their own customers. This counter-question should make clear that you don't take the bait.

Before You Leave

If you would love to read even more content like this, feel free to visit me on Twitter or LinkedIn.

I'd love to count you as my ever-growing group of awesome friends!

Exposing your greatest weakness in an interview

Oliver Jumpertz — Thu, 05 Aug 2021 14:57:37 +0000

"What's your greatest weakness?"

Have you ever been asked this question in an interview and were like, "Yea, uhm, well...I sometimes want to achieve too much?"

This question is tricky, but here is how you can crush it.

Foreword

I've interviewed quite a few times in the last few years, and I also had the honor to interview a few outstanding software engineers. I witnessed this question many times, although I never asked it myself. My job as a tech lead is to assess the technical quality of candidates and see how much they fit into my team. I like to use other techniques to do this, but I still understand why HR managers love to ask questions like this one.

Why this question is important

Self-awareness is important for everyone.

It's valuable to know what your

Strengths
And weaknesses

are and what you

Like
And dislike.

Knowing your own weaknesses is especially crucial.

It gives you the ability to know:

Where you could improve
Which tasks you might struggle with
When it is better to ask for help
Which situations you might not want to find yourself in

Self-aware employees can ask for education, certification, and help to improve their weaknesses themselves. They usually also know what tasks they can ask for help with right from the beginning. Additionally, they know about social situations they might not like.

Employees who are self-reflective enough to know their weaknesses are valuable for a company. Even an introvert can be a great team member, especially if they are committed to improving to get along in their team well.

Lastly, honesty is shown through this answer. Answering with an honest weakness exposes the candidate to the interviewer. But the candidate shows that they can be honest even if something isn't in their own favor.

How to deal with this question

If you aren't already self-reflecting regularly, prepare yourself to put in some work before your interview. Assess yourself and honestly ask yourself what your weaknesses are. Write them all down and sort them.

Here are some essential rules for the weaknesses, their order, and a description:

Choose a weakness that wouldn't cost you the job
Be honest, only real weaknesses. Don't just make something up
Add an example of how you worked to improve this weakness
Show that you can take the help of others to overcome a weakness
Neither be arrogant nor underestimate or short-sell yourself

Take your time, and don't rush this step. You can reuse this work in the future for other interviews. Follow the rules above closely. You want to crush this question and not only give a probably satisfying answer. This is why only saying something like, "I tend to become impatient after a while," is not enough.

The first spot on the list should be taken by:

An honest answer
One that still favors you and doesn't shed light too negative on you
A weakness you can tell a story about
What it affects
How you overcame it
What you did and still do to improve on it

An example of a good answer

"I tend to focus too much on details. A few times in the past, I put more work into some features I developed than would have been needed to create a good solution. This lead to me not having enough time to help my teammates out. I had a few talks with my managers about this, and I realized that software doesn't always have to be perfect. It only needs to do what it is supposed to do.

Since realizing this, I put more thought into my features and create code reviews earlier to ask for feedback. This allows me to discuss my approach with my teammates and them the chance to evaluate my approach and inform me when we reached a point where my code is good enough.

I still struggle with my detail orientation from time to time. But I actively work on improving on this, while early code reviews give me a good opportunity to learn from the experience of my peers.

I'd love to get some help with this, and if you, as an employer, offer training on this, I'd be happy to take it."

This example answer checks all marks.

If this is really something that happened to you, no interviewer can ask for more.

You exposed yourself, and it's their turn to assess whether they believe you and are okay with it.

Some common weaknesses

Here are a few examples of common weaknesses you might also suffer from:

You have a problem with patience
You struggle organizing your work
You don't like to delegate tasks
You might be timid
You don't like public speaking
You perhaps struggle with data analysis
You need to improve your software testing skills
You like to rush things
You can't deal well with stubborn people
You don't like letting go of a project
You have trouble saying no

Decide for yourself whether you suffer from one of these examples. If so, pick the one that is really your greatest weakness.

If yours is not included here, you will have to dig deeper and honestly ask yourself what the issue is that you suffer the most from. It may take some time, and perhaps you don't even find the correct one, but it will still be an honest one because you came up with it.

Before You Leave

If you would love to read even more content like this, feel free to visit me on Twitter or LinkedIn.

I'd love to count you as my ever-growing group of awesome friends!

That one obvious interview question that can cost you some nerves

Oliver Jumpertz — Tue, 03 Aug 2021 16:25:24 +0000

"Why do you want to work here?"

-> Your interviewer

"Well, I am a web developer, and you are looking for one. Additionally, I need the money."

-> You

Some interview questions are stupid. But giving answers like the one above doesn't help.

Let's see how to tackle this one effectively.

Foreword

I don't particularly like this question, and I love companies that simply throw such questions into the bin. But, there are still companies out there asking questions like this one. And this is why you should be prepared for it and the reason I share this with you.

Why this question is important

Like any other general question that is asked relatively often, this one is also aimed at giving your potential new employer some key information about you. It aims at providing the following information:

What is your motivation to work exactly at this company?
Are you really motivated to do the job?
Are you genuinely interested in contributing to the company?
Will you be a good investment for them?

You need to put yourself in the shoes of an employer. Every hire is an investment for them.

They provide

Guidance
Mentors
Education
And a budget so you can evolve.

And they want you to make money for them.

This is how a business works. Only motivated employees do their best to contribute to the goals of a company. They are the ones that put in their thoughts and work into reaching company goals. Unmotivated employees will do their work, but they won't give a hundred percent. Unmotivated employees are also more likely to leave the company again after a short while. This turnover is costly for any company, and it is also costly for the employees who leave. They have to go through the whole interview process once again, as well.

Not all companies are faceless and only business-focused entities. Some of them really have a huge interest in your well-being. If they only hire you because you need the job, they don't do you a favor, either. If getting up to go to work each day becomes so hard for you because you don't like the job, you might even end up with depression.

You should be happy with what you do. If you happen to get to this point, you found a good job. This is why this question is often asked at the beginning of your interview, where it sets the stone for it, or at the end of your interview when you learned more about the role, to check your interest and enthusiasm for it.

How to deal with this question

Good preparation is everything. Never come to an interview unprepared. It usually only backfires. It is in your best interest to get to know the company, what it stands for, and what its mission is as good as possible.

You make a commitment by signing their offer. This usually means showing up there every day (in-office or remote) and doing your work. You will inevitably contribute to the company's success. You should thus already be aware of what you expect from the company, and be sure that the role they offer and what they do is really for you.

Take notes and do your best to write down:

What the company does
What it stands for
What mission it has

With this information at hand, you can take a look at your own expectations:

What work makes you happy?
What do you want to achieve?
What do you want to contribute?
What culture do you need to thrive?
How do you want to help the company succeed?

If you can answer each of these questions honestly, you are actually already set up pretty well.

There is no need to make up the perfect answer somehow. Although it might seem tempting to make it up, so you get the job, it will only hurt you. Craft a story to tell your interviewers why you want to work at this exact company. This is everything you really need to answer this question because there is no right or wrong.

An example

"This is a great question because I also asked myself why I should join your company when I read about you and your job offer. I think that our values align pretty well. You are doing an awesome job of making the cloud easier for everyone. And this is exactly what I also try to do as a content creator and open source contributor in my free time. Your vision of making the cloud as easily usable as any web application is what I am dreaming of for quite some time now. This job is the perfect opportunity for me to contribute to this great goal and use my expertise in this field to help you succeed with this mission."

Another example

"I think my current skillset perfectly aligns with what you search for. I always wanted to get into product development, and your company seems to be the perfect fit for me. I like how you managed to build a SaaS product so many people love to use. And as I am a user myself, I would love to contribute to its further development with my previous expertise. I have found no other company that aligns with my goals as perfectly as yours. This is why I had to apply for this position."

There is really nothing special with the two example answers above. It's just important to be honest, to only state what really is true, and to really believe in what you say there.

If you manage this, you've already delivered on this question.

Before You Leave

If you would love to read even more content like this, feel free to visit me on Twitter or LinkedIn.

I'd love to count you as my ever-growing group of awesome friends!

How to react when asked to rate your skills in an interview

Oliver Jumpertz — Sun, 01 Aug 2021 09:58:37 +0000

"How would you rate your JavaScript (or XY) skills on a scale of 1-10?"

This one is another tricky question that can cost candidates in job interviews some nerves. Let's face it, most of us find it dumb. But you can turn this question into a massive win for you.

Why is this question asked?

You could go ahead and call it dumb now, but there is more to it than only the sheer will to bring candidates to sweat during interviews. But it serves a purpose. Such a question might not be the best question or even way to get this kind of information, but it exists, and from time to time, you will have to face it. And if you want this job, you need to deal with it.

You somehow have to tackle it and deliver a satisfying answer. And the actual idea of this kind of question is to test your self-awareness.

It tests how:

You perceive yourself
Well you rate yourself
Good you are at self-reflection
Much thought you put into yourself and your answer
You react to such a question

Being a professional means applying a certain skill set regularly. A software developer usually develops a lot of software (surprise!).

This includes:

Thinking about
Designing
Prototyping
Testing

solutions, for example.

And it also includes coding.

A common expectation, especially from employers, is that employees get better over time. They invest in their employees by educating them further, giving them responsibility, and letting them roam free from time to time. And this leads to them expecting a certain ambition of you to progress further and get better in your craft. But for you to get better, you need to be aware of where you are currently at. And this requires regular self-reflection. If you know where you are currently, you can plot a path to your goal. You will also, most likely, be able to assume whether you can solve a certain problem and when you need help. If you take too long to think about this question and then respond with a generic answer, it can indicate that you haven't spent much time on self-reflection recently.

Even further, only a number is usually not the expected answer. You should give a reason as to why you answer with a specific number. "Oh, an 8" is an answer, but it doesn't tell why you have actually come to this conclusion. Interviewers really expect reasons. Don't underestimate this. They will judge you based on the answer and reasons you give. There is not even a right answer to this question because usually, no one will try to assess whether an 8 or 9 is justified. It's all about how you deliver it.

How to prepare for this question

As you've previously read, it's all about how you deliver the answer. This requires some preparation on your side, like many other questions and interviews in general do. Take an hour or less while you prepare for your interview and rate yourself honestly. Do this based on the skill requirements of the job ad, at least. Create a table and rate how good are you at:

JavaScript
Rect/Vue/Angular/Svelte
API Design
Layouting
etc.

This table should contain:

The skill
Your rating
A reason why this rating is justified and how you improved in it recently

Bonus points for you if you try to imagine what else, besides each hard skill listed, might be interesting for this position.

This prepares you at least for such questions that aim at anything possibly previously known. A neat side effect is that you actually work on improving your self-reflection skills. It might well happen that you get asked to rate yourself in something that has nearly nothing to do with the position you interview for. I personally hate when interviewers do this, but it happens. In this case, you will still be prepared to come up with an answer before it is too late. Also learn to say your thoughts aloud, so interviewers don't need to watch you silently thinking about a satisfying answer. This can give bonus points.

How to deal with this question in an interview

If this question comes up, you will most likely be prepared for it. You will have self-reflected during your preparation and can honestly state your number and argument for why it is justified. Go ahead and deliver your answer. Show your interviewers that you are prepared for this kind of question and that you won't let such a tricky one fool you. You have self-reflected, and it's your right to show that you did.

Let's now look at an example answer.

An example

"I think I'd give myself an 8. Due to the extensive work I did in my last projects where I worked as a Senior Developer, I could improve my skills a lot. I was especially able to work more with Promises, and async/await and understand this topic better. But I still think that even to get close to a 10, I will definitely need more exposure to lesser used language features like asynchronous generators and generators in general."

This is an answer that contains everything an interviewer could ask for.

You:

Rate yourself
Give reasons for it
Show you are aware you improved and
also know that you still lack in some areas

And that's it then? Well, yes and no. You can answer this question and finish your interview, but there is also a way to really crush it, which comes next.

How to crush this question

Let's face it. Using numbers to rate yourself properly is nearly impossible. Let's take JavaScript, for example. What actually is a 10? I once learned the full ECMA spec, and I wouldn't give myself a 10. Even Brendan Eich said that he wouldn't call himself an expert in JavaScript anymore because he didn't put much work into catching up with the language's evolution. He stated he could, but he currently does other things.

So, what then if numbers are a terrible indicator? If the question mostly exists to assess your self-awareness, why not think outside the box and give another answer that still satisfies your interviewer's expectations? Throw any numbers away and better state that you know relatively well where you stand.

Let's say you previously worked as a frontend developer and also interview for another frontend developer role. Don't you think a lot of your experience is transferable? As long as you build SPAs, they will most likely consist of the same building parts no matter where you work. And as long as you are aware of what else a certain language or framework has to offer, you have an easier time stating what you haven't really worked with yet. The actual strategy now is to show that you know what you worked with and are aware of what you haven't worked with excessively or at all yet.

Let's take a look at an example next to show you what crushing this question is about.

An example

"Thank you for this question. I would really like to give you an honest, self-reflective rating of my skills, but I think that numbers are a terrible indicator of skill level. You can ask three nearly identical developers how they rate themselves in the same skill, and you will get three very different answers.

I think it is better to tell you where I have a lot of experience and where I believe I still need to improve. In the last few years, I worked the majority of my time on creating base components. This gave me extensive knowledge of functional React components and enabled me to get deep insights into React's rendering loop.

Due to the nature of these base components and a user base of around 500 company-internal frontend engineers, I also tackled many accessibility issues and gained a deeper understanding of the field. But I have to admit that I couldn't work much with remote calls and the fetch API. I would even go so far as to say that I definitely need to improve my frontend data skills. This also holds true for server-side React. I wasn't able to work much with Next, for example.

I do, however, highly believe that if you give me the chance and time to catch up, I will be able to do so relatively quickly while setting myself up to become a great contributor in my future team."

This answer should usually tell your interviewer much more than a common answer with a number and some reasons. It additionally shows that you are aware that certain "rating systems" are bad and that you still know how to show what you know and don't. You reflected deeply about your past and are even aware of what you might need in your future position. No interviewer can ask for more. If they do, you can still stand up and go. This company isn't worth it then.

Before You Leave

If you would love to read even more content like this, feel free to visit me on Twitter or LinkedIn.

I'd love to count you as my ever-growing group of awesome friends!

How to tackle the dreaded question "Why should we hire you?" in your next interview

Oliver Jumpertz — Fri, 30 Jul 2021 08:39:37 +0000

"Why should we hire you?"

This is another of those questions everyone interviewing hates. It spread from traditional jobs into the tech world, and even software developers have to deal with it.

But you can turn this into a huge win, and this article shows you how.

Why is this question asked?

Like any of those pretty cliché questions regularly asked in interviews, interviewers try to determine whether you are a good fit. Your hard skills might have been assessed already or will be soon, but this one is about your character.

Even before the term EQ (emotional intelligence) became popular, there was more to employees than only the skills they brought with them. People are human. They have a character. And they need to get along with other people.

What interviewers try to assess here is how good you can sell yourself. And even more, they want to find out HOW you sell yourself. Interestingly, it can tell you a lot about someone else when you listen to how they talk about themselves. Is the candidate super arrogant? Are they introverts? Don't they find the words to describe themselves? Do they only speak in superlatives? Yea, you are somehow being profiled when you are asked to answer this question.

With the answers you give, experienced HR managers can create a rough profile of you. They see whether you fit into the company culturally and how well you would fit into certain teams. It also tells a lot about how interested in the company itself you actually are. If you only talk about how awesome you are but never even mention how awesome your work would be for the company and how much you would like to contribute, you make a bad impression.

How to deal with this question

If you want to make the most out of this question, you should do these two things:

Prepare yourself before the interview
Listen to the interview(s) closely, up to the point this question is asked

Prepare yourself before the interview

Your goal is most likely to get this job or see whether it is really something for you. No matter what your motivation is, prepare yourself as if you really wanted to get this job. If you find out that you actually want this job during the interview, you might be unprepared for a question like this and thus not come up with a great answer. No one likes missed chances. Especially not if they could have been avoided.

What you should do:

Write down what you really look for in a job
Double-check the job ad and see how good of a fit you are
Check the company's background: What do they do? What do they tell about themselves?
Look for company reviews on the internet, both from customers and employees
Use a table or another form of notation to compare who you are with what the company is
Craft an honest story that references the most important points where you and the company match

This might seem much now, but let's go over it:

You should first make clear for yourself what you are really looking for.

What would make you go to work every day?
What would keep you motivated?
What does a job have to offer you, so you are happy?

Then see what the company states it is looking for. This is usually the job ad. Keep in mind that those are never perfect and should not be taken as the whole truth. But they are a good indicator.

Next, look up what the company really stands for.

How do they represent themselves?
What image do they present, and what do they do for society?
What are their values?

You want to make sure that your values align with theirs. Marketing is one thing, but the truth usually lies deeper. A company can write anything they want on their website and in press releases. But what do customers and employees say when they review the company? Is there more you can learn about them?

The next step is a little more difficult. You should somehow try to find out how well the company and you align. Do you match their criteria, and do they match yours? A table, like a pro/contra list, can help. But perhaps there is something that works better for you. Just make sure you have something written somewhere, black on white, so you don't try to cheat yourself.

With all this information at hand, you can craft a story about why exactly YOU are a good fit for the company and why they should hire exactly YOU. This story should answer: What do you bring to the table that helps them, and what can they do for you? Feel free to write multiple sentences already. This helps you learn the core of it up to the point that you could also answer this question freely during the interview. If bullet points serve you better, that's also fine.

Listen to the interview(s) closely, up to the point this question is asked

Interviews usually bring up a lot of additional information you didn't know about previously. Perhaps you couldn't find it online, or it simply wasn't there. I can only recommend you take notes during an interview. This way, you have all this information at hand when you need it. Perhaps the interviewer tells you about an employee education program that they didn't list on their website. Or perhaps they tell you about their engagement in local communities, or even better, a new field they want to get their feet wet in.

If something is interesting for you in it, definitely use it to your advantage. As soon as the question of why they should hire you comes up, you can use exactly this as one of the reasons they should hire you. You can sell them your honest interest in a certain topic as a reason to hire you. Why? Because it shows your ambition.

An example

"I can give you several reasons why you should hire me. First of all, I tick many boxes regarding hard skills as I have some extended experience. For the rest, I can assure you that I will quickly catch up with these. I've already shown that I am a fast and avid learner in the past, and I plan that this won't be any different at your company. The next reason is that I deeply care for the cloud. Most of my personal work is based on it. I would love to bring my expertise in this field into the company and see whether I can help you advance there further. I would even go so far as to say that I am very motivated to become a core contributor to this field in your company within the next two years. Another reason is your engagement with your local community. I also regularly engage in my local community and think that our values align perfectly here. Perhaps I could help with my expertise and could equally learn from yours. During our interview, you mentioned that you currently try to rebuild your education program. As a content creator on the internet, I would really love to help with my expertise. I think I can contribute a lot to this area. And lastly, I believe that we have had an awesome interview so far and seem to align quite well. For me, we seem like we fit well culturally, and I'd love to be able to thrive in the one that you carefully built."

This is only an example, but it should give an interviewer nearly anything they could ask for.

It gives them not one but multiple reasons to hire you
It shows your ambition
It showcases your interest to contribute
It states you listened to the interview

Keep one thing in mind: Your answer doesn't need to be perfect. But it should tick many of the boxes interviewers are looking for. Sell yourself as the best hire and make sure they understand that you think they are the best company for you right now.

Before You Leave

If you would love to read even more content like this, feel free to visit me on Twitter or LinkedIn.

I'd love to count you as my ever-growing group of awesome friends!