Basic requirements for Infinum JS Academy

This list of books, links, and required knowledge will allow you to enroll and finish Infinum JS Academy. One who does this exceptionally well will also get a job at Infinum.

If you find any errors in this guide please report them to me!

Basic programming

Pick any programming language and start working with it. You can start with JavaScript but yo can do with Python just fine. The most important thing is to go thru these books:

Once you skim the books and acquire as much as possible from them you can start programming.

Basic projects

The way I teach is by using examples and real projects. I believe that is the best way to learn. I recommend picking a problem you have and creating a software solution for it. If you picked the Learn Python the hard way book to start you can create basic API’s and create very simple solutions for it. If you want it can be a terminal application as well but the most important thing is to use what you write so you get the feel for bugs, fix them, add features, etc.

Getting into JavaScript

Once you’re done with the reading above and you can answer simple questions like:

  • What is a variable?
  • What is a function?
  • What are APIs?
  • What is a network request?

you can start learning JavaScipt. I’ve written a comprehensive guide on how to JS like Infinum does here.

Getting a job at Infinum as a Junior

We employ juniors all the time and they probably know as much as you do (if you read all of the books above). I won’t give you the interview questions since they are specific to you and your knowledge but as a helpful guide look at the questions below and see if you can answer them. If you can you’re good to go!

  • Pick one sorting algorithm and explain it.
  • What is a database?
  • Pick one design pattern and describe it. How would you implement
    it in JS?
  • Describe an HTTP connection.

Just as a note we don’t do whiteboard interviews.

Vue.js vs. React, or – please stop the bikeshed

A note: views expressed here are mine and mine only. In no way this represents Infinum, but it does affect the way I teach at Infinum Academy. I take great pride in that. If you don’t agree with me – that’s fine and I would like to hear you out. Tweet at me, or email me :). The end goal is to help people.


The JavaScript community is very diverse and divided. We “fight” over bundlers, package managers, editors, frameworks, libraries, code styles, etc. the list could really go on forever. This, in part, is why we as the community and JS as a language are both perceived as immature, contributing to the thing we like to call JS fatigue, and all in all a total mess. A great deal of “hate” we owe to browser vendors and the inability to deprecate stuff, but the other part of the blame is on all of us.

I’ve been a JavaScript developer for little over three years now, with a couple of big projects behind me – on some I was just helping around, other I’m leading and making technical decisions. I’ve mentored students and colleagues, reviewed pull requests for Backbone, React, and Vue.js; and helped define Infinum’s coding style for React and TypeScript. And this blog post is my answer to the “age”-old question – should I learn React or Vue.js?


If you’re gonna stop reading now and comment anywhere – comment on this statement: “start with anything.” You can start with either of them or even something else (my first JS project was Backbone.js). Teach your self the basics of the language and learn to avoid the pitfalls of endless Twitter/Hackernews/Reddit debates “my framework is better than yours”.

Importance of having a stable base

While I’ll be one of the first people who preach and talk about just starting and building stuff, I’ll also be the first to back up the idea that without a base your house is unstable, and so is your JavaScript knowledge. Sounds contradicting? Allow me to explain.

Whatever you pick as your starting point, you’ll have the same problems to overcome, especially if you’re new to the whole JavaScript thing. How do I get the data to my application? How do I show that data? How do I style the data? We can have long discussions on any of this questions; axios vs. fetch, redux vs. vuex, scss vs. css. But at the end of the day the problem has to be solved, and whatever you pick I guarantee it you can apply that knowledge across the whole ecosystem.

Echo chamber

When you pick a framework to work with you undoubtedly pick a community too. You’ll probably want to follow people working on the same tool as well, maybe even listen to a podcast, subscribe to a newsletter. What you are doing is fine, really! – but understand that you are entering a huge echo chamber.

What you are also doing is perpetuating the self-generated discussions how your tools are the easiest to learn (OMG just look at how I can make a component with zero boilerplate), or even how performant your language is (0.545345ns first paint!!! #perf). What also happens inevitably is commenting on how your tools are the best! And again – all of this is normal!

But(!), you’re also never learning about other tools and what they do good or even better. And this is really bad – for you and for your community.

There is a time and a place to worry about performance and boilerplate – but that time is not when you’re just starting out.


I have a unique position and an opportunity to help shape young JavaScript developers in Infinum’s Academy. I chose a framework (React+MobX) to work with because I know that when they start looking for a job a CV with “knows JavaScript well and in detail” won’t land them the same opportunities as “a React developer.” But what I put the focus of the Academy on is the mechanics of the language, project structure, good practices, etc. All of which are applicable to any frameworks out there.

I’m really proud of two of my past students, now colleagues and friends. Both of them started with React, but now are proficient and working with Angular and Backbone respectively. If they spent time discussing and going back and forth between frameworks, or even (and this hurts me to write) listened to influencers preaching a framework other than what they chose and then kept switching they would not be where they are now. And I’m glad to say that they are both very respected members of the JS team.

To a junior dev

Whatever you start with is fine. Also, it’s fine to start with a framework that has the cutest logo (the only reason I started learning GO). Just stick with it to the end and you’ll be able to pick up any framework that you wish later. Stop focusing on why JSX sucks, or why vuex is a terrible choice for beginners.

For those just learning to code now- remember when you were learning to drive? You had to think about everything constantly- but eventually the car became an extension of yourself. That’s how it will be. You will eventually have muscle memory built into many tasks. Stick with it.— Sarah Drasner (@sarah_edo) April 3, 2018

Spend that time building and learning so one day you’ll be able to pass that knowledge onto another person. And maybe, just maybe, we can focus more on our end users and our products a bit more instead of angry tweeting about webpack vs. fusebox, angular vs. react, …


Not so long ago I was also one of the people defending my choice over other. I was wrong and I’m making sure to make an effort now to invest time into understanding what the base should be. At the end of the day it’s just a tool; you can use one but don’t be one.

I have a getting started guide written over at Infinum’s blog. It still is what I think a good starting point is, and what I’ll recommend if you ask me. This blog post doesn’t change how I feel about the one published on Infinum’s blog, and vice versa.

Quick guide to GnuPG

Point of this document is to get you up and running. We will explain the basics of how PGP works, setup on MacOS/*nix systems, encrypting/decrypting data, and the process of signing and verifying messages.

Please note that once this document is more than a year old you will need to recheck all of the things mentioned here.

Last edited: 09/02/2017


There are a few ways you can setup PGP on your computer, some will include a wider set of tools, and others will cover only the basics. You might want to have a look at, OpenPGP, or GPG suite. Today we will focus on gnupg – it will provide all the needed tools in a compact form.


  • MacOS brew install gpg2
  • on other systems install the latest version of gnupg

You need to define a pin entry application. Do the following after installing gpg2:

echo $(which pinentry) >> ~/.gnupg/gpg-agent.conf
gpg-connect-agent reloadagent /bye

Generating your keys

Start by issuing gpg --gen-key. This will ask you a range of questions: your real name, email, type of a key, and key size.


  • RSA and RSA key type
  • 4096 key size

Use a secure passphrase that you will never share with anyone!

This will generate your private and public key pair which you can use for all further actions.

Sharing your keys

Without sharing your keys all of this is in vain. What you will give out to people who you trust is you public key. You can export that using the following command:

gpg --armor --export <your email>

example of that would be:



Importing keys is also really easy. Let’s presume that the key we saw before is saved in the file called andrei.asc.

gpg --import andrei.asc

Signing keys

Each key should be signed. When generating your key, you sign it by default. After exchanging keys with someone you might want to sign theirs and upload it to a key server (more on that later). You can sign their key like this:

gpg --edit-key sign save

Be sure to sign their key only if you trust the source where you received it from. Usual places would be other people servers (like this one), Facebook, etc.

Uploading to key servers

Keys are usually uploaded to a key server for others to get and upload. You can upload yours and other people keys. If you signed their key When uploading it, you are making that public.

gpg --keyserver --send-key F611EAEFA07D5401

Substitute F611EAEFA07D5401 with either your key ID or your friend keys ID.

In this example I used You can use it or any other key server. Note that you can also use Keybase, but the upload procedure will differ. Also, now you can host your public key on Facebook as well – add it here.


When you encrypt a file you need to add all of the recipients or else no-one will be able to open it. If you do not add your self you will not be able to open it.

gpg -e -r my-file.txt

You can now send my-file.asc via email or Slack. More recipients can be added by adding -r <email> as many times you need.


If you got a file that is intended for you you can decrypt it using the following command:

gpg -d my-file.asc

And, provided that you have the correct private key you can now read the contents.

Signing messages

If for some reason you need/wish to provide proof that it’s really you who have sent the message you can sign any file following this commands:

gpg --clearsign <file>

this will create a file with the same filename but the extension will be asc. This file can be distributed around. It’s contents are in plain text but it contains the info about who signed the message and if the message was changed in any way. Your message might look something like:

Hash: SHA256

Hello world!


Verifying the message

You might want to verify if the message you got is really from the sender. This can be done by:

gpg --detach-sig <file>

This will create a file with an extension sig that can be used to verify the message:

gpg --verify <filename>.sig <filename>

Please do verify your messages.

Image courtesy of XKCD.