The bootcamper cheat sheet

Or, how to land a job in your dream startup after attending a coding bootcamp.

As I mostly work with Ruby or Ruby on Rails, I wrote all the examples using these languages. I apologize for the JS/PHP/Python… lovers.

Me

After studying mechanical engineering and working as a data-analyst, I’ve enrolled in the batch #2 at Le Wagon. Since then I’ve been CPO of an unborn app, built my very own product (rip fivemarks.in 😢), worked as a back-end engineer at a web-agency and, finally, I’ve been a back-end developer at Aircall, an eFounders company and one of the fastest growing french startup, since june 2016.

You

So you’ve just finished your coding bootcamp and you’re looking to start your new career as a junior developer. After several weeks (depending on which bootcamp), you’ve learned the basics to become a full-stack/back-end/front-end developer.

As you may think, a weeks long intensive training is not exactly the same as graduating with a MSc — Master of Science — in CS. Recruiters have that in mind, thus they likely won’t ambush you by asking you to reverse binary trees.

When it comes to real junior developers — i.e. developers who have never earned money writing code - bootcampers we screen at work perform as good as more classicaly trained developers.

Lucky you, you’re most likely to quickly find a new job

Enough chit-chat, let’s jump into the good parts.

What tests will you have to pass 👨‍🏫?

Basically there a three types of tests company may ask you to take.

• A basic algorithm/coding test: It can go from writing a fizzbuzz to resolving some NP complete problems. It allows companies to ensure candidates are academically great. One good way to train for this particular exercise is through codewars (leetcode is a great alternative). Don’t be too scared, most companies won’t give you problems harder than the 6kyu level.
• Reproduce a basic functionality of a company’s product: Basically you will reproduce a core feature of the company you’re applying to, usually in a simpler form, using the same framework the company uses. It allows companies to ensure candidates are proficient with its framework and have a better idea about what the candidate’s code would look IRL.
• Pair programming session: You will pair program with a developer on a — usually — quite simple problem. The interviewer will ask you several questions during the sessions in order to assess your expertise. It allows a company to figure out how a candidate reacts in real life situations and her/his cultural fit.

Your code will have swag ✊

When you’re asked to take a coding test, recruiters will be waiting for great code. Following the best practices and write concise, readable, clean and maintainable code will be greatly appreciated. You will even get extra kudos if your code runs fast 🏎…

For example, let’s say you have a fairly simple test, a fizzbuzz.

You can solve the problem by writing really bad code like the following example.

😢

This solution works but it will demonstrate you’re a sloppy developer. First your method name is really badly chosen. The code is not really readable (intricate ifs are bad) and you don’t follow any Ruby best practices.

So, how can you submit a better version of your code?

Lint it and refactor it

Using a linter will make you a better coder by showing you the best practices from your languages. Every languages have an associated linter you can run in your terminal or directly in your text editor.

After some autocorrections done using rubocop and renaming the method to be more understandable, here is our fizzbuzz.

😐

When linting the file Rubocop still finds some offenses… Still not great.

Inspecting 1 file
C
Offenses:
fizzbuzz.rb:1:1: C: Method has too many lines. [13/10]
def fizzbuzz(number) ...
^^^^^^^^^^^^^^^^^^^^^^^^
fizzbuzz.rb:2:3: C: Prefer each over for.
  for i in 1..100 do
  ^^^

A little refactor and we have an acceptable fizzbuzz.

But our method is still too long 😛. And all this ifs are not that swaggy.

🤓

Finally something we can be proud of. No offense detected and almost a one liner. Yeeeeehaaaaaaaa.

You embrace testing ✅

Depending on what bootcamp you’ve attended you may, or may not, have familiarised with writing tests. However, testing is a huge part of a professional developer’s life so the sooner you start learning it the better.

One good and easy way to start is to take one of your bootcamp project and add tests to it. Start by unit testing and then move to integration tests then end to end tests. It is very fast to learn and master the basics of testing, which is just what you need to start as a junior software engineer. It will also help you improving your code by allowing you to handle specific edge cases and worst case scenarii.

1. Add tests to your interview

You will often find the following requirement when looking for an engineering position: Experience with TDD environments (RSpec, Minitest, Capybara, Selenium) …

It is a fact, as soon as a startup gains traction and starts scaling, you have to be dead serious about quality and maintainability. Therefore you will have to write a lot of tests! While I personally find TDD (Test Driven Development) too cumbersome (and I’m not the only one, see DHH view on it), I totally agree that all the code you write should be thoroughly tested.

But, let’s got back to our application process. Passing the challenge is a great achievement, but passing and adding tests to it will make your application stand out. As you will see, adding some tests is extremely easy.

So let’s go back to our fizzbuzz and let’s add some tests.

Adding these simple lines of testing show you’re proficient with unit testings and follow good practices such as TDD.

2. Add coverage to your interview

When testing your application, the holy grail is to reach a 100% code coverage. Meaning that any method you’ve written has some code testing it. When you submit your assignment and you have reached a 100% coverage, feel free to add it. For example, when working on sample ruby/rails app you can use simplecov to generate your coverage.

Maybe you’ll sound a little bit cocky, but you would have proved you’re serious about code quality.

You know how fast is your code 🏎

When you scale, writing maintainable code and tests may not be enough. Some critical parts of an application may require to be deeply optimised, wether it is regarding your throughput or your memory footprint.

We should forget about small efficiencies, say about 97% of the time: premature optimisation is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

It’s likely that, when doing your application assignment, you’ll miss a few possible optimisations. Most of the time it won’t be a dealbreaker, but you should be able to answer questions about these possible optimisations.

1. Know your complexity

If you’re asked for a simple algorithm test. You can almost be sure the interviewer will come up with a question about the complexity of your solution and what is its big O.

In order to make a good impression, even if you may not come with a better solution on the spot, you should be able to know where your code stands in terms of performance.

2. Sharpen your queries

When working on a web-app, databases can quickly become bottlenecks. Moreover, it is a real pain to upgrade a database and it can not be done without generating a downtime so, please, take care of your database and treat it gently.

Most web frameworks come with their ORM. This means you won’t have to write a single SQL query within your app. While being super handy, it may make you crazy when investigating why your database is so slow.

The n+1 query

It is the most common issue when returning a collection of objects. Luckily it is also one of the easiest to tackle.

First, what is a n+1 query?

Considering an application with an Author model and a Book model where an Author has many Books.

### books_controller.rb
def index
  @books = Book.all
end
### books/index.html.erb
<% @books.each do |author| %>
   <tr>
    <td><%= book.author.name %></td>
    <td><%= book.title %></td>
    <td><%= book.content %></td>      
    <td><%= link_to "Show", book %></td>
    <td><%= link_to "Edit", edit_book_path(book) %></td>
    <td><%= link_to "Remove", book, method: :delete, data: { confirm: "Are you sure?" } %></td>
   </tr>
<% end %>

You will make 1 query in order to fetch the book records and, when rendering, you will make 1 query for each book — so n queries — to display the author. Therefore you will trigger n+1 queries.

Like I said, it is really easy to solve that issue as most ORM’s provide some lazy loading helpers. For examples, includes and preload in Ruby on Rails — more details here. Thus, you can rewrite your controller with the following syntax, which get you rid of the n undesired queries.

### books_controller.rb
def index
  @books = Book.includes(:author).all #or Book.preload(:author)
end

One query to join them all

inner join, right join, left outer join, but what does it mean???

One big drawing is worth thousands words

When using your ORM lazy loading capabilities, it will perform a join or an additional query to fetch associated records.

Depending of your database, you should choose between using joins, making an additional query or using subqueries

This is one of the most important thing to know when working with databases. Depending on your database schema, joining can make your queries painfully slow vs using subqueries. Therefore you should compare the different approaches and choose the best for your specific needs

In Index Veritas

One of the most common question an interviewer can ask to a junior web developer is what is an index and when to use it?. You reeeeeaaaaaaaalllllllllyyyyyyy need to be able to answer this question!

First, read this article. Then follow these rules of thumbs.

• Every time you use a where clause when querying your database within your app, you should use an indexed field
• Every time you have relationships between tables you have to index the foreign key
• When doing scoping or composite queries, use compound indexes
• If you want to use uuids it is fine, but keep your regular id as the primary key, it will make your queries faster
• When doing advanced queries, use explain method to ensure you use the right index. If not, force it!

Jedi Trick: subqueries

Using scope instead of triggering queries will allow you to use subqueries. Read carefully the following code…

Miscellaneous Skills🚨

Devops

As a junior web-developer, no recruiters will ask you to be a certified DevOps. Nevertheless, a candidate showing interests for Ops subjects such as modularity, scalability or security will get a lot of attention. Spend some time learning the basics of DevOps, try to gain a little bit of experience on AWS or Docker. Sharpen your monitoring skills, learn to use tools like Datadog or NewRelic, it will have an amazing ROI.

Git

Please, master git… It won’t help during your interview process or for completing your assessment but everybody prefers working with someone who’s proficient with Git and does not mess up everyone else jobs by screwing up the repo. Spend some time exploring git, mess up at home, and never forget there is always a way to going backwards.

Design, Data, Finance, Writing…

If you come with a background with a strong vertical such as design, data, finance or writing you may use these skills easily within your new company.

Just propose projects at the crossroads of your developer jobs and your old job/education. This will demonstrate your creativity and earn you an unique spot within the company.

Keep in mind that startups are fast paced environments where everybody has many different roles. Mastering different subjects will always be strongly appreciated.

Mindset 👩‍🎤

Something recruiters love with bootcampers, it is their mindset which usually perfectly match the startups’ mindsets. But, entering the startup world as a developer is just a new beginning.

Stay foolish, stay hungry

Keep learning and keep being curious

When you’re a developer you’re always late. Things evolve at such a high pace you can barely keep up. You will have to keep learning. Learn new languages, learn new frameworks…

You will likely be working with other tremendously talented developers. Be a sponge and learn from them, this will be your best and most efficient way to perfect your game and learn new skills.

Keep being passionate and keep having fun

I think there is one key difference between good developers and great developers, this is passion. You can hardly become a great developer without it. While you may have hard times at work, keep having fun when coding. It can be by working on side projects, trying new technologies… Be curious about what is going on, you will always find new and exciting things.

Embrace your singularity

Coming from a different path than a classic CS academic background is a great advantage over other candidates. Showing how these uniques combination of skills and experience would add value to the company will make your application stand out.

Final words

I hope you’ve enjoyed this article and that it will help you getting a job at your dream startup. While most examples are based on Ruby On Rails, all the advices can be extended to any other programmation language. Feel free to add your own examples in your favourite language, I would be more than happy to integrate them.

A few training resources

Testing

Back to Basics: Writing Unit Tests First

Better Specs { rspec guidelines with ruby }

Writing automated tests is THE thing to learn as a Developer Newbie

Databases/ORM

ActiveRecord Eager Loading with Query Objects and Decorators

Computer science

I strongly recommend any junior developer to read this amazing book by Wladston Viana Ferreira Filho which is extensive, enjoyable and accessible.

Computer Science Distilled

The classic pragmatic programmer collection, all the books are great but, they are more specialized. They’re extremely useful when you want to jump on new technologies or go deeper on technologies you already master a bit.

The Pragmatic Bookshelf

An other classic, cracking the coding interview is a great preparation if you want to apply to a company which is espacially keen on hiring developers with strong academical and algorithmical skills.

CRACKING the CODING INTERVIEW