DEV Community: Carlos Roso

FAQs for future Toptalers

Carlos Roso — Thu, 23 Jul 2020 20:51:15 +0000

This is not an official FAQ from Toptal. It's all based on my personal experience. Take it with a grain of salt - very opinionated notes ahead. These are all real questions I've been asked over the years.

Once I get accepted, how long does it take to get a job?

It depends on factors like your specialty, experience, time availability, and timezone. In general, for a web developer with +3 years of experience looking for full-time or part-time, I'd say you can get a gig in 2-3 weeks.

Can I make a living working in Toptal?

Yes. I've been working (as talent) at Toptal for quite a few years now and it's been pretty stable. For 18 months I had a contract for 50 hrs/week paid at a very good hourly rate. I married, traveled, and lived well.

What kind of jobs can I get at Toptal?

There are certainly more jobs for web development (both for backend and frontend) than anything else. Clients are normally looking for experts, expect to be treated as such. Jobs are mostly full-time and part-time.

How can I prepare for the interview?

Assuming you're a developer, you basically need English proficiency and fluency solving algorithms. It also helps to have a minimum of 2-3 years of experience. I wrote a free eBook to help you.

How much does Toptal pay?

You can set your own rate. However, it's unlikely for a client to pay you $100 USD/hour, unless you're very special. I'm under NDA so I can't disclose my rate but Toptal shows some average numbers here and here.

I sent this post weeks ago to +1100 devs on my email list. Join here or follow me on Twitter if you want to get my tips and thoughts on career growth.

Should I learn X language to get into Toptal?

You're good if you know some of the popular languages and frameworks. They have clients looking for C#, Drupal, Python, JavaScript, Java, React, SQL, Angular, iOS, Android, etc. Stick to whatever you're good at.

Do they only offer short-term freelancing gigs?

No. I worked with a client full-time for 18 months until I decided to part ways. Full-time and part-time jobs are normally expected to last between 6-24 months.

Do they pay vacations?

None of that. You work for one hour, they pay you one hour. You might get special treatment if you have a very good relationship with your client. The norm is to pause your engagement once you go on vacation.

Do they pay health, retirement plan, or any other benefits?

No. As a freelance, you need to take care of that yourself.

As for taxes, do they deduct something from your wage?

No. Once you get in, you sign a form where you confirm you'll be paying taxes in your country. You will then report your earnings as an independent contractor in your country.

I don't have much experience, can I still get accepted?

I don't recommend applying if you don't have at least 2-3 years of experience. It'll be a disservice for you, the client, and Toptal. Don't rush. Enjoy being a junior but train like you're an expert.

I'm not good at algorithms, can I pass the interview?

No. You won't make it too far in the process if you're not fluent in solving algorithms. Check out my free eBook to prepare. Then start solving easy-level algorithms in Leetcode, Hackerrank, or Interview Cake.

How difficult it is to pass the interview?

I have referred well over 190 people. Only 3 of them have passed. Now, this is not to scare you. The process is not difficult per se, it just needs a good amount of preparation.

Are there any challenging or interesting projects at all?

I'd say 90% of the projects are very challenging. I've worked on hard things I didn't know I was capable of like web 3D graphics, service workers manual tuning, CICD setup from scratch, you name it.

Do you have to compete with fellow Toptalers to get jobs?

Yes. Toptal recruiters find a handful of Toptalers to fulfill a position. Then the client interviews all of the Toptalers and picks whoever they want. There are plenty of projects for everybody, though.

I'm afraid to quit my job for Toptal. Is it stable enough?

There's no need to quit your job. First, pass the interviews. Then, pick up an hourly or part-time job. Once you feel ready to take the plunge, do it. If Toptal doesn't work out, there are some more platforms to work on.

I've heard Indians or Africans never make it. Is that true?

That can't be more misleading. I myself have interacted with very impressive developers from all over the world in Toptal including, of course, people from India and Africa.

I currently make $100 USD/hr. Can I make more than that in Toptal?

You're better off doing your thing. You won't probably get that much in Toptal but maybe, if you're very special (99th percentile), you can get very close.

Is it hard to change your rate?

You can change your rate whenever you want. That is, you still need to go through an uncomfortable conversation with your recruiter. Stay firm and ask for what you deserve.

Do you need to stick to a work schedule?

Most likely not. It depends on the client. Just make sure to set clear expectations with the client and be responsible. Join any mandatory call and then manage the rest of your time as you please.

Got any more questions? Ping me at Twitter or post them in the comments. I'll keep this post up-to-date as I come across more questions.

Prepare and ace the interview

I wrote a FREE guide with a lot of tips and tricks to ace the Toptal interview. If you're curious, you can sign up here and get it right away.

Lessons learned doing open source

Carlos Roso — Thu, 16 Jul 2020 23:07:15 +0000

I'm not popular in Github but I have a repo with 1.5K stars and 1M hits/month. I got some more with a few hundred stars. Here's what I've learned along the way.

Build good looking demos

This may come off as superficial but it's worked wonders. I write frontend libraries where demos are critical for adoption. I put a lot of hours designing and coding good looking demos.

It's fine to be inconsistent

I used to beat myself for being inconsistent. Not anymore. Github is my lab, not my job. I make sure to have a stable, working version on master and move on. I come back once motivation strikes again. I play it long term.

Build framework-agnostic libraries

Building libraries for frameworks is fun and it has its niche. But, if you want to have more impact, architect your libraries to be framework-agnostic and easy to plug anywhere (see next point).

Write framework-specific recipes

Whether you do backend, frontend, ML, or whatever, chances are your users are using frameworks. Write easy-to-follow recipes for how to plug your library into any of these abstractions. It'll boost adoption.

Have a clear scope

Devs complain about clients asking too much yet we do the same on Github. You'll get a myriad of feature requests if your OSS project takes off. Communicate your scope. Learn to oblige. Learn to decline.

I send posts like this to +1050 devs on my email list. Join here to send you my tips and thoughts on algorithms and career growth. If email is not your thing, follow me on Twitter to get sneak peeks of what I'm working on.

Relaunch

I'm not a marketer so launching is always a gamble. What I've learned, though, is you must relaunch. People might have not seen your stuff the first time. Release a new version and write a blog post. Tweet about it.

Sneak in to understand usage

Use the Github's Dependency Graph to see who's using your packages (lots of supported ecosystems). Then visit your users' repos and analyze usage. Are they hacking it to fix a hidden bug? can you improve the API?

Use badges but don't oversell

Scientific research has shown that badges are positive signals for contributors and users. Adding a badge doesn't change popularity but popular projects are more likely to have badges. Use assessment badges.

Use a GIF

You have just a few seconds to convince users to try your library. Put a GIF at the top of your README to help them quickly jump in. You can use terminal screencasts, GIF recordings or screenshot sequences.

Yes, build it again

Unless you're a seasoned OSS developer, you need to build yet another version of popular things. This will ignite your curiosity to try bolder things later. Don't try to code the next big thing. Just build something. Today.

Redefine success

I have unpopular projects with little to no installs. I'm proud of them, though. I learned a lot from building them. I use them myself. I'm getting better and enjoying my projects. That's my ultimate bar for success.

Be aware of moniker naming rules

Not sure about other ecosystems but NPM has moniker rules for package naming. I learned it the hard way. Pick a good name and make sure you can work with it. Only then start coding.

This is a personal journal for things that have worked in my open source work. You might want to save it. I'll keep updating this as I come up with new findings.

Do you have any advice to build good OSS projects? Let me know in the comments!

Shameful self-promotion

My mission is to help devs grow by posting tips to write CVs, teaching algorithms, or talking about my experience working on top remote workplaces. I also shared my experience transitioning to Machine Learning and put up some fancy illustrations to explain computer science problems. I wrote an eBook to help you land a job in Toptal. You can sign up here and get it right away.

Are these lists equal?

Carlos Roso — Thu, 09 Jul 2020 22:22:21 +0000

This is an entry-level algorithm to get you warmed up for tough interviews like those you get in Amazon, Google, Toptal, and top remote work sites. It'll get you exposed to a real-life problem with time complexity analysis and data structure exploration.

The problem

Given 2 unsorted lists, determine if both lists contain the exact same items. You can assume that there's no duplicate item in any of the lists.

1. Brute force makes it work

Rule #1 to solve algorithms: Come up with a brute force solution first. The best solution is simply the worst one after some rework. How do you normally check if an item exists in two lists? you traverse both lists and try to find the same item in both: "For every element in list 1, loop through list 2 and try to find it".

The figure above shows the comparisons between the lists. Compare 1 to all the items in list 2; then compare 6, and so on. But, what's that n2 weird curve at the right? Let's talk about time complexity.

BigO: n^2 for the nested loop

Make sure to read this quick recap on BigO complexity if you feel lost about this topic. For every item in list 1, you need to loop over all the items in list 2. That is, take item 1 and visit all 5 items in list 2. Rinse and repeat for the remaining items 6, 2, 9, and 3. That results in 25 comparisons (5+5+5+5+5). A list with 10 items would result in 100 operations. That's why we say out algorithm resolves in quadratic time O(n^2).

I sent this post weeks ago to +950 devs on my email list. Join here to send you my tips and thoughts on algorithms and career growth. If email is not your thing, follow me on Twitter to get sneak peeks of what I'm working on.

2. Sorting makes it better

Brute force proved to be effective but not efficient (too many comparisons). Let's get clever. What if we sorted both lists and then compare items by their indices? After all, if both lists are sorted, the first items should be identical (i=0), same for the second items (i=1), and so on.

As you can tell from the illustration, we first sort the lists, and then we make only one comparison per item. We stop when we find a mismatch on 2 items with the same index.

BigO: nlogn for the sorting algorithm

As previously explained, sorting arrays bring benefits but it also comes with a cost. The sorting cost is normally understood as O(nlogn). This complexity is better than our brute force solution, though, so we made our algorithm a bit more efficient.

3. Counting makes it perfect

O(nlogn) is not "as cool" as we'd like our algorithm to be. Can we do better without sorting, and without a lot of rework? Let's think about this.

If two lists contain the same elements, then I can find the same amount of 1s in list 1 than in list 2. If I tell you "I have two 1s and three 2s in my list" you can then count the occurrences of the numbers in your lists and verify we both have the same frequencies. Can you spot the pattern now?

We're changing the problem from "are these list equal?" to "verify both lists have the same frequencies for all items". We now have a 'counting' problem: count the frequency of all items in list 1 and compare it with the frequency of all items in list 2. This is what hashmaps are useful for.

In the image above, we loop over every item and register in our "frequency" hashmap (i. count items). We build a hashmap for every list. For example, we visit item 2 in list 1 and we add a new record in our hashmap: <2, 1>. This means "item 2 appears 1 times in list 1".

Finally, we loop over the keys in the hashmap #1 and compare the values with the same key in hashmap #2 (ii. compare counts). If the key is not found in hashmap #2, then the lists are not equal.

It seems like this is a lot more work, so, is this really more performant?

BigO: n for just one pass at the lists

Let's count the operations:

Loop over list 1 only once. That is 5 items.
Loop over list 2 only once. That is 5 items.
Loop over the keys in the hashmap. That is 5 items (worst case).

This results in 15 operations. If we had 10 items, this would be 30 operations (10+10+10). Hopefully, you can see a linear correlation here: for lists of length n, we do 3n operations. In computer science, we often simplify O(3n) to O(n).

We finally arrived at an algorithm with linear execution time. When you understand that O(n^2) is worst than O(nlong) which is worst than O(n), then you realize we have arrived at our most performant solution.

Note: This algorithm will also work for lists with duplicate items. Can you understand why? Explain us in the comments!

Show me the code

Let's see how our most performant solution looks like in code. I'm doing it in JavaScript just for familiarity.

function areListsEqual(list1, list2) {
  if (list1.length !== list2.length) return false;

  // count items from list 1
  const map1 = {}
  for (let item of list1) {
    map1[item] = (map1[item] || 0) + 1
  }

  // count items from list 2
  const map2 = {}
  for (let item of list2) {
    map2[item] = (map2[item] || 0) + 1
  }

  // compare the counts, return false if counts dont match
  for (let item in map1) {
    if (map1[item] !== map2[item]) return false
  }

  return true
}

areListsEqual([1,6,2,9,3], [3,1,9,2,8])

Here's a blitz with the working code. Can you adjust it to work with 3 lists? Send your blitz in the comments!

Key takeaways

If you can only remember one thing from this post, let it be one of these:

Find brute force solutions first.
Sorting is nice, but it comes at a cost.
Hashmaps will land you the job.

I wrote an eBook to help you

My mission is to help devs grow by posting tips to write CVs, teaching algorithms, or talking about my experience working on top remote workplaces. I wrote an eBook to help you land a job in Toptal. You can sign up here and get it right away.

How I went from Frontend Dev to Machine Learning Engineer

Carlos Roso — Thu, 02 Jul 2020 19:47:29 +0000

This is the story of how I went from zero to do real client work on Machine Learning.

I want to keep this article short so you can grab what's useful for you and leave. But, if you're interested in the details with pictures and personal opinions, you can read the full story on my site.

Note: I hate overnight success stories like "how I reached X in 3 months", I don't think real progress comes like that and it's just stressful for the reader. Therefore, I'm just going to say this all happened in the span of a year or so.

TL;DR

Here's an overview of my journey. In the next paragraphs, I'll put useful links and a bit of my personal story.

I respect your time so I'll summarize a lot. Go here if you want to read the full story, though.

1. First book

My wife got me this Machine Learning handbook from MIT. It's a pretty short overview of the topic that got me triggered to dive deeper.

2. First online course

I then enrolled in the Data Scientist with Python track in DataCamp. I didn't finish the whole course, just took a few lessons until I felt I could move on alone.

3. Second book

I bought a copy of the book Hands-On Machine Learning with Scikit-Learn and TensorFlow. It was a terrific investment. This book is great to learn supervised and non-supervised learning with Scikit-Learn as well as deep neural networks with Tensorflow.

4. First competition

I then tried some luck at the Kaggle's Titanic Machine Learning competition. This is the "hello world" of Machine Learning competitions.

I ended up submitting 3 attempts. I didn't get good scores but I was proud I put in the time and self-discipline to finish the challenge.

This is the type of content I send to +850 devs on my email list. Join here to get my tips and thoughts on algorithms and career growth. If email is not your thing, follow me on Twitter to get sneak peeks of what I'm working on.

5. First real-world project

I secretly built an unsolicited news topic classifier for the company I worked for. It would analyze the content on a news article and predict its category (sports, politics, religion, etc) based on previous training.

As it turned out, they didn't like it at all. I didn't feel like trash, though. I proved myself I could do ML professionally. I moved on.

6. Second competition

I went to compete on the AWS DeepRacer Scholarship Challenge which would grant access to enroll in the Machine Learning Engineer Nanodegree Program.

The competition consisted in tuning an autonomous racing car to complete a track as fast as possible. The top 200 times would get the scholarship.

(Self-note: next time don't take pictures with a potato). I ended up winning the scholarship but not for my scores, my lap times were crap. I got mine either for luck or for creating this repo with some resources for new competitors. I didn't ask, though. I moved on.

7. Second online course

I enrolled in the Machine Learning Engineer Nanodegree Program with the scholarship I'd won. It was basic but I learned a lot about deploying ML models to production in AWS.

I didn't like any of the choices they offered for the final project. I then decided to find something meaningful to work on.

8. Second real-world project

I reached out to my friend Nicolás who happens to run one of the biggest crowdfunding sites in Latin America, Vaki.co. I proposed to build a recommender system, à la Netflix or Amazon. He liked the idea and we started working together.

After several weeks of work, I built a hybrid recommender system that predicts recommendations based on two models: Content-Based and Collaborative Filtering. You can read the full report over here. It's ready to be used in production but hasn't yet been implemented (out of my scope).

I haven't built anything else after that. I don't want to devote myself to something I picked out of FOMO and which doesn't really spark that fire within me. I have added something new to my toolbox, but I won't necessarily switch paths anytime soon.

Key takeaways

The ultimate guide to learn is non-existent. Everyone needs to find their sweet spot. For me it is print books, pen and paper, and practicing with real/dummy projects.
Do your best to understand the math. Tuning hyperparams or reasoning about model performance feels weird without a good foundation.
I'm not a researcher, I'm an engineer. I'm ok with not understanding all the latest, complex advances in AI and ML. I'm happy to understand and use common ML tools to solve real problems. For me, Machine Learning is just a means to an end, not the end itself.
I don't like that feedback is very slow on ML. It's very frustrating for me, coming from a product background, to train a deep neural network for hours just to see garbage results and not be able to tell why.
Dive into other topics to grow your toolbox but don't deviate from your true path, whatever that is. I'd rather double down on my strengths than being a jack of all trades.

Thanks for reading. Never stop learning!

Shameful self-promotion

You can follow me on Twitter or just keep reading me here. I wrote about my story getting into Toptal, my recommendations to write a good resume, a curated list to find top-remote jobs, and some more advice to ace algorithm interviews. I also wrote an eBook to get into Toptal, check it out if that's your thing.

Hashmaps like you've never seen them

Carlos Roso — Wed, 24 Jun 2020 18:57:51 +0000

Enter hashmaps. You're using them every day, yet you might not be aware of how it works or why you're preferring them. Why do I say it's the best? not only it is your silver bullet in any coding interview, but it also gives you free performance gains in your day-to-day code.

Hashmaps disguised as objects or sets

Open your last project and you're almost certainly using hashmaps all over the place. If you're writing JavaScript, they are just plain objects { name: 'carlos' } (not strictly, see the final section). Java uses the HashMap object, Python calls them dictionaries, and Go has maps. Let's see a TypeScript example, just for the sake of the illustration.

const ages: Record<string, number> = {
  carlos: 28,
  leena: 34,
  luigy: 14,
  maria: 54
};

So, you're familiar with the concept - you know how it looks like, but, what is it?

A ridiculously efficient way to read and write

A hashmap is a data structure (i.e. a piece of code to manage data) which is absurdly efficient to store and retrieve data to/from memory. Think of it as a table with pairs. A 'key' is how you identify a 'value'. In the previous section, the keys are 'carlos', 'leena, 'luigy', and 'maria'; the values are 28, 34, 14, and 54.

Hash. As for 'hash' function

A hashmap is an array on steroids. The difference is that you don't access the array with numeric indices, but instead with objects. How come so? How do you point to something in the array if you don't have its index?

Simple: if you don't have the array index, you need a way to get it from the object.

The fire is the magic. That magic is called the Hash Function. It's a way to turn something (string, number, object) into a position within an array. Every programming language has its own esoteric way to write this function. A hashmap can be terribly inefficient or blazing fast depending on its hashing function.

What does a ~~terrible~~ hashing function look like, then?

I sent this post weeks ago to +700 devs on my email list. Join here to get my tips and thoughts on algorithms and career growth. If email is not your thing, follow me on Twitter to get sneak peeks of what I'm working on.

Counting chars

Let's implement a terrible hashing function that only works for keys as strings. It'll map keys to an array of length 10. Here's how our hash function works:

Our hashing function h(x): Convert every character of string x to its numeric position in the alphabet. Sum all these numbers. Divide it by 10 and take its reminder (aka modulus %).

Sounds complex, better to show an example:

h('abc') = (1+2+3) % 10 = 6 % 10 = 6
h('carlos') = (3+1+18+12+15+19) % 10 = 68 % 10 = 8

This means that the map { carlos: 28 } will store the value 28 in the position 8 of its underlying array. Here's a more visual representation of the hashing function concept.

Free perf gains

By this point, you're sold on the concept. You understand why it's so fast and how it works internally. But, why should you care? How can you apply this concept in real life?

Let's work on an algorithm you might easily come across in your day-to-day job: Find the most common item in a list of words. For example, in the list [4,1,3,4] the most common element is '4'. There are many ways to solve this but we'll focus on 2 of them here:

For every element, find all its duplicates. Return the element that has most duplicates.
Count the occurrences of each element. Pick the element with most appearances.

The first approach requires a nested loop (for every element i, loop over all other elements j to search this item); the second approach will only need a hashmap. Let's see how they compare in terms of operations.

If you don't understand why 21 and 9 operations, think about this:

In the first approach, you visit the first item 'carlos' and then visit the rest of the items to find something similar. That is 6 visits. Then you visit the 2nd item 'edgar' and go through the remaining 4 items. That is 5 visits. Keep doing it until you're left with just 1 element, sum all the visits you pay to the numbers, and you're left with 21 operations.
In the second approach, you visit the first item 'carlos' and save it in a hashmap with value 1. Every time you find another 'carlos', you'll increment its value in the hashmap. That is, you need to go over each element just once, making it 6 visits. The hashtable ends up with 3 items, so you'll need to go over each one of these to find out which one appeared the most (max number). That sums up to 9 operations.

The larger the input, the better the perf

You might think: "that's a dumb example just to make your point, 21 vs 9 is nothing for my CPU". Let's see what happens when you have an array of 10, 20, 30, ..., 100 items.

As you can see, our algorithm performs much better when using the hashmap than when using the nested loop. Algorithms should be judged according to their performance when the input approaches infinity. In fact, the first approach runs in quadratic time O(n^2) whereas the one with the hashmap is linear O(n). That's BigO notation.

Knowledge is power. You have now an additional piece of power to make your code a bit more efficient with Hashmaps!

Keep curious

This was just an introduction to a data structure I personally find very useful and interesting (literally the best one you can ever learn). That being said, this was just the tip of the iceberg of a huge topic. There's a lot of complexity involved when dealing with hashmaps. If you feel intrigued, I invite you to keep researching the following topics:

Collision handling: 'carlos' and 'mike' both map to the same array index 8. What happens then? how do you retrieve an element if its hash collides with another key?
Load factor: What happens when the list is full? the list should grow from 10 elements to 20, how does it decide when to do it?
JavaScript may not be using Hashmaps to store objects. How does it do it, then?
Just to feed your curiosity, watch how Google built a super fast and efficient Hashmap.

Let me know on Twitter if you got some value from this post and learned something new. Be more mindful about the code you write, think about performance and the stuff underneath. Hashmaps will also help you ace a lot of interviews in your career, I've been there.

I wrote an e-book to help you

My mission is to help devs grow by posting tips to write CVs, teaching algorithms, or talking about my experience working on top remote workplaces. I wrote an ebook to help you land a job in Toptal. If that's something you're interested in, sign up here and get it in my next email.

Best sites to land top remote jobs [+$100K/year]

Carlos Roso — Fri, 19 Jun 2020 17:05:43 +0000

There are 2 ways to land remote work these days: you either apply for companies directly (or via referrals), or you go to freelancing sites and land jobs there. This last kind can be classified into 2 types:

Non-vetting platforms like Upwork, Fiverr, or Freeeup where you create an account and start applying to jobs.
Vetting platforms where you need to pass 3-4 tough engineering filters to start receiving job offers.

I'll talk about the second category here. Yes, you'll probably spend a lot of time in these interviews, but you'll likely get paid 3x or 4x compared to non-vetting platforms.

I myself have worked on some of these and can honestly say it's changed my life.

Toptal

Experience required: You're expected to be fluent in your tech stack. I'd say you need somewhere between 2-3 years of experience.
Pros: Excellent salary. Vetting for clients too. Full-time & part-time mainly.
Cons: Tough and lengthy interview process.
Interview: 4 steps: English interview, online coding assessment, live algorithms screening, take-home project. It can be heavy on algorithms.
Salary (USD/year): Frontend: 80k-120k. Backend: 70k-120k. Machine Learning: 80k-130k.
Apply here (Referral link)

CrossOver

Experience required: They have a huge variety of openings ranging from 2 years exp for junior developers to +15 years exp for high-level managers. You'll need familiarity with JavaScript, C#, C++, or Java.
Pros: Good salary. Only long term, full-time work.
Cons: They take screenshots of your machine every 10 minutes to make sure you're not on Facebook or Twitter.
Interview: 6 steps: basic fit, psychometric (CCAT: basic math and logic test), language, software questions (multiple choice), 2 free-response questions, and the final interview with a hiring manager. You have 13 days to complete.
Salary (USD/year) Junior: 30k. Mid level: 60k. Senior: 100k. Technical Manager: 100k. VP: 200k.
Apply here

TripleByte

Experience required: 2-3 years of experience and good preparation to pass the online quiz and interview.
Pros: Excellent pay. Good, well-funded startups to work for. No resume or credentials needed.
Cons: Mostly for onsite US jobs. Few offers for remote only.
Interview: 3 attempts to pass a 35 question quiz. 2 mins per question. 2-hour Skype interview afterward. Make sure you apply to "Remote only" positions.
Salary (USD/year): For remote, it can range between 100k - 190k.
Apply here (Referral link)

I sent this post weeks ago to +550 devs on my email list. Join here if you want to get my tips and thoughts on career growth.

Turing

Experience required: At least 2 years of industry experience as a software engineer.
Pros: Legit company with hires all over the world (Africa, Brasil, Pakistan)
Cons: Tough and lengthy interview process. Less than 1% accepted.
Interview: Unclear number of steps. You can easily go through algorithm tests, multiple-choice quiz for a specific tech stack, live interview with a coding task, and maybe you also need to build a take-home project.
Salary (USD/year): Based on my research, you won't probably get more than 100k/yr.
Apply here

Arc

Experience required: You'll have it pretty difficult to pass with less than 2-3 years.
Pros: Full-time and hourly jobs. Great online reviews. You can set your expected salary.
Cons: Lengthy interview process
Interview: 4 steps: Background and experience check, coding algorithms challenge, 1-1 English interview assessment, and a 2.5-hour interview with a senior dev.
Salary (USD/year) Mostly depends on your location and seniority. Here's a list with rough averages. Latin America: 70k. Africa: 60k. Asia: 65k.
Apply here

Gun.io

Experience required: Their vetting process is not hard - I'd say +1.5 years of experience is enough to apply.
Pros: Short, easy application process.
Cons: The site is not polished, lacks design, and feels buggy at times. Requires a reference from a previous employer. Mostly hourly, contract work, not full-time.
Interview: 3 step process: Reference check from a previous employer (this one is weird), 3 online algorithm challenge, video self-interview (just you and your camera).
Salary: Mostly hourly contract work. $40-$70 USD/hr.
Apply here

Prepare and ace the interview

I wrote a FREE guide with a lot of tips and tricks to ace these types of tech interviews. If you're curious, you can sign up here and get it in my next email.

You might want to save this post as I'll probably discover some more platforms in the future and update the list. Also, I normally use my Twitter to post more of these platforms as I find them.

PD: Here's some advice to write your resume and here's a short post to get you warmed up on algorithms. If you think this helps you, follow me here and stay up to date!

Can you recommend any other similar sites?

4 tricks to boost up your algorithms game

Carlos Roso — Thu, 11 Jun 2020 18:04:44 +0000

TL;DR.

Associate O(1) with table lookups and math
O(n) is for list traversal
The weird logarithm is for sorting: O(nlogn)
Connect O(n²) with nested loops

Whether you agree or not with whiteboard interviews and algorithmic questions, becoming good at this is yet another skill you should master at some point. And, to become good at algorithms, you should grasp the notion of BigO. Notice I wrote "grasp", not "master". There's nothing mystic about this topic.

BigO is simply a notation that tells you how well or bad your algorithm performs as your input size grows. I've identified some tricks I use from time to time to solve and analyze algorithms.

I sent this post weeks ago to +450 devs on my maillist. Join here if you want to get my tips and thoughts on career growth.

1. Associate O(1) with table lookups and math

Means your algorithm will take roughly the same amount of time regardless of the input size. Applies normally to math operations and object lookups.

// regardless of a or b, a sum is a math operation that takes just 
// one clock cycle to complete
const add = (a, b) => a + b;

// no matter of how big your map is (e.g an object in JavaScript), 
// a lookup will take 1 cycle to complete
const lookup = (map, key) => map[key];

You know when you access the bar prop from the foo object like foo.bar? Well, that's an O(1) operation.

Note: Hashmap lookups are considered to be O(1) in theory regardless of how they solve collisions

2. O(n) is for list traversal

Means your algorithm run time will grow linearly with the input. Take, for instance, the algorithm to find the max number of a list. Your algorithm necessarily needs to visit every element to know which number is the max. If your list grows 2x, your algorithm will roughly take twice the time to complete.

// you need to loop through all the elements to find the max.
function findMax(list) {
  let max = -Infinity;
  for (obj of list) {
    if (obj > max) max = obj
  }
}

3. The weird logarithm is for sorting: O(nlogn)

This one is easier than what it looks like. Don't worry about the weird logarithm over there. Logs in BigO notation normally means you're dividing something into halves, and each half is divided again into halves. But, the only thing you need to remember is this: O(nlogn) is mostly associated with sorting. Sorting lists are not free operations, you're incurring in costs when using them. Let's see an example of a very inefficient way to get the max of a list:

function getMax(list) {
  return list.sort((a, b) => b - a)[0]
}

O(n) is better than O(nlogn) because if you multiply 🦄 by logn, you get a bigger 🦄.

Now you have good criteria to decide what's most efficient to find a max. Would you use the O(n)? or the O(nlogn) algorithm?

4. Connect O(n²) with nested loops

Means your input size affects the algorithm like crazy (not quite as bad as others). If your input size doubles, your run time grows 4x. If your input grows 4x, your run time grows 16x. This normally takes the shape of a nested loop. Let's write a very inefficient way to find if an array has a duplicate.

function hasDuplicates(list) {
  for (let [i, el_i] of list.entries()) {
    for (let [j, el_j] of list.entries()) {
      if (i !== j && el_i === el_j) return true;
    }
  }
  return false;
}

For every element in the list of size n, we're looping over the whole list of size n. That means we're visiting the elements n*n = n² times.

Can you come up with an O(n) algorithm for this task? one that only loops through the list once? let me know in the comments

Summary

No need to dig into this topic if you're against learning algorithms, I can respect that. Just save this table and know that some tasks cost more than others and why.

Others

There are all kinds of complexities and nuances on this topic. You're free to keep researching. But, if you can grasp these 4 concepts and stick them to heart, you'll level up your algorithms game for interviews, PR reviews, or just to write better code.

Don't fear coding interviews

I've used these concepts to get better at coding algorithms. I've since landed interviews (and job offers) at Amazon, Toptal and a few more top remote work platforms. I wrote a FREE guide with a lot of tips and tricks to ace remote tech interviews. If you're curious, you can sign up here and get it in my next email.

My DMs on Twitter are always open to help you on your career, algorithm interviews, resume questions, or growth tips. Shoot me a message or just say hi!

Resume Pro Tip: The absolute best way to show your work experience

Carlos Roso — Wed, 03 Jun 2020 16:37:50 +0000

Say you're a recruiter and you're reading the "Work experience" section of a candidate's resume.

Which of the following bullets sounds like a more impressive statement for you?

Spent dozens of hours writing blog posts about Go and Kubernetes.
Reached +20k visits (aggregate reading time +100 hours) in technical posts on Go and Kubernetes.

What about this one?

Created presentations based on data for company stakeholders.
Helped stakeholders take decisions worth +50k USD by analyzing big data (+2000GB) and building reports in PowerBI.

I personally find alternative #2 to be more engaging and interesting. As a recruiter, I will easily remember the girl with experience mangling +2TB of data or the dude with a ton of views on his blog. But, why does it work?

Note: if you still think there's no difference, that's fine. This is just an opinionated approach that has worked for me (see the section below).

I sent this post weeks ago to +400 devs on my maillist. Join here if you want to get my tips and thoughts on career growth.

Stick to these 2 rules

Having a strong resume helped me land interviews at Amazon, Toptal, Crossover, and many more top remote work platforms. I credit most of my CV success to the way I showcase my work experience. Let's see how it works.

The trick here is to follow 2 simple rules:

Use the format "Accomplished X by implementing Y".
Show numbers.

Note: Credits goes to Gayle L. McDowell as I took inspiration from her book Cracking the Coding Interview.

1. Show your accomplishments

If you find it hard to remember two rules, then stick to this one: don't tell me what you did, tell me what you accomplished.

Writing Angular apps, PHP backends or wiring Firebase APIs are very common things in our industry. Every dev goes through that eventually. It's not what you did but rather what you achieved, what really sets you apart from the crowd.

2. Show numbers

If a bullet in your work experience was a title for a blog post, would you read it? When you think about it that way, you realize how important numbers are. The use of numbers has proven to be highly effective when engaging with your audience; your audience just happens to be your recruiter.

If you don't have numbers to show on your resume you're not thinking deep enough. Remember that time when you integrated OAuth in your app? Can you recall any conversion increase? Use that number here. Did you create an architecture guide to create React apps in your company? how many discussions do you think that document helped reduce? I'd say more than 3x. Use that metric in this section.

If you definitely don't have any metric, then start measuring today! Coding is just a means to an end, and that end can surely be measured.

Examples

I partnered with my friend and Google Dev Expert, Juan, to review resumes from the community. After reviewing several of these and giving a lot of advice, I gathered a handful of examples that you can use as a guideline to improve your CV today.

// Detect dark theme var iframe = document.getElementById('tweet-1248958395819921408-301'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1248958395819921408&theme=dark" }

Keep in mind these are real-life examples of real-life devs.

Frontend Dev

Helped +20 customers evaluate ideas in record time by building fast UI prototypes in Angular. This resulted in a time-to-market reduction of 400%.
Improved loading time in 5x by using advanced web performance techniques for Angular (tree shaking, lazy loading, custom Webpack configuration).

Backend Dev

Reduced deploy time 70% by implementing a CI/CD Jenkins pipeline which helped product managers validate features 2x faster.
Helped customers run through data 2x faster by implementing paginated API responses in RoR and JavaScript.

Data Science, Tech lead, Dev advocate

Read more examples in the original blog post on my site.

I hope you got some inspiration and learned something new. Remember, when it comes to showing off work experience, it's not so much about what you did, but about what you accomplished.

If you liked this, you might want to get more advice on what not to do in your resume. You can also ping me anytime on Twitter, I can take a look at your resume and give feedback (if I'm not super busy at the time).

Let me know in the comments, what other strategies do you use to show your work experience? what has or hasn't worked so far?

Acing that tech interview

I've used this technique to land interviews (and job offers) at Amazon, Toptal and a few more top remote work platforms. I wrote a FREE guide with a lot of tips and tricks to ace remote tech interviews. If you're curious, you can sign up here and get it in my next email.

You're the worst developer I know

Carlos Roso — Fri, 29 May 2020 21:32:39 +0000

You're the worst developer I know because you don't listen. You trash the juniors and don't accept feedback. You don't trust women in your team. You think you're a 10x engineer and make no effort to help grow your peers. You don't teach what you know, always gatekeeping everything to yourself.

You're the worst developer I know because you criticize every open source project but you have never made anything yourself - your ego won't allow you. You think you're superior because I do frontend and you do backend. You don't take anyone seriously when you find out they don't have a CS degree.

You're the worst developer I know because you never say thanks, never say please, never say hi, never say bye. You're proficient and excellent technically, but it's a nightmare to work with you. You do not reply to my questions when you don't know the answer; you'd rather google them and then come back to me as if you knew it all.

You're the worst developer I know because you think you deserve better just for working ridiculously long hours. You don't have an opinion but you mainsplain every other woman on Twitter. You hold on to your past success to call everyone on their mistakes. You never accept help even when you need it.

You're the worst developer I know because you trash my solutions for being too simple but you never finish your overkill proposals. You overengineer everything and call my code as not so clean. You can't say I'm right, you can't say you're wrong. You trash managers on their back, always have done so.

You're the worst developer I know because you don't inspire, you're just too negative, every single time. You force-push updates to my PRs with no feedback whatsoever. You're so perfectionist we barely release anything, even when the project needs it. You're too negative, you're so defensive, you're intimidating more than welcoming.

Carlos, this is for your future self. Save this, come back every now and then, and make sure you don't turn into the worst developer you know.

#tbt give some love to your old projects

Carlos Roso — Thu, 21 May 2020 19:04:25 +0000

It's Thursday! let's all share an old project we're all proud of. It can be a GitHub repo, side project, whatever.

Deploying frontend applications — the fun way

Carlos Roso — Thu, 21 May 2020 11:23:34 +0000

In this post, I will show you how I deploy my frontend applications using GitHub, Jenkins, Docker and Digital Ocean. I had some doubts through my learning journey so I decided to put up what I learned on this post as a self note.

Note: This post is not intended for you my friend, expert, and consultant guru 15+ years exp DevOps architect; this is for those of us who are just starting to discover the beauty of CI/CD tech. This post may contain some bad practices, please take it with a grain of salt.

Cut the cr#p, shoot me the TL;DR

You’re like me, you skim around and grab the bullets, you leave. Here’s the TL;DR for you:

Spin up 2 servers with Docker installed: build and production servers
Install Jenkins (or any other CI) in your build server
Create a job in your CI that clones, installs and builds your project in a docker image
Set up webhooks in GitHub to fire the job on every push
Push the docker image to your personal Docker Hub
SSH into your production server
Pull the image from Docker Hub and run the container
Profit

Docker based continuous deployment workflow

Thanks for reading.

Hopefully, I caught your attention and you want more details now. In the following paragraphs, I will outline my thought process and explain how my deployment pipeline works. I won’t go deep into technical details but will instead put up some useful links for your further research.

The problem

Simple: I developed a TypeScript AST interactive viewer in Angular and I wanted to deploy it.

TypeScript AST Interactive Viewer

Bu… but, why not use Firebase, Google Engine, vanilla FTP, GitHub pages? you know, like “one-click deploys” duh, you may ask. All those tools work great, but most of them are either too expensive or just felt too magical (nothing tops “gcloud app deploy”) and are not that fun to learn! I wanted to understand, automate, and have full control of the whole deployment process. I wanted a challenge, I wanted to learn, I wanted to have fun (hell I’m inspired).

What it all comes down to

I set up my own challenge which looked like this:

I want to push code and have it deployed automatically — aka Continuous Delivery.
I want to pay a cheap hosting service

Let’s draw these non-functional requirements in a black box diagram:

Problem illustration. From GitHub to Live App. Icon: magic by ✦ Shmidt Sergey ✦ from the Noun Project

Unraveling the Magic box

I’ll divide this chapter into three parts. Each part will reveal one small portion of my Magic box:

From GitHub to Magic
Developing the Magic
From Magic to Live App

1. From GitHub to Magic

Push code, sit and relax, refresh the live app, profit. That’s all I wanted.

Choosing my VPS (Virtual Private Server)

The first step was then to set up a server that could grab my code from GitHub and execute a series of commands (npm i && npm run build). Not quite sure what to do next, but I knew I had to start from there.

After reading about the best VPS providers out there, I finally went with Digital Ocean. Great tutorials, easy for newcomers, decent DNS management, and good pricing — was a no-brainer.

CI tools everywhere

After signing up, I knew I needed some sort of tool that let me grab the code and automate the build process — the CI tool (Continuous Integration). There are several of them out there, some of them targeted for open source projects, some primarily designed to be self-hosted, some premium, some free. I chose Jenkins mainly for its concept of Pipelines and because I had some familiarity with the tool.

Reading through some tutorials, it was relatively easy to get my Jenkins instance up and running. Now I needed to tell Jenkins to grab my code whenever I git pushed. Turns out there are dozens of posts out there on how to set up a GitHub webhook pointing from your repo to your Jenkins Droplet IP. Setting this up was faster than I expected (not quite straightforward for private GitHub repos, though).

Let’s recap

At this point, I have a DO droplet running Linux with a Jenkins instance pulling code from GitHub on every git push. How cool, huh? Let’s see how our Magic box starts to reveal itself:

Black box diagram with Digital Ocean Droplet and Jenkins

Useful links:

2. Developing the magic

In the next few paragraphs, I’ll develop the core of my strategy which leverages Docker and DO droplets. Let’s dive right in.

Dockerize all the things

At this point, I have a dist folder with an index.html and its dependencies, ready to go. I know I need to spin up a webserver to serve these files over the web. Let’s then install nginx (or Apache) in the same server and serve the thing. I also need to install Node and a couple of global node packages. Easy peasy, let’s do that…

“But wait, Carlos, that hmmm… that doesn’t feel like the right thing to do — you’d end up with a ton of stuff installed on your server and managing your dependencies will be a hell later on… just saying, though” — Inner self

Indeed, I needed a way to encapsulate the dependencies, the dist artifact, and even the web server so that it wouldn’t mess up my server. Let’s use Docker. It would let me build an image with my webserver running on a port on my server, and my server filesystem would barely notice what I just did. How cool, huh?

I set up a Dockerfile for my app and edited the job in Jenkins to build a docker image and run the container with the 80 port exposed. It worked like charm. I could access my app live from http://my.server.ip.

On scaling and stuff

I planned to have many applications deployed with this same schema using the same server. It wouldn’t make sense then to run Jenkins and all my containers on the same server. It just felt like I could do much better — I wanted to separate concerns. Sure I can juggle with different users, having Jenkins living in its own user, etc, but something within me really wanted to keep a machine specifically for building my applications.

Based on this premise, I created another droplet (aka server) with less memory (no heavy lifting, just to serve web apps) and with Docker installed as it should be able to run Docker containers. I would then run all my apps on this server. This would let me scale well because I could easily change the memory allocation on my build server while leaving my apps untouched.

Let’s recap

We’ve made quite good progress. We’ve settled for Docker as our core build mechanism and we also decided to separate concerns in favor of maintainability by spinning up a separate production server in another server.

Deployment workflow with Docker and 2 DO droplets

Useful links

How to Dockerize Angular, React and Vue apps.
How to install Docker in Ubuntu.

3. From Magic to Live App

I wasn’t sure how to integrate my servers (build + prod). After asking for help and researching, I came to the conclusion that, for my particular use case, I could implement the following workflow:

Build the docker image in the Build Server
Push the docker image to my Docker Hub
Log in to my prod server via SSH
Pull the image from the Docker Hub and run the container

It made sense as I didn’t have to resort to using tools like docker-machine or Kubernetes to orchestrate my servers. It just works, it’s simple and it looks clean enough for me.

Note on security: It’s recommended to disable password-based authentication on your production server and enable only key based authentication from your build server. That is, it will be virtually impossible to log in to your prod server if not from your build server.

Show me some code

A technical post is not a technical post until you show some code. Let’s see what the Jenkins pipeline looks like in the CI when integrating the whole thing:

#!/usr/bin/env groovy

node {
  def app

  stage("Clone") {
    git 'https://github.com/caroso1222/ast-viewer.git'
  }

  stage("Build") {
    app = docker.build("caroso1222/ts-ast-viewer")
  }

  stage("Push") {
    docker.withRegistry("https://registry.hub.docker.com", "docker-hub-credentials") {
      app.push("${env.BUILD_ID}")
      app.push("latest")
    }
  }

  stage("Deploy") {
    sh "ssh root@my.server.ip \"docker stop ast_0 && \
        docker rm ast_0 && \
        docker pull caroso1222/ts-ast-viewer:latest && \
        docker run -d --name=ast_0 -p 8080:80 caroso1222/ts-ast-viewer:latest\""
  }
}

I’ve labeled some lines in the snippet, let’s go through them real quick:

Build a docker image based on the Dockerfile.
Push the docker image to my Docker Hub account.
SSH into the production server
Pull the image from my Docker Hub
Run the container from the image we just pulled. I run the container on port 8080, but that’s because I set up Nginx to route the traffic to several containers in the same server via subdomain proxy_pass (e.g. domainA.com serves container A, domainB.com serves container B). I won’t elaborate on this technique as it falls out of the scope of this post.

As stated at the beginning of this post, this pipeline runs on every git push made in master. The following image shows what happens on Jenkins for every deployment. By the way, I love this image as it depicts what the challenge looked like in my head before diving in.

Stage view of the Jenkins pipeline. Each line represents a deployment triggered by a git push.

Let’s wrap up

We finally made it. We have unraveled our black box. Every secret has been revealed and we have been able to cover each one of its components. Let’s take a look at what our final deployment workflow looks like now!

Diagram of the full deployment strategy covered in this post. A Docker image is built in the build server, goes through the Docker Hub and finally made it to the production server.

Useful links

Conclusion

There are tons of deployment strategies out there, each of them with its pros and cons, and each one relying on a different stack with its own taste. That’s the beauty of it. In this post, I covered just one of these strategies that grant me full control over my custom deployment pipeline using two servers, a CI, and Docker.

It all might sound daunting if you’re not very familiar with the concepts we covered. Fear not, I say. It’s a long post mainly because it sums up a learning journey that spanned across almost 3 months, putting 1–2 hours each night grinding on these servers and reading stuff I was not very familiar with.

Even if you’re a FrontEnd developer focused on browser-land, I still think it’s very valuable that you get familiar with the full stack. It will give you the tools to have a solid conversation and form an opinion when discussing DevOps stuff in your company. It’s better to say “you guys are the experts, but this is my opinion on the matter…” *than saying “*well, that’s not my thing, you ops guys figure it out”.

I hope you got some inspiration to go ahead and implement your personal deployment pipeline and get to know all this DevOps tech — tons of fun ahead!

Shameless self-promotion

I’m not an amateur SoundCloud rapper nor I’m looking for funds in Patreon. I just help devs get jobs at top remote platforms like Toptal. I write about career growth, tips for interviewing, fun CSS stuff and put up some discussions here in DEV from time to time.

Now I'm writing a FREE guide with a lot of tips and tricks to ace remote tech interviews. If you're curious, you can sign up on the waitlist here and be the first to get it.

Find me on Twitter @caroso1222 and don’t forget to say hi!

What do you look for in a PR review?

Carlos Roso — Mon, 18 May 2020 21:17:47 +0000

What are you strict about when reviewing code? What do you always point out in your peer reviews?