Hi! We’re Toptal, we help developers get jobs they can do from anywhere. AUA!

Hey Casey,

Honestly, half the reason I helped start Toptal was because as a freelance engineer paying my way through an expensive university, I wasn’t getting paid for half the stuff I was doing. Marketing myself, getting deal-flow, doing estimations, RFPs, invoicing, taxes, etc. was all a significant time sink, and I never got paid for any of it. Even though I had some great clients, at the end of the day, my hourly rate could easily be divided by 2 if I included all of the hours that went into actually getting every dollar into my bank account.

Obviously I’m not impartial, but the best thing you can do as a freelance software engineer looking for stability is to join Toptal. You want deal-flow, to be paid for the time you work (on projects that are actually interesting), and to skip the sales fluff? The Toptal network pools its resources and spends millions of dollars a year to make sure everyone here can do exactly that. Many Toptalers are engineers who have left Silicon Valley to pursue their dreams of travel (while leveraging a Bay Area income), and deal-flow + stability are some of the biggest reasons they are here. Of course they can get clients themselves. But why spend the time or risk the hassle when they can ping a Toptal Director of Engineering and often get an interview with a new client whenever they want something new?

To answer your question more directly, however, I do have some pointers for getting hired/closing business as a freelance engineer. These things worked well for me:

1. Act like a core team member from the very first interview. Do not act like a transactional freelancer. Go above and beyond, think medium- and long-term in addition to short-, and figure out what true north means for your potential colleagues and also what value system is important to them for getting there. If you realize they don’t have the same first principles or true north across their team, tell them.
2. Think twice. Code once.
3. Explain things simply and clearly. Provide the context your client needs in order to understand your answer. If you are not able to do this (meaning he still doesn’t understand), realize that’s your problem, not his. You need practice making complex things simple.
4. Be available and communicative. I remember winning several deals because the client had a question about my RFP or something I said in the interview. It was late when they pinged me, but I took the time to either 1) respond with the best answer I could, or, 2) immediately let them know I got their message, and I would respond at a certain time.
5. Inform potential clients that you will tell them when they are wrong. And then do it. Everyone has worked with a yes man. Your client doesn’t want that. Or if they do, you don’t want them as a client.

Does that help?

Best,
Breanden

Hi Xiufen,

You definitely don’t need a degree to be a good or financially successful developer. I think one good approach aspiring developers can take right now is:

1. Start building something. Anything. Ping a developer friend and get her to help you set up an environment and crash you through the very basics. Pick a language (Python/Java/Ruby/Mathematica/etc), and buy a highly rated book on it. Read the whole thing and do every example. Go to Codecademy, and do every course they have on your language. Search Google for tutorials on your language (and get used to Googling any time you get stuck). Join StackOverflow/Quora and ask/follow questions about your language.
2. Join a bootcamp program like General Assembly or Hack Reactor.
3. Keep building something. Anything.
4. Dive into Open Source. Start by helping on tasks like documentation, helping organize issue lists, etc…this will force you to be around great developers and read their code, which is a great way to learn. Most Open Source projects have amazing contributors that won’t mind pairing with you to teach and get you going quickly.
5. Keep building something. Anything.
6. After that, you can start working as a junior developer either at a company or as a freelancer.
7. Keep building something. Anything.
8. Teach other people every chance you get. Explain what you’re doing to your boyfriend/girlfriend. Research and answer questions on StackOverflow/Quora. Write blog posts and tutorials for the things you’ve just figured out.
9. Keep building something. Anything.
10. Surround yourself with senior developers and constantly ask “why?”, not just “how?”.

After a year or two, you will be on your way to becoming a good developer, and you will get clients

Best,
Breanden

Hi Pilcrow,

The short answer is: there is always a way for you to create value (financial, educational, and social) for yourself at Toptal. As a Toptal engineer, if you are ever in the position where you feel like you are out of options, that means I am failing, and you should yell at me immediately—my skype is smsprep. While there is no guarantee of client work, we do work very hard and invest a lot of resources to ensure that anyone in Toptal who is looking for an engagement has multiple good options at all times. There are always many new positions open (Scala/Play/Akka > Java), but ultimately it does come down to whether or not you are a match for any specific client/project, and of course it helps if you can be flexible in terms of your availability (full-time, part-time, hourly, possibly on slightly different time zones, etc.).

Another important point is that, as a Toptaler, you’ll have free access to a lot of Toptal resources like Udemy, Pluralsight, conferences, misc events, etc., and you’ll have ways to earn significant money by working with us directly whenever you choose.

Does that answer your question?

Best,
Breanden

Hi Nemrut,

We started Toptal six months before I finished university—proper dorm room style in about 400 square feet. By the time I graduated, I think our run rate was nearing $1M/year, so we had some traction before I picked up and started traveling. We did raise a little bit of money (about $1.4M from a16z and a few others) for strategic and stability reasons, but our initial traction came from our network (Taso and I were both developers and we knew a lot of people in Startupland) and our endless hunger (Taso and I are both the kinds of people who need things to be accelerating forward at all times or we freak out). When you combine a good network with that kind of drive, you can make a lot happen.

Best,
Breanden

You can freelance as a non-US citizen working outside the US for a US company. You just complete a W8 to prove you’re not a US taxpayer, and then you’re responsible for paying your taxes in your home country. Your US company may actually have a hard time getting you your money when the time comes, and you’ll probably be frustrated by that process and the many fees different services (like your banks) take, but you can definitely do it.

Hey Marcus,

What changed in the 5 years since you started the company?

Wifi, 3G/4G coverage, and data plans have changed a lot. It’s significantly easier (and cheaper) to have internet everywhere now, and it used to be a pita. In February, for example, I was in Svalbard (essentially the North Pole), and the wifi was faster than in SF. Outside, you couldn’t take your phone out of your pocket, because it was -40C, and it would freeze in seconds, but inside the wifi/4G was like lightning. I’ve started using ATT’s Passport plan as a backup wherever I go, and it’s simplified my life a lot.

Do you see a development in the amount of people who want to work location independent?

The numbers are surging. You’re telling me I can travel, have an awesome life, make money, build big things, work with smart people… all while I’m young? Badass. I’m in.

However, what I’m starting to see from people a bit now (including myself at times) is nomadic life post honeymoon period. There are very real risks associated with it that can sneak up subtly. Isolation, loneliness, impatience, restlessness, and even depression are all things people should to be aware of, and the movement will eventually have to figure out real solutions here. I plan on writing more about this topic in the near future.

How do you structure your team calls? Are they gathered in one timezone like Automattic is doing or do you have another setup?

We try to have very few of them. We’re not big fans of meetings. Every team here has a call on Monday where they sync up, and the rest of the week is meant for one-on-ones and on-the-fly Skype calls where you pull in the people you need to in order to get things done. In general, most of the company operates on a loose UTC−05:00 time zone and is surprisingly available regardless of the time.

Thanks!
Breanden

Hey Divraj,

Many Toptalers work here exclusively, but it’s not a requirement. Some have day jobs at big tech companies, other have their own freelance clients, and others have their own start-ups.

Toptal is in India! We don’t have a large presence there yet, but I know several Indian Toptalers.

Best,
Breanden

Hi Flowen,

Answering your questions in order

Do you find there is still a lot of resistance to remote developers? Personally when I ask my former employees and clients they don’t really like the idea that they’re not able to work in the same timezone.

Yes, every day! I wrote a post about this topic here: http://qr.ae/pvi0V, but for us it comes down to helping people understand that:

• A good remote developer is better than a bad local developer.
• A great remote developer is better than a good local developer.
• A top developer is a top developer regardless of where they are.

How do you match developers with employees? Or wait… I just made an assumption, are your clients usually looking for fulltime developers or is there also a lot of freelancing going on?

We are a network of freelance software engineers, so virtually everything we do is freelance For matching, we have a core team of very senior engineers here who sit down with clients and help them choose the best fits for every project/position they have.

how did you create the top3% test? I haven’t done it myself, but I just wonder how you came up with those numbers (26,7%, etc) and questions.

It wasn’t arbitrary. We didn’t start by saying, “wow, we should set the acceptance rate at 3%, because that sounds nice” or we somehow knew that the bottom 97% were bad. 3% (and every value you see on our screening process) is simply the result of a numerator and a denominator (successful_applicants over all_applicants). We designed the process to be the bare minimum criteria for us to be extremely confident that we are admitting someone into the network who will thrive here. We’re engineers ourselves, and we look for great problem solvers with personality and drive — the types of people we want to work with (and learn from) ourselves.

Thanks!
Breanden

Hi Tom,

Thanks for your message. Before I answer, I really want to clarify that ‘3% get accepted’ is not a policy. While “top 3%” sounds sexy, for us, it is simply the result of a numerator and a denominator which are successful_applicants over all_applicants and our process, which is designed to make sure anyone who passes is very smart and will thrive here. Sorry to diverge, but I see a lot of copycats changing their taglines to “the top X%”, and as an engineer, seeing arbitrary numbers like that makes me cringe

To answer your question: We do cover aspects of effective remote working during our screenings (esp during the test projects), and we have a very active internal community + blog where people share knowledge and learn from each other, but we do limited formal training here outside of making the communication and availability expectations very clear. I would really like to hear about your direct experience here, though, to see if we can perhaps do something even better.

Please email me at [email protected] any time.

Breanden

Hey Pieter,

Tackling your questions in order

What do you recommend to developers that are working for fixed companies now that would like to become nomads and work remotely?

Practice communication (in English - both written and verbal) until you are excellent if you are not already. There are plenty of sites like Livemocha.com for this, and communication is one of the most important parts of working remotely. In fact, I think being responsive, clear, and communicative as a remote developer is almost as important as your technical skill. Get used to over-communicating and chatting to people online and constantly being available even if you aren’t sitting at your computer doing heads down work. It goes a long way with clients. Leaving Skype on all the time and replying to emails at odd hours (even if you’re on a train, standing in line for an event, etc.) takes some getting used to. You don’t always need to be working, but you need to be responsive even if it’s just to say, “Hey I’m grabbing some food real quick, but I got your email, and I’ll push in a few minutes when I get back."

What skills should they focus on to get hired remotely (e.g. at Toptal), are those skills any different from general developer skills? If so, in what way?

Again, proactive communication and responsiveness. At Toptal, we’re almost all engineers, and we look for great problem solvers with personality and drive. To us, that’s the very definition of an engineer. But when it comes to who really kills it at our company, it’s the tremendous problem solvers who are proactive and communicative. When you’re remote, clear expectations and communication are lifeblood.

Imagine two different developers:

Person A is smart, sociable, and you always know what she’s working on. In fact, because you guys communicate so well, you could be in two separate rooms yet have the same answers to questions like: 1) What are you working on now and why? 2) What were you working on yesterday and why? 3) What will you be working on tomorrow and why?

Person B is also smart and friendly enough, but you don’t always get the updates you’d expect, and maybe days go by where you only vaguely know what she’s working on (“refactoring…” or “back-end work mostly…” etc.). Eventually cycle times are extended due to communication delays, and problems that could have been resolved in a few seconds get incorporated into code and product simply because you weren’t asked about them when they arose.

Who are you going to hire again? Who are you going to tell your friends they should hire?

Toptal started 5 years ago, back then remote work was even less fashionable than it is now (getting slowly fashionable recently stuck_out_tongue), what made you and Taso decide to run the company remotely AND focus so much on getting the developers you hire/place to do the same? Why?

Pasting an excerpt from an article I wrote the other day

We could have gone to San Francisco, set up shop, raised many rounds, and pursued Toptal in the typical Valley way. But of course when Taso and I started all this, I was still in class, and everything had to happen virtually. Taso didn’t live in Princeton, and I didn’t have time to commute to NYC or SF for meetings every day. So, using Skype as our office, we said from day one we would be distributed (meaning we would be working from anywhere but a central office), and we proceeded to “meet” people and companies all over the world using our computers. And instead of having two or three in-person meetings a day, we could do ten or twenty virtually with people who were located anywhere. We didn’t lose any time for commutes, and we avoided all of the costs associated with them. No one stared at clocks, and no one wore a suit.

While working like this, we realized that we didn’t need to physically be in Silicon Valley for Toptal to take off, and this opened up a world of possibilities—literally. Taso and I are adventurous people, so we began talking about cool places we could go that were also economically strategic so we could reinvest as much as possible back into growing the business and skip funding rounds in the meantime. We quickly set our sights on Budapest, as one does. It was significantly cheaper than San Francisco, and, to us, it was significantly more fun.

As we grew in Budapest, we further embraced the freedom of not having a physical office. We traveled to dozens of nearby countries and met hundreds of incredible people—from Topcoders to Prime Ministers to CERN researchers to infamous hackers—often in the places we’d least expect. Soon our core team members were operating from Russia, Brazil, and Argentina, and with our team’s coverage map widening every day, Toptal began to grow organically in that same way. We were able to practice what we preached—working remotely—and because we were entirely distributed and that was never a question, we figured out how to have our cake and eat it too. We had the freedom to hire talent wherever we went and build local Toptal communities in every country we visited.

And the question I always ask…Is this the future?

Of course. Staring at a clock in an office sucks, and as Tom Preston-Werner (CEO of GitHub) said, “If you do not have a distributed team you are, by definition, not working with the most talented people.”

Cheers,
Breanden