The freeCodeCamp Podcast

In this episode, Alex, a Romanian developer, tells the tale of how he and his friends grew their small side project into a $17,000 a month business. In the beginning, they were coding in a Starbucks. Now their team has grown, they've sponsored 20 hackathons around the world, and business is booming. Here's their story.

Written by Alexandru Paduraru: http://twitter.com/axelut

Read by Quincy Larson: https://twitter.com/ossia

Original article: https://fcc.im/2F5yfQX

Learn to code for free at: https://www.freecodecamp.org

Intro music by Vangough: https://fcc.im/2APOG02

Transcript: 

In 2014, my friends and I set out to build the best possible web design tools. We built UI kits, Admin Dashboards, Templates, and Plugins. We’ve always tried to create products that are helpful in the development process, and that we ourselves would use for building websites for clients.

From a revenue’s perspective, if we don’t take into consideration the Black Friday sales (which doubled the amount that we made in November 2016), we are grossing around $22,000 per month. Part of that goes toward paying our affiliates’ commissions, collected VAT, payment vendors’ taxes, and other expenses. We end up netting around $17,000 each month.

In this case study, I’ll share exactly how we built our products and grew our business. You’ll hear all about:

What motivated us to start our startup, Creative Tim, and how we built our initial product

How we got our first users

Marketing strategies we used to grow

How our business model works

The story behind our revenue sources

Biggest lessons we’ve learned so far

1. What motivated us to get started with Creative Tim and how we built the initial product

We started out as a two-person agency in Romania with no funding from third parties. We didn’t have enough cash to rent an office — even desks at a co-working space —so we just worked out of a Starbucks. We were barely able to pay our daily living expenses by doing work for clients.

Creative Tim was a side project that we thought would come in handy to web developers like ourselves. We noticed that we were always “reinventing the wheel” when working with clients, and creating the same items over and over again for their websites. So we wanted to create a few standard components, like login and register modals, calendars, wizards, headers, and footers.

Over the span of a few months, we dedicated our time to implementing the platform and a few freebies (alongside the agency work). In the beginning, we didn’t have any Twitter followers, Facebook fans, or email list subscribers. We posted a lot of stuff about our freebies on various design forums and we used the “stalk web developers on Twitter” technique to spread the word about our products.

2. How we got our first users

At first, nobody really understood what we wanted to do. They didn’t understand the value we could provide by helping them improve their businesses. We decided that it would be better to create a more complex product that would help people understand what we were doing 🤔

We launched the Get Shit Done Kit, a UI Kit based on Bootstrap. It was featured on Designer News, and it was quite popular. We got over 11,000 users from that source, which was a huge spike for our business.

Then two weeks later our startup was featured on Product Hunt. That gave us another spike with over 5,000 users. After that, the situation was stable, and we graduated from 0 users/week to a consistent 2,000 to 3,000 users/week.

A couple of months later, motivated by the success of free Get Shit Done Kit, we released Get Shit Done Kit PRO the premium version of GSDK, with more components and ready-to-use example pages.

Initially, we only made a few sales. The product was generating about $200/week, which was not nearly enough to sustain our business. At the same time we were working on a web project for one of our clients.

Then in December, we got published on Bootstrap Expo, the most popular gallery for showcasing websites created with Bootstrap. This was another important spike for our business. Since all of the people who go to Bootstrap Expo for inspiration already know Bootstrap or have previously worked with it, they were the perfect audience for our business.

Later, we discovered that getting traffic on your website is not enough to create a long term relationship with your users, and most of them forgot all about us after their first interaction. We did some research and discovered what most marketers probably already know: people forget things that they aren’t reminded of. Then we implemented the “Remember us email system” following the rules from the forgetting curve.

We wanted to give our users a reminder that we still existed and that we’re a valuable resource for their projects or their clients’ projects.

Currently, we send emails at the following schedule:

After 3 days from their first download, we send an email with other recommended products.

On day 10 we send an email requesting feedback and asking if they need help.

On day 15 we remind them that they can upgrade to PRO.

On day 30 we ask them again for feedback and offer to promote something they’ve built in our gallery and social media.

We send a final reminder on day 60.

3. Marketing strategies we used to grow

Most of our marketing strategies consisted of submitting our content to different communities like Reddit, Product Hunt, Designer News, Hacker News, and GitHub. Some important subreddits that work well in our area include /r/web_design, /r/html5, /r/frontend, and /r/webdev.

We also paid between $100–200 for newsletter campaigns a couple of times. Even though the ROI ratio matched the amount we invested, the campaigns did not meet the expectations. (Maybe this was just in our case, that wasn’t profitable and it works better for others.)

Then we paid $400 for Get Shit Done Kit PRO to appear in the Sidebar.io newsletter, a curated list of the 5 best design links made by Sacha Greif. This was a very rewarding newsletter for us, generating about $1,500 in sales.

Then we purchased the “Review + Newsletter” package ($550) from eWebDesign. There were about 5,000 users who participated in the giveaway, and the total sales amounted $2,800.

We also thought about different places where we could find web developers who could use our products, and we realized that hackathons were exactly what we needed.

Presenting how our tools can help during the Hackathon

Subsequently we started talking to people that were organizing hackathons to offer them free licenses for our “premium products.” We sponsored over 20 hackathons in different cities around the world (you can check them here).

All the developers were happy to get free licenses, which made us happy that we could help them create better projects faster and they also found out who we are, so a win-win situation.

Critically, being physically present at some of the hackathons also gave us a lot of information about how the developers were using our products and how we could improve them in order to make them more user-friendly.

In March 2015, we finished the agency’s contracts and we switched from “Agency mode” to “Startup mode.” With some revenue in the bank and a few monthly sales, our team moved to working full time for our startup. As we put everything together and constantly launched new products, our sources of traffic and revenue grew.

4. How the business model works

We realized that the best business model for Creative Tim was freemium: we create high quality freebies that help web developers build great websites, then release the PRO versions for those freebies, which contain more elements, sections, plugins, and example pages.

At this moment, we have 8 premium products, each of which have their own freebies. Their prices range from $19 to $599, depending on the license and archive type (HTML, HTML + PSD, HTML + Sketch). The freebies appear everywhere on different communities, blog posts, newsletters, and social websites — and they are driving all of our traffic.

Our business model: create high quality freebies that help web developers build great websites, then release the PRO versions for those freebies which contain more elements. 👌🏼

The basic idea is that those freebies are always appearing on top 10 lists in these big communities. Each post that’s in the top 10 (depending on how big is the community) gives us between 1,000 and 15,000 targeted users in one day. You can imagine how much that would cost if you wanted to do a regular targeted marketing campaign. 😮

Some examples:

Paper Kit — 380 upvotes on Reddit

Material Kit — 560 upvotes on Reddit

Light Bootstrap Dashboard Angular — 210 upvotes on Reddit

Material Kit — 180 uvpotes on Hacker News (peak position 9 with over 14,000 users coming to our website in 1 day)

Material Kit — 860 upvotes on Product Hunt

etc… you got the idea

5. The story behind our revenue sources

Direct Product Sales

Here we have the regular sales that are done on our website, which are worth about 24% of our overall sales. This doesn’t include the Big Bundle.

What is this Big Bundle, and how did we create it? We noticed that some of our users were downloading all our free products. (When I say all, I literally mean all of them in about 2–3 minutes after they have created an account.) We also noticed that some of our clients were purchasing all the products that were premium.

So we decided to test a new product called the “Big Bundle” which gives you access to all our products with huge discounts (over 60%). This big package was getting around 6–8 purchases per month. Since the prices for this Big Bundle is $299 (instead of $500) for the personal license and $669 (instead of $2,127) for the developer license, it’s a good source of revenue and a great deal for the web designers and agencies who are using our products for multiple clients. It’s a win-win situation.

Affiliates Sales

We’ve created an affiliate network, and our affiliates are very happy because they get 50% to themselves from each transaction. For example, one of our most important affiliations is done through a very popular GitHub Repo: Bootstrap Material Design (17,000+ stars on GitHub). Currently, affiliates account for around 25% of our overall revenue.

Organic Search (SEO)

We saw that we were also getting around 22% of our revenue from SEO. So we decided to invest more in SEO, we brought on an SEO consultant, whom we pay around $500/month to improve our products’ ranks in Google.

Other revenue

The remainder of our monthly revenue comes from Facebook, Twitter, and our newsletter. Here’s how our revenue has evolved over time, along with some historically important moments, so you can understand why it has grown in some months:

6. The biggest lessons we’ve learned so far

It sounds cliché, but having a great product is crucial.

A lot of founders really struggle trying to market and sell something that people don’t want or don’t need. If your product is crap, there is no marketing strategy — and no source of investment — that can keep it alive for long.

At the moment, our products are used by over 134,000 web developers around the world. We have people from Microsoft, Ubisoft, Vodafone, Orange, Harvard University, Stanford University, and governmental institutions downloading and using them as different internal tools, and we’ve sponsored more than 20 global hackathons from 14 countries.

Don’t look to be the next Facebook. Try to solve a real problem instead.

Every step in our development seemed like the natural thing to do at the time. Looking back at our evolution, we wouldn’t change anything. But with all we’ve learned, we could definitely do everything faster the second time around.

We’ve always created and improved our products based on our customers’ feedback, and that is the best way to develop a business. It doesn’t matter what you personally like — you need to make sure you solve a real problem for a real customer.

Read, read, read.

In the past three years, I’ve read more than I’d read in my entire life, and this makes me feel great. Here are some of my favorite books, which I recommend to everybody:

How to Win Friends and Influence People — Dale Carnegie

Zero to One — Peter Thiel

The Hard Thing About Hard Things — Ben Horowitz

Law of Success — Napoleon Hill

Think and Grow Rich — Napoleon Hill

Good to Great — Jim Collins

The Lean Startup — Eric Ries

The Charisma Myth — Olivia Fox Cabane

Lean Analytics: Use Data to Build a Better Startup Faster — Alistair Croll

I really do think that the secret weapon is to deliver great products combined with a great user experience and a great customer support.

The best decision that we made was to put our customer in the first row, and make sure that they were receiving a great UI kit/Dashboard that really solved their problems. That guided us through the whole journey. Our secret weapon is that we deliver great products combined with a great user experience and great customer support.

Everything is possible.

We are living in a world where anybody can become anything they want as long as they want to invest the amount of time that is needed. I’m saying time, and not money, because we all have time. I want to recommend two books that talk about this: Karaoke Capitalism by Jonas Ridderstråle and Kjell Nordstrom, and Zero to One by Peter Thiel (a PayPal co-founder).

At this point, there are no limits. You can go anywhere on the planet and you can talk with whomever you want just by contacting them through social media. Today an ordinary person can achieve more influence than the president of a small country. Think of those Instagram accounts with millions of followers. If I — a regular guy from Romania — can build a profitable business in 2.5 years that is making 60x my country’s monthly minimum monthly wage, then boy, just about anything is possible.

Elvis was "just a village boy from Nigeria who had nothing but a dream and a Nokia J2ME feature phone." Today, he's a 19 year old Android developer who has worked on over 50 apps and currently works for an MIT startup. This is his story.

Written by Elvis Chidera: https://twitter.com/elvisnchidera

Read by Quincy Larson: https://twitter.com/ossia

Original article: https://fcc.im/2Bwp50Y

Learn to code for free at: https://www.freecodecamp.org

Intro music by Vangough: https://fcc.im/2APOG02

Transcript: 

In 2012, I was just a village boy from Nigeria who had nothing but a dream and a Nokia feature (J2ME) phone. Today, I’m a 19 year old Android developer who has worked on over 50 apps and currently works for an MIT startup. My name is Elvis Chidera and this is my story.

My journey began with my curiosity about how to build a website. Growing up, I spent a lot of time online as I loved downloading games and reading Society Of Robots. I would save for weeks to buy a 10 MB internet bundle for 100 Naira ($0.28), and back in 2012, that could last for a month.

When learning to code, I took the first and simple step of doing a Google search about how to build a website. I got millions of results. Not knowing where to start, I clicked on the first link I saw, which was from W3CSchools.

The article explained that I need to learn some languages (HTML and CSS) to be able to build a website. I checked some other resources to confirm that I actually needed to learn these things. Then I started the W3CSchools HTML and CSS course.

Each day after school I would head over to the website to study. Initially, the code examples and explanations didn’t make much sense to me. But I kept studying regardless. I referred to various tutorials when I was stuck. This helped me view the problems I encountered from many different angles.

When I was younger, I struggled with my reading and writing skills in school. I was only able to get better at them through continuous practice. So I already had this model in my head: if I continue to practice — no matter how long it takes — I will ultimately be able to understand these programming languages.

A few months of intensive learning got me acquainted with HTML, CSS, and JavaScript. While I was still learning, a friend showed me the movie “The Social Network.” And after watching it, I was super motivated to build the next big thing. Thank you, Hollywood.

I had a eureka moment a few days later. The idea was to build a better version of Facebook. At that time, you couldn’t see your Facebook friends that were online. Also, Facebook was built to connect with people you already knew in real life.

So that was my billion dollar startup idea: build a social network with all the features Facebook didn’t have. Mark Zuckerberg - I’m coming for you - or so I thought.

I spent the next few months building a better social network by adding any feature I could even think of using.

I was naively confident that I was going to win.

After completing the project, I did what anybody without an advertising budget would do. I spammed the internet for days and days.

After several days of marketing, reality slapped me hard in the face. I only got 200 users, which I had to keep begging to come back to the site.

I was depressed! A few months of hard work spent in vain. This taught me two important lessons the hard way:

I needed to recognize the cold start AKA chicken and egg problem that new platforms face early on.

I was building something I thought people needed. But I ended up building just another feature factory.

While it’s okay to be motivated by a project, you also need to know when you’re headed down a dead end. I spent a few more months trying to see if I could get more people on my site, but retention numbers kept dancing toward 0%, and I eventually gave up on the project.

But I was motivated by the motto of Lewis in Meet the Robinsons, “Keep moving forward.”

Seeking inspiration for my next project, I reflected on the needs of my local community. This time around, I wanted to build something that people actually needed and are willing to pay for.

I came up with an idea to make text messages cheaper and easier to send to multiple people at a time. This was more like Whatsapp backed by SMS. After speaking to different people about it, I decided this was the next thing to do.

I named the project Xmx Me. It was going to be a J2ME app. This meant I had to learn Java. Looking back in time, I have to admit that it was the biggest challenge I’d yet encountered. I had to read some tutorials several times to fully understand them.

After completing a few Java courses, I was ready for work. Relentlessly typing one line of code after another, I carefully built the backend with PHP, the frontend with HTML and CSS, and the mobile app with J2ME. The app was coming to life.

But here’s the thing — I didn’t own a laptop. I was building out all of these pieces of my app on my J2ME feature phone.

Wait. What?

You read that right.

I wrote my code on a Nokia 2690

How I built my production apps on a feature phone

At this point in my life, I had never actually programmed on a laptop. I simply couldn’t afford one. My parents wanted to help me. But it was difficult for them because they had to choose between paying my school fees (and other necessities) versus buying me a laptop.

I hadn’t used a laptop before, and my only interaction with computers was at cyber cafes. I remember watching some videos about how to use a computer (left click, drag, drop, and other basic stuff) and then walking into a cyber cafe to practice them.

I was lucky that a relative had gifted me a feature phone (The Nokia 2690). This phone changed my life. It’s what I used to develop Xmx Me, my failed social network, and several other projects.

With nothing but a phone and the will to succeed, hour after hour I typed my code on that tiny keyboard. I was lucky again to have found an app that allowed me to compile my J2ME projects. Yes, building a J2ME app on a J2ME phone is possible.

The SDK was resource hungry, so my battery often died. I would carry on, writing out all my code on paper and try to review it for any syntax errors.

I don’t think I’ll fail any Java whiteboard coding tests after having done this for so long. :)

Launching my group SMS app

After several months, I had the product ready. I was able to convince someone I met on an internet forum to help me pay for the website hosting and the bulk SMS service for a limited number of SMS units.

The app launch went well — at least better than my first project. We got some local press, and one of Kenya’s top blogs even wrote about the app. We grew organically to about 5,000 users.

We were in business. And we were getting transactions a couple of times a day.

With no prior experience running a business, I made some huge mistakes, some of which were:

There was no easy way to charge users in Nigeria. Not everybody has a debit card. So I allowed people to pay using their mobile phone credit. The problem here was, there was no official way to convert this credit into money. I had to sell to vendors, who bought it back at a ridiculously low rates.

There was little to no accounting. I was losing money and I didn’t know about it. I didn’t factor in some overhead costs. There were several missing pieces.

I was considering selling the App to buy a laptop. Not knowing what to do, I went online to beg. Yes, I was that shameless and hungry. It didn’t turn out well. Somebody accused of being a scammer, which I eventually resolved. Again, I was inexperienced and I handled the situation poorly.

After borrowing money multiple times to keep the business running, I decided to throw in the towel. Looking back, I think this was a bad decision. With a little more learning and experience, I would have been able to make things better. Maybe I didn’t see any future in an SMS app. Well, I released a throwback app recently, and many of the users still use it and love it.

Lessons I learned along the way

I realized that if I was going to be able to afford a computer anytime soon, I would need to work hard for it. So I began saving all the money I could. I cut my daily expenses and lived as simple a life as possible. I asked my relatives for help. I even sold some personal belongings to raise money for the laptop.

Still, it wasn’t enough. Determined to achieve my goal, I took on a freelance job of building a website so I could earn the remaining sum.

How do you use a feature phone to build a website designed for PC users? Simple: have a Facebook friend who you disturb every night to view your website on his computer and give you feedback. It was cheaper than going to a cyber cafe repeatedly.

I also made heavy use of Ideone which allowed me to run my PHP scripts to see if they work before uploading them.

Well, I finally was able to get that laptop. I can still remember the feeling of joy I had. That smell of plastic when you unbox a brand new cheap computer. I could now work on any project I wanted without feeling restricted because of my phone.

Since J2ME devices were slowly dying out, I eventually switched to building for the Android platform. My Java skills were still relevant there. I just needed to learn some platform-specific things.

The next year in 2015, after high school, I decided to start working to support my family. So I began freelancing. I was always active in local forums and groups, looking for people who wanted help with building an Android app.

Because I didn’t have a good portfolio, I would build apps for some people before they even paid, without any guarantee that I’d be paid. I was stung by this approach several times, but it allowed me to build a good enough portfolio.

I would like to share something I wish I knew while I was freelancing:

Don’t spread yourself too thin. Taking up too many responsibilities is not good for your health, your family, or the clients.

I worked with several clients from different parts of Nigeria who loved my work. I eventually got a full-time job in Lagos, Nigeria after working with a client remotely.

Then, while going through my news feed, I saw a job advert for an Android developer position at Dot Learn. I looked them up and realized they are an MIT startup working in an education technology field that I was passionate about, and in a market I understood. They had a unique idea: to solve the problem of access to online education by making educational videos that are extremely data-light — as low as 1MB for every hour of video.

This was almost unbelievable, and I knew it was key to making education very accessible to a lot of people.

I am very passionate about revolutionizing education in Africa. In fact, I have already built a free (ad-supported) exam prep app called PrepUp that has over 30,000+ installs and was one of the finalists at the West Africa Mobile Awards in 2016. So I wanted to be part of what Dot Learn was building.

So I went through the developer job requirements and I felt I had a chance. But impostor syndrome didn’t want me to be great.

For days I had conflicting thoughts. Should I apply or not?

Then I realized one thing: I had nothing to lose.

The worst that could happen would be that I got rejected. But I wouldn’t die. So, I went ahead and applied.

Fingers crossed, I started re-watching several of the videos I had downloaded from MIT OCW. I also spent some nights watching some coding interview solution videos. In the past, I had mostly been hired based on my strong portfolio and previous job experience, but I didn’t want to be caught off guard if they gave me a coding interview.

Well, long story short: after lots of preparation, answering some difficult questions, a phone interview, and some coding projects, I was accepted.

I couldn’t believe it. I was ecstatic.

Looking back at it, this was one of my best decisions.

Working at Dotlearn, I have had exponential growth in my career and have met with lots of awesome people from MIT, Harvard, and other great places.

From attending big events like the Techcrunch Battlefield (I ended up missing my flight) to realizing I could rap, it’s been a fun and exciting experience so far.

 

An Australian developer thought his local police force was spending way too much money on their new license plate scanning system. So he decided to build one himself. Here's how he did this, and how he ended up catching a criminal.

Written and read by Tait Brown: https://twitter.com/taitems

Original article: https://fcc.im/2iJWWuE

Learn to code for free at: https://www.freecodecamp.org

Intro music by Vangough: https://fcc.im/2APOG02

Transcript:

The Victoria Police are the primary law enforcement agency of Victoria, Australia. With over 16,000 vehicles stolen in Victoria this past year — at a cost of about $170 million — the police department is experimenting with a variety of technology-driven solutions to crackdown on car theft. They call this system BlueNet.

To help prevent fraudulent sales of stolen vehicles, there is already a VicRoads web-based service for checking the status of vehicle registrations. The department has also invested in a stationary license plate scanner — a fixed tripod camera which scans passing traffic to automatically identify stolen vehicles.

Don’t ask me why, but one afternoon I had the desire to prototype a vehicle-mounted license plate scanner that would automatically notify you if a vehicle had been stolen or was unregistered. Understanding that these individual components existed, I wondered how difficult it would be to wire them together.

But it was after a bit of googling that I discovered the Victoria Police had recently undergone a trial of a similar device, and the estimated cost of roll out was somewhere in the vicinity of $86,000,000. One astute commenter pointed out that the $86M cost to fit out 220 vehicles comes in at a rather thirsty $390,909 per vehicle.

Surely we can do a bit better than that.

The Success Criteria

Before getting started, I outlined a few key requirements for product design.

Requirement #1: The image processing must be performed locally

Streaming live video to a central processing warehouse seemed the least efficient approach to solving this problem. Besides the whopping bill for data traffic, you’re also introducing network latency into a process which may already be quite slow.

Although a centralized machine learning algorithm is only going to get more accurate over time, I wanted to learn if an local on-device implementation would be “good enough”.

Requirement #2: It must work with low quality images

Since I don’t have a Raspberry Pi camera or USB webcam, so I’ll be using dashcam footage — it’s readily available and an ideal source of sample data. As an added bonus, dashcam video represents the overall quality of footage you’d expect from vehicle mounted cameras.

Requirement #3: It needs to be built using open source technology

Relying upon a proprietary software means you’ll get stung every time you request a change or enhancement — and the stinging will continue for every request made thereafter. Using open source technology is a no-brainer.

My solution

At a high level, my solution takes an image from a dashcam video, pumps it through an open source license plate recognition system installed locally on the device, queries the registration check service, and then returns the results for display.

The data returned to the device installed in the law enforcement vehicle includes the vehicle’s make and model (which it only uses to verify whether the plates have been stolen), the registration status, and any notifications of the vehicle being reported stolen.

If that sounds rather simple, it’s because it really is. For example, the image processing can all be handled by the openalpr library.

This is really all that’s involved to recognize the characters on a license plate:

A Minor Caveat

Public access to the VicRoads APIs is not available, so license plate checks occur via web scraping for this prototype. While generally frowned upon — this is a proof of concept and I’m not slamming anyone’s servers.

Results

I must say I was pleasantly surprised.

I expected the open source license plate recognition to be pretty rubbish. Additionally, the image recognition algorithms are probably not optimised for Australian license plates.

The solution was able to recognise license plates in a wide field of view.

Annotations added for effect. Number plate identified despite reflections and lens distortion.

Although, the solution would occasionally have issues with particular letters.

A few frames later, the M is correctly identified and at a higher confidence rating.

As you can see in the above two images, processing the image a couple of frames later jumped from a confidence rating of 87% to a hair over 91%.

I’m confident, pardon the pun, that the accuracy could be improved by increasing the sample rate, and then sorting by the highest confidence rating. Alternatively a threshold could be set that only accepts a confidence of greater than 90% before going on to validate the registration number.

Those are very straight forward code-first fixes, and don’t preclude the training of the license plate recognition software with a local data set.

The $86,000,000 Question

To be fair, I have absolutely no clue what the $86M figure includes — nor can I speak to the accuracy of my open source tool with no localized training vs. the pilot BlueNet system.

I would expect part of that budget includes the replacement of several legacy databases and software applications to support the high frequency, low latency querying of license plates several times per second, per vehicle.

On the other hand, the cost of ~$391k per vehicle seems pretty rich — especially if the BlueNet isn’t particularly accurate and there are no large scale IT projects to decommission or upgrade dependent systems.

Future Applications

While it’s easy to get caught up in the Orwellian nature of an “always on” network of license plate snitchers, there are many positive applications of this technology. Imagine a passive system scanning fellow motorists for an abductors car that automatically alerts authorities and family members to their current location and direction.

Teslas vehicles are already brimming with cameras and sensors with the ability to receive OTA updates — imagine turning these into a fleet of virtual good samaritans. Ubers and Lyft drivers could also be outfitted with these devices to dramatically increase the coverage area.

Using open source technology and existing components, it seems possible to offer a solution that provides a much higher rate of return — for an investment much less than $86M.

Remember the $86 million license plate scanner I replicated? I caught someone with it.

A few weeks ago, I published what I thought at the time was a fairly innocuous article: How I replicated an $86 million project in 57 lines of code.

I’ll admit — it was a rather click-bait claim. I was essentially saying that I’d reproduced the same license plate scanning and validating technology that the police in Victoria, Australia had just paid $86 million for.

Since then, the reactions have been overwhelming. My article received over 100,000 hits in the first day, and at last glance sits somewhere around 450,000. I’ve been invited to speak on local radio talk shows and at a conference in California. I think someone may have misread Victoria, AU as Victoria, BC.

Although I politely declined these offers, I have met for coffee with various local developers and big name firms alike. It’s been incredibly exciting.

Most readers saw it for what it was: a proof of concept to spark discussion about the use of open source technology, government spending, and one man’s desire to build cool stuff from his couch.

Pedants have pointed out the lack of training, support, and usual enterprise IT cost padders, but it’s not worth anyone’s time exploring these. I’d rather spend this post looking at my results and how others can go about shoring up their own accuracy.

Before we get too deep into the results, I’d like to go over one thing that I feel was lost in the original post. The concept for this project started completely separate from the $86 million BlueNet project. It was by no means an attempt to knock it off.

It started with the nagging thought that since OpenCV exists and the VicRoads website has license plate checks, there must be a way to combine the two or use something better.

It was only when I began my write-up that I stumbled upon BlueNet. While discovering BlueNet and its price tag gave me a great editorial angle, with the code already written. There were bound to be some inconsistencies between the projects.

I also believe part of the reason this blew up was the convenient timing of a report on wasteful government IT spending in Australia. The Federal Government’s IT bill has shot up from $5.9 billion to $10 billion, and it delivered dubious value for that blow out. Media researchers who contacted me were quick to link the two, but this is not something I am quick to encourage.

A Disclaimer

In the spirit of transparency, I must declare something that was also missing from the original post. My previous employer delivered smaller (less than $1 million) IT projects for Victoria Police and other state bodies. As a result, I’ve undergone police checks and completed the forms required to become a VicPol contractor.

This may imply I have an axe to grind or have some specific insider knowledge, but instead I am proud of the projects we delivered. They were both on time and on budget.

Visualizing the Results

The following is a video representation of my results, composited in After Effects for a bit of fun. I recorded various test footage, and this was the most successful clip.

I will go into detail about ideal camera setups, detection regions, and more after the video. It will help you better understand what made this iPhone video I took from through the windscreen a better video than a Contour HD angled out the side window.

An Ethical Dilemma

If you saw the hero graphic of this article or watched the video above, you may have noticed a very interesting development: I caught someone.

Specifically, I caught someone driving a vehicle with a canceled registration from 2016. This could have happened for many reasons, the most innocent of which is a dodgy resale practice.

Occasionally, when the private sale of a vehicle is not done by the book, the buyer and seller may not complete an official transfer of registration. This saves the buyer hundreds of dollars, but the vehicle is still registered to the seller. It’s not unheard of for a seller to then cancel the registration and receive an ad hoc refund of remaining months, also worth hundreds of dollars.

Alternatively, the driver of the vehicle could well be the criminal we suspect that they are.

So, although I jokingly named the project plate-snitch when I set it up on my computer, I’m now faced with the conundrum of whether to report what I saw.

Ultimately, the driver was detected using a prototype of a police-only device. But driving on a 2016 registration (canceled, not expired) is a very deliberate move. Hmm.

Back to the Results

Of the many reactions to my article, a significant amount were quite literal and dubious. Since I said I replicated the software, they asserted that I must have a support center, warranties, and training manuals. One even attempted to replicate my results and hit the inevitable roadblocks of image quality and source material.

Because of this, some implied that I cherry-picked my source images. To that I can only say, “Well, duh.”

When I built my initial proof of concept (again, focusing on validating an idea, not replicating BlueNet), I used a small sample set of less than ten images. Since camera setup is one of, if not the most, important factors in ALPR, I selected them for ideal characteristics that enhance recognition.

At the end of the day, it is very simple to take a fragile proof of concept and break it. The true innovation and challenge comes from taking a proof of concept, and making it work. Throughout my professional career, many senior developers have told me that things can’t be done or at least can’t be done in a timely manner. Sometimes they were right. Often, they were just risk averse.

“Nothing is impossible until it is proven to be.”

Many people bastardize this quote, and you may have seen or heard one of it’s incarnations before. To me, it neatly summarizes a healthy development mindset, in which spiking and validating ideas is almost mandatory to understanding them.

Optimal ALPR Camera Setups

This project is so exciting and different for me because it has a clear success metric — whether the software recognizes the plate. This can only happen with a combination of hardware, software, and networking solutions. After posting my original article, people who sell ALPR cameras quickly offered advice.

Optical Zoom

The most obvious solution in hindsight is the use of an optical zoom. Though I explore other important factors below, none lead to such a sheer increase in recognition as this. In general, professional ALPR solutions are offset at an angle, trained on where the license plate will be, and zoomed into the area to maximize clarity.

This means the more zoom, more pixels to play with.

All the cameras I had at my disposal were of a fixed lens. They included:

A Contour HD action camera. These came out in 2009, and I use mine to record my cycling commute and to replay each week’s near death experience.

The featured test run was recorded on my phone. My only method of replicating an optical zoom was using an app to record at 3K instead of 1080p, and then digitally zooming and cropping. Again, more pixels to play with.

Angle & Positioning

The viewing angle of 30° is often referenced as the standard for ideal plate recognition. This is incredibly important when you learn that BlueNet uses an array of cameras. It also makes sense when you consider what a front facing camera would generally see — not very much.

What a front facing ALPR camera sees — not much.

If I had to guess I’d say a mostly forward-facing array would be the ideal setup. It would consist of a single camera pointed dead center as above, two off-center at 30° each side, and a single rear-facing camera. The value in having most of the cameras pointed forward would come from the increased reaction time if the vehicle is traveling in the opposite direction. This would allow a quicker scan, process, and U-turn than if the rear facing cameras picked up a suspect vehicle already ten meters past the police vehicle.

A four camera array would need to be angled similar to this. Icons from Freepik.

A Gymbal

When compositing the video, I thought about stabilizing the footage. Instead I opted to show the bumpy ride for what it was. What you saw was me holding my phone near the windscreen while my wife drove. Check out that rigorous scientific method.

Any production-ready version of a vehicle-mounted ALPR needs some form of stabilisation. Not a hand.

Frame Rate

Both the attempt to replicate my project and my recordings since then explored the same misconception that ALPR sampling frame rate may be linked to success. In my experience, this did nothing but waste cycles. Instead, what is incredibly important is the shutter speed creating clean, crisp footage that feeds well into the algorithm.

But I was also testing fairly low-speed footage. At most, two vehicles passing each other in a 60km/h zone created a 120km/h differential. BlueNet, on the other hand, can work up to an alleged 200km/h.

As a way of solving this, a colleague suggested object detection and out-of-band processing. Identify a vehicle and draw a bounding box. Wait for it to come into the ideal recognition angle and zoom. Then shoot a burst of photos for asynchronous processing.

I looked into using OpenCV (node-opencv) for object recognition, but I found something simpler like face detection, taking anywhere from 600–800ms. Not only less than ideal for my use, but pretty poor in general.

Hype-train TensorFlow comes to the rescue. Able to run on-device, there are examples of projects identifying multiple vehicles per frame at an astounding 27.7fps. This version could even expose speed estimations. Legally worthless, but perhaps useful in every day policing (no fps benchmark in readme).

To better explain how high-performance vehicle recognition could couple with slower ALPR techniques, I created another video in After Effects. I imagine that the two working hand-in-hand would look something like this:

Idea: how vehicle object detection could remove ALPR frame limits by processing asynchronously.

Frame Rate vs Shutter Speed

A different manifestation of frame rate is largely influenced upon shutter speed, and more specifically, the rolling shutter issues that plague early or low end digital movie recorders. The following is a snapshot from some Contour HD footage. You can see at only 60km/h the rolling shutter issue makes the footage more or less unusable from an ALPR point of view.

Adjusting frame rate on both the Contour HD and my iPhone did not result in noticeably less distortion. In theory, a higher shutter speed should produce clearer and crisper images. They’d become increasingly important if you were to chase the 200km/h BlueNet benchmark. Less blur and less rolling shutter distortion would ideally lead to a better read.

Open ALPR Version

One of the more interesting discoveries was that the node-openalpr version I was using is both out-of-date and not nearly as powerful as their proprietary solution. While an open source requirement was certainly a factor, it was amazing how accurately the cloud version could successfully read frames that I couldn’t even identify a plate on.

ALPR Country Training Data

I also found that the main node-openalpr package defaults to US country processing with no way of overriding it. You have to pull down someone else’s fork which allows you to then provide an extra country parameter.

Slimline Australian plates need their own separate country detection to regular Australian plates?

But this doesn’t always help. Using the default US algorithm I was able to produce the most results. Specifying the Australian data set actually halved the number of successful plate reads, and it only managed to find one or two that the US algorithm couldn’t. Providing the separate “Australian Wide Plate” set again halved the count and introduced a single extra plate.

There is clearly a lot to be desired when it comes to Australian-based data sets for ALPR, and I think that the sheer number of plate styles available in Victoria is a contributing factor.

Good luck with that.

Planar Warps

Open ALPR comes with one particular tool to reduce the impact of distortion from both the camera angle and rolling shutter issues. Planar warp refers to a method in which coordinates are passed to the library to skew, translate, and rotate an image until it closely resembles a straight-on plate.

In my limited testing experience, I wasn’t able to find a planar warp that worked at all speeds. When you consider rolling shutter, it makes sense that the distortion grows relative to vehicle speed. I would imagine feeding accelerometer or GPS speed data as a coefficient might work. Or, you know, get a camera that isn’t completely rubbish.

What others are doing in the industry

Numerous readers reached out after the last post to share their own experiences and ideas. Perhaps one of the more interesting solutions shared with me was by Auror in New Zealand.

They employ fixed ALPR cameras in petrol stations to report on people stealing petrol. This in itself is not particularly new and revolutionary. But when coupled with their network, they can automatically raise an alert when known offenders have returned, or are targeting petrol stations in the area.

Independent developers in Israel, South Africa, and Argentina have shown interest in building their own hacked-together versions of BlueNet. Some will probably fare better than others, as places like Israel use a seven digit license plates with no alphabet characters.

Key Takeaways

There is simply too much that I’ve learned in the last few weeks of dabbling to fit into one post. While there have been plenty of detractors, I really do appreciate the support and knowledge that has been sent my way.

There are a lot of challenges you will face in trying to build your own ALPR solution, but thankfully a lot of them are solved problems.

To put things in perspective, I’m a designer and front end developer. I’ve spent about ten hours now on footage and code, another eight on video production, and at least another ten on write-ups alone. I’ve achieved what I have by standing on the shoulders of giants. I’m installing libraries built by intelligent people and have leveraged advice from people who sell these cameras for a living.

The $86 million question still remains — if you can build a half-arsed solution that does an okay job by standing on the shoulders of giants, how much more money should you pour in to do a really really good job?

My solution is not even in the same solar system as the 99.999% accurate scanner that some internet commenters seem to expect. But then again, BlueNet only has to meet a 95% accuracy target.

So if $1 million gets you to 80% accuracy, and maybe $10 million gets you to 90% accuracy — when do you stop spending? Furthermore, considering that the technology has proven commercial applications here in Oceania, how much more taxpayer money should be poured into a proprietary, close-sourced solution when local startups could benefit? Australia is supposed to be an “innovation nation” after all.

5 years ago, Ken was a college dropout who woke up every day at 4 a.m. to drive a forklift. He taught himself to code and kick-started his career by convincing a local web development company to hire him. Ken shares his advice on how to go from a hobbyist to a professional developer.

Written and read by Ken Rogers: https://twitter.com/KennethARogers

Ken's original article: https://fcc.im/2FeA24K

Learn to code for free at: https://www.freecodecamp.org

Intro music by Vangough: https://fcc.im/2APOG02

Transcript:

A few years ago, I was bouncing back and forth between landscaping jobs and restaurant jobs. I had just left college, and didn’t know what I was going to do with my life.

I had a lot of ideas, but no direction. During that time, I started teaching myself programming. At first it was a hobby. I thought it was cool to be able to build things using nothing but my brain and some code.

But then I started thinking about where my life was going, and saw this as a potential living.

At first, I put the idea out of my head. I couldn’t afford real education. I already dropped out of college once because of money, and if I went in for computer science, I’d have to start over.

I’d leave with 6 years of school and well over $50,000 in debt if I took that route. So that wasn’t an option.

Then I started thinking that I could teach myself web development well enough to get an internship.

My initial plan was to introduce myself to a few companies in my town, and ask if they would want to meet with me. I wanted to discuss the potential of me working with them while I was in school. That way I could pay for school and get some experience at the same time.

So I got serious about web development.

Instead of tinkering I started to build a real portfolio and document my skills.

I started becoming active on places like Stack Overflow.

I built a few practical applications and put them on GitHub. They were nothing fancy, but they demonstrated that I knew how to code.

One company didn’t offer me a part time job. They didn’t say to come back after I had my degree. They offered me a full-time job on a 6 month trial basis as their new Junior Developer.

I was over the moon. It turns out that once I got serious and started developing with a purpose, I taught myself quite a bit.

I was able to answer their questions. I was able to walk them through the modest applications I had built. And I was able to explain how my projects worked.

I stayed at that company for two and a half years, and then took a job as a web developer for the city I live in.

View yourself as a lifelong apprentice

An important part of my transition into a professional developer role was viewing the time I spent with my previous company as an apprenticeship. I learned as much as I could.

The real-world knowledge gained from working at a company is invaluable. Knowing how to work with clients, coworkers, and within constraints is essential. This is something you can only learn in the field.

While I may know more now than I did when I first started that job, I’ll never stop viewing myself as an apprentice. One of the requirements for being a great developer is the desire to continue learning. The minute we see ourselves as having mastered a skill is the minute we stop growing.

Hemingway said it best:

We are all apprentices in a craft where no one ever becomes a master.

He was talking about writing, but it applies to development as well.

The combination of teaching myself and working for a company has allowed me to learn so much (I’m even writing a book). I understand the technical practice of web development, and also how to go from a hobbyist to a professional. It’s a path that anyone can take, regardless of your time or abilities.

To give you some perspective, I was working two jobs at once — one of which involved getting up at 4 a.m. to drive a forklift around.

Learning to code as a busy adult takes determination, drive, and a stubborn persistence.

Making the transition from Hobbyist to Professional

Here’s a process that you can follow. The exact journey will be different for everyone, but there are steps you can take to get you on the right path.

1. Realize that you can do this

Anyone can teach themselves to be a developer. There’s this idea that being self-taught is something only a certain type of person can do. They’re right in a sense. You need to be self-driven and motivated by something other than immediate payment. But anyone can become this type of person.

There’s this idea present in our society that some people are born with certain traits and others aren’t. It’s detrimental to growth, and one of the reasons why so many people feel unfulfilled in life.

If you always felt that you either “had it” or you didn’t, it would be very easy to get discouraged.

I want to put that myth to bed right now. Anyone can learn to be self-motivated and teach themselves programming. Or start a successful business. Or achieve a long-term goal.

It’s not about catching a big break, or being born with the right traits. It’s about perseverance.

If you can put your head down, push through the hard times, and commit, you can do anything you want to.

That last part is super important, but I want to provide a warning before moving on.

People are often too quick to embrace their own successes and the successes of others. It’s known as survivorship bias.

There is an element of luck in everything. Sometimes things just work out. For example, I contacted a web development agency and was lucky enough that they happened to be looking for someone at that moment, and I happened to fit what they were looking for.

But what is luck?

Sure, I was lucky to get that job, but I never would have been lucky if I hadn’t made the decision to teach myself development. And then made the decision to apply to that job.

Luck does play a factor, but the myth is that it is all up to luck. You can increase your odds of getting lucky, you just have to be willing to put yourself out there.

But luck will never find you if you don’t commit to being great at something.

2. Commit to being incredible at your craft

One of my biggest weaknesses is that I get bored and distracted. I want to jump into the next project. This tendency will kill your success.

It feels like freedom. Being able to bounce between whatever project happens to suit your mood that day, but...

It’s a trap! If you take away nothing else from this article, let it be this:

The number one key to succeeding in becoming a professional developer is to commit. Commit and never stop until you make it happen.

This applies to everything.

People stress out about which framework to use. But what matters is picking one and sticking with it. You can transfer and learn new languages and frameworks later.

What matters is the problem solving skills you will gain when developing. The ability to think like a developer.

I taught myself programming using Laravel, but the company that hired me used CakePHP. It didn’t matter. They knew I could pick up the technical skills required to switch frameworks.

Pick a direction and see it through, no matter what. You have to remove the possibility of getting distracted by something else.

Few feelings can compare to the relentless pursuit of mastery of a craft.

It isn’t easy. Once you learn to ignore distractions, you will notice an increase in enjoyment of your work.

Mike Rowe is fond of saying that people shouldn’t start with finding their passion.

People are so unhappy because they look for the perfect career. They look for the one that they are passionate about.

But passion comes from an unstoppable desire to be incredible at your craft. Once you adopt that mindset, your abilities as a developer will take on a new life.

3. Start building things immediately

Aspiring developers can get stuck in the trap of reading too much without taking action.

Tutorials and books are great for learning the basics. The problem is that they instill a false sense of confidence in the developer.

Have you ever finished a programming book and gone to build something on your own only to realize you had no idea how to go about doing it? Then you know what I’m talking about.

The solution to this is simple, but not easy.

Start building.

Make something. Make an app that solves a problem you have in your own life, or that addresses an issue for someone close to you.

Make something for fun.

Make something and put it out there. Make it open source and put in on GitHub. You aren’t doing it for anyone else, it’s for you, so don’t worry about other people’s opinion of it.

Your code will be ugly at first. I look back at some of the code I wrote even a few months ago and want to vomit. But you can’t learn development without building stuff. Books are fantastic, and I am obsessed with reading as many as possible. Then you must apply that knowledge.

You’re going to run into issues and you’re going to struggle. That’s good. Those are the times we learn the most.

Start off by building things that solve problems, I’ll talk more about that in step 6 below.

4. Set up an online presence

As soon as you start building things, you’ll want to set up an online presence. Your GitHub account will be a great start.

This is where you’ll be able to house the projects you are working on and share them with the world.

But you want to go further than this. I recommend setting up your own portfolio site.

This site will do a few things:

- It will serve as a public place to tell potential employers about yourself

- It will be another place where you can showcase your work

- It will serve as your platform

- That last one is huge. Once you start building things, you should immediately start writing about them. Start a simple blog where you share what you are working on and teach everything you know.

This is one of the best ways to give potential employers a taste of who you are and what you can do. It’s a way to get your name out there and start building a platform for yourself.

This can lead to job opportunities and the possibility to make more income on the side by writing books or freelancing.

Your site should serve a very specific purpose.

Most people create an online resume, but you should do more. What is your specific goal? Your website should be designed and created around that goal.

If you want to get a job working on a certain kind of project or with a certain framework, put that in your site.

I recommend having 4 core areas for your site:

1. Home page

Your home page is the entry point to your site. It should provide a very brief overview about who you are and what you do. And should direct people to go where is most relevant for them.

For example, you could have two main buttons. One leading people to your writing section to learn more about web development, and one leading to a hire me page if someone is interested in hiring you.

2. Writing

This is where your blog and your tutorials will live. Write as much as you can here, and don’t be afraid to share it.

3. About

A simple about section that goes into more detail about who you are and what you do. Don’t make this a life story. Again, target this section to be relevant towards what you want to do.

Rather than talk about your personal life, talk about what led you to web development, your journey so far, and where you want to go. Mention some of your favorite projects and link to them.

4. Hire Me

An essential part of your site, this is where people will go if they are interested in hiring you as a developer.

Make sure to find the right balance between selling yourself and being honest. There may be some overlap between this page and your about page, but this page will be more specific about your skills and what you bring to the table.

This page should also have a contact form so people can get in touch.

In addition to your own site, start offering to write for other major publications. Then you can provide a link back to your site in the bio section.

5. Start teaching everything you know

Nathan Barry is a big fan of teaching everything you know. He tells the story of Chris Coyier, founder of CSS Tricks.

That site started out as Chris publicly writing about what he was learning so others could follow along. Now it’s one of the biggest web development sites out there.

The lesson here is that you don’t have to be the world’s greatest expert to start writing about something and teaching it.

In the online business world, there is this idea of the relative expert. It’s the idea that everyone is an expert in something relative to someone else.

I have my issues with this, especially when it is used by someone to justify selling something that maybe they shouldn’t be selling. But it is a useful comparison to make.

What bothers me is the use of the word expert. I don’t think there is anything wrong with teaching what you know, and even potentially selling that information if it is valuable to someone else.

But calling yourself an expert may be taking it too far. So when you write your content, approach it honestly.

I prefer the term learning in public.

There are many people who got their start by simply being a public learner. They were learning a craft and documenting what they were learning along the way.

This is the perfect way to approach teaching everything you know. As you learn more and more, you build up your content, and become a better writer in the process. Over time, others in your industry will start to see you as an authority in your space.

This will be invaluable both when it comes to finding a job and if you ever want to strike out on your own.

6. Build to solve problems

One of the most important aspects of becoming a professional developer is doing everything with a specific intention.

It’s one thing to build random apps for fun, it’s another to build apps and sites that solve specific problems.

Web development shops aren’t really in the business of coding, they are in the business of solving problems. The coding is just their preferred tool to make that happen.

Read any marketing or copywriting book and they will tell you to sell the benefits of your product, not the features.

Web developers should market their apps to show how they effectively solve a customer’s problems. And then back up their claims with specific metrics. Customers are generally more responsive to this approach than if the developers talk about the bleeding edge technologies they use.

You will be a very attractive prospect for employers if you can demonstrate your programming skills as well as your ability to code with the specific intention of solving problems and making meaningful applications.

Think about benefits vs features when you are communicating with potential employers or clients, and when writing the content for your site.

Of course, you should also mention your coding proficiency, but most people spend all their time on this. Mention it briefly so potential employers know what you do. If you have a portfolio of effective applications, your coding skills will mostly speak for themselves.

7. Take on an apprentice mindset

The day you think you have mastered something is the day you stop learning.

Adopt the mindset of a lifelong apprentice. There is always more to learn and always more to improve on.

This is especially important in the early stages of your career. If you get a part time job or internship or land a role as a junior developer, you need to immediately get in the mindset of learning and growing as much as possible.

You should really be doing this right away, even before you have an actual ‘mentor’.

In his book, The Art of Work, Jeff Goins talks about the 21st century version of the apprentice-master relationship.

Back in medieval times, the relationship was very formal. A master would take on an apprentice for years, and they would slowly start to master their craft until they reached the title of master, at which point they would take on an apprentice.

The relationship has changed, but it is still very important to consider yourself an apprentice. The main difference is that now you have to keep an eye out for potential mentors and learning opportunities, and there will be many throughout your journey.

In the world of web development, we are constantly on the internet, so this can come in various forms.

Books, tutorials, courses, forums, and other forms of learning are all valuable. I think, however, the most valuable form of apprenticeship comes from learning from someone who is currently in the position you want to be in.

This is why it is so important to be eager and willing to learn. Getting your first development job is not the end of the journey, it’s the beginning.

That is when you will really start learning and exponentially growing your knowledge.

8. Learn to collaborate

One of the biggest differences between coding as a hobby and coding for a living is learning to collaborate with people.

You’ll need to interact and work with peers, bosses, colleagues, clients, partner companies, and all kinds of personalities throughout your career.

Learning how to effectively work with other people is important.

In the field of web development, communication is key. When a company comes in and tells you what they want, and you aren’t clear about exactly what that looks like, it can cause a lot of problems and headaches in the future.

Likewise, if you can’t communicate with the people you work with, your work will suffer and you won’t be able to do your job as well.

While you’re still learning, there are a few great ways to do this.

Part of this will come when you start teaching everything you know. People will interact with you, sometimes negatively, and you’ll learn how to deal with those situations.

I also highly recommend contributing to open source projects. This gives you a taste of what it is like to collaborate on a project where different people may have different ideas on the best way to do things.

Contributing to open source projects can be intimidating, but it will do wonders for your development career.

Check out this site to get started.

Get out there and make a living

Being a web developer is hard. It means a life of non-stop learning and adapting to new technologies. It’s one of those careers where you need to be well-versed in not only technology, but business and communication as well.

It’s an extremely rewarding path. You get to make things that solve people’s problems and make their lives easier, while making a fantastic living at the same time.

There are countless resources to help you learn to code, many of them completely free, but there seems to be a lack of resources helping people make that transition into professional developer.

I hope this short guide provided a good road map for you to get started becoming a professional developer.

Remember, nothing will happen unless you take action. Build a simple portfolio website, email a few potential employers, write some posts on Medium. Just start doing something.

The more you put yourself out there, and the more you do, the sooner you’ll make the shift from amateur to professional.

For Haseeb's first software developer job, he was able to negotiate a total compensation package of US $250,000 for his first year at Airbnb. He believes negotiation is a skill that can be learned, just like any other. And it isn't particularly elusive or hard to understand. In this episode, he explains how anyone can negotiate effectively.

Written and Read by Haseeb Qureshi: https://twitter.com/hosseeb

Haseeb's original article: https://fcc.im/2mBOOea

Learn to code for free at: https://www.freecodecamp.org

Intro music by Vangough: https://fcc.im/2APOG02

Transcript: 

So you’ve maneuvered through the initial offer conversation. You’ve lined up counteroffers from other companies. Now it’s time to enter the actual negotiation.

Naturally, this is the part where everything goes horribly wrong.

But don’t worry. I’m going to turn you into a superhero negotiator. (Or at least an eccentric billionaire negotiator, which is sometimes better?)

Seriously though. In this article, we’re going to deep-dive into the negotiating process, and discuss my final 4 rules on how to negotiate a job offer.

If you didn’t read my first 6 rules, you can read them here (or you can just skip ’em and keep reading):

Ten Rules for Negotiating a Job Offer

When the story of how I landed a job at Airbnb went viral, I was surprised at how infatuated people were with my…

What does it take to be a good negotiator?

Most people think negotiating well is just looking the other person in the eye, appearing confident, and asking for tons of money. But being a good negotiator is a lot more subtle than that.

What Good Negotiators Sound Like

You probably have a friend or family member who’s infamous for refusing to take no for an answer. The kind of person who will march into a department store and bullheadedly argue with the management until they get a purchase refunded.

This person seems like they often get what they want. They make you cringe, but perhaps you should try to be more like them.

Rest assured, this person is actually a terrible negotiator. They’re good at being difficult and causing a scene, which can sometimes convince a waitress or shift manager to appease them. But this style of negotiating will get you nowhere when negotiating with a business partner (that is, an employer).

A good negotiator is empathetic and collaborative. They don’t try to control you or issue ultimatums. Rather, they try to think creatively about how to fulfill both your and their needs.

So when you think of negotiating a job offer, don’t imagine haggling over a used car. Think more like negotiating dinner plans with a group of friends, and you’ll fare much better.

Slicing up the cake

Another important difference between good and bad negotiators is that bad negotiators tend to think of a negotiation as a zero-sum game.

Imagine we’re negotiating over a cake. In a zero-sum negotiation if I get one more slice, you get one less. Any gain I make comes at your expense.

This seems obviously true with cake, right? So what makes a job negotiation any different?

Ah, but it’s not actually true for cake. What if I hate corner pieces and you love them? What if I really like the cherries? What if I’m full and you’re starving, but you’ll agree to treat me to my favorite cake next time?

Of course, when I posed the question I didn’t mention anything about cherries or my feelings on corner pieces. It might seem like I just made stuff up.

But this is exactly what good negotiators do. They bend the rules. They question assumptions and ask unexpected questions. They dig to find the core what everyone values and look for creative ways to widen the terrain of negotiation.

While you were thinking about how to haggle over slices, I’m thinking about how to give both of us more than just half of a cake.

Different parties in a negotiation almost always have different value functions. We may value the same things — we both care about cake, after all. But we don’t value them in exactly the same way, so there’s probably a way to give each of us more of what we want.

Most people go into a job negotiation thinking they need to stubbornly haggle over salary like slices of cake. They don’t ever stop to ask — hey, what do I actually value? Why do I value it? What does the company value? Why do they value that?

There are many dimensions to a job negotiation:

- salary - signing bonuses - stock - year-end or performance bonuses - commuter benefits - relocation expenses - equipment - an educational stipend - a childcare stipend - extra vacation time - a later start date - getting a dedicated hour a day to work out or study or meditate or play solitaire.

You could choose which team you’re assigned to, what your first project will be, what technologies you’ll be working with, and sometimes even choose your title.

Maybe you’re a frosting person, and the company is more into cherries. You never know if you don’t ask.

Hold onto this mindset.

Okay.

Let’s pick up the negotiation where we left off. All the offers are in, and recruiters are eagerly waiting for you to get the ball rolling.

Let’s start negotiating.

Phone VS Email

Your first decision is whether you want to negotiate over the phone, or keep correspondence over e-mail.

Talking on the phone not only signals confidence, but more importantly, it allows you to build a strong relationship with your recruiter.

Talking on the phone enables bantering, telling jokes, and building connection. You want your recruiter to like you, understand you, empathize with you. You want them to want you to succeed. Likewise, you want to care about your recruiter and understand what’s motivating them.

The best deals get made between friends. It’s hard to make friends over e-mail.

However, if you don’t have confidence in your negotiation skills, you should try to push the negotiation to e-mail. Written, asynchronous communication will give you more time to strategize and make it easier to say uncomfortable things without being pressured by a recruiter.

That said, recruiters will always prefer to get you on the phone. It’s essentially their home turf. They’re also well aware that negotiating is easier over e-mail, and they have little interest in making it easier on you. They’ll often be vague about the offer over e-mail and only offer to discuss specific details on the phone.

If you want to stick to email, you have to push back against this. There’s no secret to it: just be honest and ask for what you want.

Tell them:

“Hi recruiter, I hope your day is treating you well!

Re: your previous e-mail, I’d prefer to discuss the details of the offer over e-mail. I sometimes get nervous during important phone calls, so discussing the offer over e-mail helps me to keep a clear head and communicate more clearly. I hope this is okay with you. :)”

No BS, no huff-puffery. Just telling the truth and asking for what you want.

There’s tremendous power in honesty and directness. Take advantage of it.

(Also, note how I wrote “discuss the details of the offer” rather than “negotiate.” Never describe what you’re doing as negotiating — that sounds immediately adversarial and haggley. Describe it instead as a discussion, and they’re less likely to recoil.)

Having Alternatives

I mentioned before how essential it is to have multiple offers. I’ll reiterate again — it’s very, very valuable to have multiple offers.

With other offers on the table, if your negotiation doesn’t work out, they know you’ll just accept another offer. Your negotiating position suddenly becomes a lot more credible because they know you’re willing to walk away.

This effect is strengthened if you get an offer from a prestigious company. And the effect goes through the roof if you have an offer from a company’s primary competitor (now they’ll really want to poach you from the big bad competitor-corp).

Some of this behavior is stupid tribalism. And some part of it is rational in trying to deprive competitors of talent. Either way, take advantage of it, and be tactical in which companies you aim for.

But what if you don’t manage to get any other offers? Does all the negotiating just go out the window?

Not at all. What’s important here is not actually having other offers. More specifically, it’s in having strong alternatives. Which is why Rule #6 of negotiating is: have alternatives.

A negotiation needs stakes. If there were no risk and you knew for sure the other side would sign a contract, what incentive would you have to offer them anything more?

Your alternatives are what give a negotiation its stakes. By signaling your alternatives, you allow your interlocutor to develop a mental model of when and why you’ll walk away from the negotiation. Your alternatives also have an anchoring effect on how much the other side thinks you’re objectively worth.

In negotiation literature, your best alternative is often referred to as your BATNA (Best Alternative To a Negotiated Agreement). Basically, it’s what you’d do if you walked away.

I like the term BATNA a lot, mostly because it sounds like a gadget Batman would lob at bad guys.

So what’s your BATNA if you don’t have other offers? Do you even have one?

Of course you do. Your best alternative might be “interview at more companies” or “go to grad school” or “stay at your current job” or “go on sabbatical in Morocco for a few months” (as it was for a friend of mine who was deliberating between joining a startup and gallivanting through North Africa).

The point is, you don’t need to have another offer to have a strong BATNA.

Your BATNA’s strength comes from:

- how strong the other side perceives it to be, and - how strong you perceive it to be.

If your recruiter thinks that going to grad school is an awesome thing to do, then they’ll see you as having a very strong alternative, and the stakes of the negotiation will be raised.

But even if they think grad school is ridiculous — if you convince them that you’d be totally happy to go to grad school — then the burden is on them to make this deal more attractive to you than going to grad school.

Thus, you need to communicate your BATNA. This doesn’t need to be ham-fisted, but you need to make it a background to the negotiation. (Note: usually whenever you signal your BATNA, you should also re-emphasize your interest in reaching an agreement).

Examples:

“I’ve received another offer from [OTHER CORP] that’s very compelling on salary, but I really love the mission of [YOUR COMPANY] and think that it would overall be a better fit for me.”

“I’m also considering going back to grad school and getting a Master’s degree in Postmodern Haberdashery. I’m excited about [YOUR COMPANY] though and would love to join the team, but the package has to make sense if I’m going to forego a life of ironic hatmaking.”

Note: one of the biggest mistakes I see here is from people who are currently working. If you already have a job, staying where you are is often your BATNA.

This means if you tell your interlocutor that you hate your job, then they know your BATNA sucks, and have no incentive to negotiate with you (on top of potentially thinking that you’re a negative person). Always emphasize the pros of your current company, your seniority, your impact, and whatever else you like about where you currently work.

You should make your decision seem like a genuinely difficult one — then it will appear to be a strong BATNA.

What a Job Negotiation Means to an Employer

I’ve kept saying that in order to be an effective negotiator, you need to understand the other side. So let’s take a look at what it’s like to negotiate as an employer. (I’m going to have to use the tech industry in my examples here, but the details will differ by industry.)

First, we have to rewind and understand what brought us to this offer in the first place. What kind of resources have they spent so far in trying to fill this position?

- Writing and posting a job description on all appropriate channels ($300) - Reviewing ~100 or more resumes ($1,250) - About 15% of those resumes need to be phone screened, so roughly 15 phone screens ($2,250) - Around 75% of those initial phone screens warrant a technical screen, so roughly 11 technical screens ($9,000) - About 30% pass through to an on-site, so roughly 3 onsites. These onsites require the coordination of 6–7 employees ($10,800) - Finally, they make one offer. The recruiter (and potentially the executive staff) need to spend time on the phone with the offeree convincing and negotiating. ($900)

Numbers nabbed from here.

All-in-all this process took about 45 days from start to finish.

Now say you end up turning down their offer. They’ve spent over $24,000 just extending this single offer to you (to say nothing of opportunity costs), and now they’ll essentially have to start over from scratch.

This is what a company faces if you turn them down.

Realize what a gauntlet they’ve been through!

Realize how important it is that you’re the one!

Out of the droves and droves who’ve shown up on their doorstep, you’re the one they want. They want to usher you into their tribe. They went through so much crap to get you here, and now they’ve found you.

And you’re worried that if you negotiate, they’ll take it away?

Further yet, understand that salary is only one part of the cost of employing you. An employer also has to pay for your benefits, your equipment, space, utilities, other random expenses, and employment taxes on top of all of that. All-in, your actual salary often comprises less than 50% of the total cost of employing you.

Which means they expect that your value to the company — in terms of the revenue you’ll generate — to be more than 2x your salary. If they didn’t believe that, they wouldn’t be hiring you at all.

So, this is all to say: everything is stacked in your favor. It doesn’t feel that way, but it absolutely is.

Realize that, while you are agonizing over whether to ask for another few thousand dollars, they’re just praying with bated breath that you’ll sign the offer.

If you don’t sign the offer, they lose. Losing a good candidate sucks. No one wants to believe that their company isn’t worth working for.

They want to win. They will pay to win.

And yet, you might worry: “but if end up negotiating more, won’t they have higher expectations? Won’t my boss end up hating me for negotiating?”

No, and no.

It’s your role that will determine your performance expectations, not how much you negotiated. Making 5k more or less in salary doesn’t matter at all. Your manager will literally just not care about this.

Remember how expensive it is to even employ you in the first place! Nobody’s going to fire you because you’re performing 5K worse than they expected you to. The cost of firing you and hiring someone else is a lot more than 5K to begin with.

And no, your boss won’t hate you now. And in fact, at most big companies the person you’re negotiating with won’t even be your boss. Recruiting and management are totally separate departments, completely abstracted from one another. And even if you’re at a startup, trust me that your boss is used to negotiating with candidates and doesn’t place nearly as much significance on it as you do.

In short: negotiating is easier and more normal than you think. Companies are completely willing to negotiate with you. If your intuition tells you otherwise, trust that your mental model is wrong.

How to Give the First Number

In part 1, I mentioned how valuable it is not to have to give the first number. But there are times when you just can’t avoid it. In these situations, there are ways to give the first number without actually giving the first number.

If a company asks you “what are your salary expectations?” you might say:

“I don’t have any particular numbers in mind. I’m more interested in learning whether this will be a good mutual fit. If it is, I’m open to exploring any offer so long as it’s competitive.”

Sounds good. But they push back, “I understand that, but we need to have a clear idea of what you think is competitive. I need to know whether it’s worth going through the interview process. We’re a young startup, so I need to make sure we’re on the same page as far as compensation.”

That’s a strong push. But you can still push back.

“I completely hear you, and I agree it’s important that we’re on the same page. I really have no particular numbers in my head. It all depends on the fit and the composition of the offer. Once we decide we want to work together, I think that’s the best time to figure out a compensation package that makes sense.”

Most employers will relent here. But there’s a small chance they push further: “Okay, look, you’re being difficult. Let’s not waste each other’s time. What’s an offer that you’d be willing to take?”

This is a decision point. They’re trying to take away your negotiating power and pin you to a premature decision.

That said, you probably will have to say a number at this point, or risk damaging the trust in this relationship. (They are making a valid point that startups can’t offer the same kind of cash as large companies, nor should you expect them to. They might be sensing that you’re not aware of this.)

But you can give a number here without actually giving a number.

“Well, okay. I know that the average software engineer in Silicon Valley makes roughly 120K a year in salary. So I think that’s a good place to start.”

Notice what I did here. I didn’t actually answer the question “what’s an offer you’d be willing to take,” I merely anchored the conversation around the fulcrum of “the average software engineer salary.”

So if you’re forced to give a number, do so by appealing to an objective metric, such as an industry average (or your current salary). And make it clear that you’re merely starting the negotiation there, not ending it.

How to Ask for More

An offer is out there, and now you want to improve it. As always, be direct and ask for what you want. Here are generally the steps you should take.

First, reiterate your interest in the company. This is as simple as “I’m really excited about the problems you guys are working on at Evil Corp…”

Now frame why you’re asking for more. There are two choices here: you can say that you’re on the fence and that an improvement might convince you, or you can go stronger and say that you’re outright dissatisfied with the offer. Which approach you choose depends on how much leverage you have, how weak the offer is relative to your BATNA, and whether you have other offers (the weaker your negotiating position, generally the more tentative you should be).

Either way, be unfailingly polite.

If you’re dissatisfied with the offer, you might say something like “I appreciate the work you guys put into constructing this offer. But there were a couple things I was unsatisfied with.”

If you want to be more reserved, you can say something like:

“The offer you guys extended was strong. Right now my decision is basically between you and [XYZ CORP]. It’s a genuinely difficult decision for me, but there are a couple of dimensions where if this offer improved, it would be much more compelling.”

Don’t just say something like “Thanks for the offer. Here are some ways I think it could improve.” This makes you sound like an ass. Be polite, and if you want to strengthen the offer, tell them clearly how you feel about it. This builds trust and conveys seriousness.

Let’s say you want to raise the salary. Now that you have a specific ask, it’s time to employ rule #7: proclaim reasons for everything.

We all implicitly know the catch-22 of negotiation: if you say you want more salary, you’ll sound greedy. And no one likes greedy people, right? So why would they want to give more money to a greedy person?

I suspect this is the primary reason why so many candidates recoil from negotiating. They don’t want to feel greedy. It goes against all of their social conditioning. And yet, there are some situations in which most people would be totally fine negotiating.

Specifically, when they have to.

If you had to raise your salary or you wouldn’t be able to afford rent, or if you had to negotiate health insurance to cover a medical condition, you’d negotiate without a twinge of regret. The difference? That you have a reason for what you’re requesting.

It’s kind of a brain-hack, both for yourself and for your negotiating partner. Just stating a reason — any reason — makes your request feel human and important. It’s not you being greedy, it’s you trying to fulfill your goals.

The more unobjectionable and sympathetic your reason, the better. If it’s medical expenses, or paying off student loans, or taking care of family, you’ll bring tears to their eyes. I told employers that I was earning-to-give, so since I was donating 33% of my income to charity, I had tonegotiate aggressively to leave myself enough to live off.

But honestly, even if your reason is inane and unimpressive, it will still carry this effect.

Just saying “can you improve the salary?” sounds like you’re boringly motivated by money. But if you say “I really want to buy a house within the next year; what can we do to improve the salary?” This suddenly seems a lot more legitimate.

If they turn down your request now, they’re implicitly telling you “No, Jennifer, you can’t buy your house. I guess you don’t deserve one.” No one wants to do that. They want to be the one who says, “All right Jennifer, I talked with the director and I made it happen. You’re getting that new house!”

(Of course, it goes without saying that you want money so you can spend it on things. I know. It’s stupid. But it works.)

Just go with it, state a reason for everything, and you’ll find recruiters more willing to become your advocate.

Assert your Value

One effective move you can make in a negotiation, especially after an ask, is to emphasize the unique value you’ll be bringing to the company. Example:

“Blah blah blah, I want X, Y, and Z.

I know that you guys are looking for someone to build out your Android team. I believe I bring a lot of experience leading a team of Android developers and I’m confident that I’ll be able to bring your mobile offerings up to parity with your competitors.

Let me know your thoughts.”

Be confident without boasting or trying to hold yourself to specific metrics (unless you’re supremely confident). Whatever you assert should be something you’ve touched on earlier in your discussions. But it’s okay to repeat it now as a gentle reminder. It reminds them of the carrot, and shows that you’re still excited to add value.

This is not appropriate in every negotiation, especially for very junior positions, where it’s harder to differentiate yourself. But later in your career (or for more specialized/consulting roles) this can be a really valuable nudge.

What to Ask For

This brings me to rule #8: be motivated by more than just money.

Note, this is not code for “if you seem like you’re motivated by more than just money, you’ll get more money.”

There is no bigger turn-off to a company than somebody who only cares about money. This is something you’re not going to be able to fake.

Actually be motivated by other things. You should be motivated by money, too, of course, but it should be one among many dimensions you’re optimizing for. How much training you get, what your first project will be, which team you join, or even who your mentor will be — these are all things you can and should negotiate.

Among these factors, salary is perhaps the least important.

What do you really value? Be creative. Don’t try to haggle over slices of cake when there’s so much more on the table.

Of course, to negotiate well you need to understand the other side’s preferences. You want to make the deal better for both of you. That’s why rule #9 is: understand what the company values.

How do you figure this out? Well, there are a few good rules of thumb.

First, salary is almost always the hardest thing to give, for a few reasons:

- It must be paid year after year, so it becomes part of a company’s long-term burn rate. - It is almost always the thing that people gossip about, so paying someone significantly more salary can cause unrest. - It tends to be the most tightly constrained by pay bands, especially at large companies.

So if you want more financial compensation, you should think about structuring as much of it as possible outside of salary. A signing bonus, for example, is easier to give than salary. A signing bonus has the advantage of only needing to be paid once. It gets the candidate excited about joining (because everyone likes wads of cash), and it’s generally not as public.

Remember that you can always get salary raises as you continue to work at the company, but there’s only one point at which you can get a signing bonus.

The easiest thing for a company to give though is stock (if the company offers stock). Companies like giving stock because it invests you in the company and aligns interests. It also shifts some of the risk from the company over to you and burns less cash.

If you are genuinely risk-neutral or early in your career, then you should generally try to assume as much stock as possible. If you aggressively trade cash for stock, you can end up with a higher expected value offer (albeit with higher risk).

A Brief Primer on Equity

First, understand there are two completely different classes of companies: public companies and private companies.

If the company is public (i.e., it has IPO’d and is listed on the stock market), then its stock is as good as cash.

You will usually be granted RSUs (Restricted Stock Units), which are just shares like you can purchase on the stock market. Once these shares vest (that is, are released to you), you can turn around and sell them on the stock market. This is how they turn into money.

If the company is private, then things get a lot more complicated.

For private companies, most of the time they will not actually issue you stock grants. Usually, they will issue you stock options. An option is a pre-agreed right to purchase shares of stock at a frozen price.

It’s important to note that when you want to leave a company, if you have options, your life becomes really complicated. You may have to pay a bunch of money to actually exercise your option (that is, buy your pre-agreed upon stock at the previous frozen price, or risk losing it), with no way to actually sell it yet. The only way to truly liquidate your options is when the company IPOs or is acquired. And many companies don’t ever do this.

Thus, options are very risky. It’s easier to get screwed by options, especially on tax implications. For a lot more information, see this post by Scott Kupor of a16z.

Equity Shenanigans

Many companies will try to play mind games with you when it comes to equity. Several companies pulled these on me.

A common one is presenting the total value of the stock grant rather than the annualized value, despite the stock not vesting evenly, or vesting over 5 years instead of the standard 4.

But the most egregious thing that companies will do is tell you absurd stories about the value of their stock. They’ll say: “okay, we’re worth this much now, but at the rate we’re growing, we’re going to be worth 10X that in a year. So really, the value of your options is many millions of dollars!”

To not mince words: this is cynically dishonest BS. Don’t buy it even for a second. I got this a few times, and the only reason I didn’t walk away from the offer immediately was because it was always a recruiter pulling this crap. If it was a manager I would’ve turned down the offer outright.

Here’s why this is infuriatingly stupid: a company’s valuation is determined by investors. These investors see the financials and the growth rate of the company, and invest at a price that reflects the current growth rate of the company.

In other words, they invested at a valuation that already took their 10x growth rate into account. Investors are not idiots. And unless you (or your recruiter) think you have privileged information or insight that the company’s investors don’t, you should probably take the investors’ word for it.

Also, a company’s nominal valuation is almost always inflated due to preferred shares, debt, and survivorship bias. But let’s ignore that for now.

So if a company gives you this hock of crap, fire back and tell them thank you, but you’ll be considering the stock at the same valuation their investors valued it at.

I mean, be nice. But don’t let them try to strong-arm you into accepting this garbage.

A job is not a suicide pact. Choose a company that is judicious and transparent, and you’ll be much more likely to find yourself respected and taken care of.

Other things you can ask for

Because I’d be remiss if I didn’t point out a few other things.

Relocation expenses often come out of separate budgets at big companies, so this is generally very easy to get.

Look for creative benefits that would be particularly valuable to you. Maybe it’s covering your commuter expenses, asking for dedicated volunteer or learning time, getting sponsored for conferences, or even charity donation matching.

Don’t assume anything’s off the table until you’ve tried bringing it up.

That said, don’t throw the entire kitchen sink at them. A negotiation can quickly become cumbersome for an employer if you bring up a litany of changes. Keep the changeset as pithy as you can.

Negotiating Jiu Jitsu

Recruiters love trying to trick you into ending the negotiation early. They’re going to do this relentlessly. Don’t fault them for it — I suspect they can’t help themselves.

Just keep breaking out of their shenanigans. Don’t let yourself be pressured into ending a negotiation until you’re actually ready to make a final decision.

This is especially grave if you have multiple offers, and you let one company pressure you into canceling the others. Companies succeed in doing this all the time, so I want to equip you with the skills to jiu jitsu out of these techniques.

Here are two situations you can break out of. These are both real situations that happened to me during my negotiations, though the numbers and details are invented.

Situation 1:

I ask for a 10K increase in signing bonus. The company gets back to me and says, “That’s really tough for us to do. I’m going to try. I think you’re worth it. But I can’t really go to my boss and fight for you unless she knows you’re going to sign. Are you going to sign if I get you that 10K?”

You should be thinking: ah, this person is trying to force me to a decision point and take away my negotiating power.

I respond, “Okay, so what I’m hearing is that you’ll have to expend some personal reputation to get me a 10K bonus. If you end up going to bat for me, are you confident you’ll be able to get that 10K?”

“I think I can, it just comes down to you Haseeb. If you’re serious about joining us, then I’ll go fight for you. But I need to know for sure you’ll sign.”

Great. Time to jiu jitsu.

“That makes sense. Unfortunately I can’t commit to signing yet; I’m not yet at the stage where I can make a final decision. Like I told you before, this weekend I’m going to sit down with my family and talk things over with them. Choosing the company I’m going to spend the next few years at is a commitment I take really seriously. So I want to be sure I’m making a well-considered decision.

“But since you’re confident that you can get an extra 10K, let’s do this instead: in my mind, I’ll pretend this offer is [X + 10K] and as I’m considering my final decision, that’s where I’ll value it. I know it’s tough for you to go and get that from your boss, so I don’t want you to do that until I’m certain I’m going to sign.”

They then vaguely recant and promptly get approval for the 10K bonus.

Situation 2:

I ask for a 20% increase in stock package. The hiring manager, knowing that I’m negotiating with other companies, then fires back: “I want to get this stock package for you. And I know I can, we’ve got the budget. But before I do that, I need your word on something.”

“What’s that?”

“I need you to give me your word that if I improve your offer, you’re not going to just turn around and take our counter-offer to [COMPETITOR_COMPANY] to improve your offer with them.”

You should be thinking: so basically they’re asking me not to negotiate.

“Let me see if I understand what you’re saying. You are willing to improve my offer, but only if I agree that I won’t tell [COMPETITOR] what you’re offering me. Is that correct?”

“Well no, I can’t legally do that. What I mean is… what I mean is, look. I like you. But if I improve your offer and you just take our offer to [COMPETITOR], you’ll be violating my trust.”

“Okay, let me be sure I understand you here. If you give me this offer and I tell [COMPETITOR], I will be violating the trust under which you’re granting me this improved offer. Is that correct?”

“Uhh… Look. How about this. In my mind, I’m going to go get you this stock package okay? And in my head, I’m going to do it with the assumption that you’re the kind of person I think you are, and you’re going to consider our offer in its own right and not just shop it around. Fair enough?”

I nod. He gets the improved offer. I continue to negotiate. Antics averted.

(In case you’re wondering, if he had said “yes,” I would have turned down the proposal.)

The Path to Signing

It’s not enough to just continually ask for stuff. Companies need to sense that you’re actually moving toward a final decision, and not just playing games with them.

Your goal in a negotiation is not to be difficult or elusive. True, you should assert your value and carefully consider your options, but you can do so in a way that’s respectful and considerate toward the companies you’re talking to.

Don’t go dark on people. Be open and communicative. I keep saying be honest and I mean it — be honest.

Aside: I keep talking about honesty, and you might protest that this is antithetical to my earlier rule of “protect information.” It’s not. True, you should protect information that might weaken your negotiating position, but you should be as communicative as possible about everything else (which is most things).

Negotiating is all about relationship, and communication is the bedrock of any relationship.

This brings me to the final rule, Rule #10: be winnable. This is more than just giving the company the impression that you like them (which you continually should). But more so that you must give any company you’re talking to a clear path on how to win you. Don’t BS them or play stupid games. Be clear and unequivocal with your preferences and timeline.

If there is nothing that a company could do to sign you, or you don’t actually want to work for them, then don’t negotiate with them. Period.

Don’t waste their time or play games for your own purposes. Even if the company isn’t your dream company, you must be able to imagine at least some package they could offer you that would make you sign. If not, politely turn them down.

It costs each company money to interview you and to negotiate with you. I didn’t negotiate with every company I received an offer from, but if there was one key mistake I made in my job search, it was that I still negotiated with too many (in large part because I didn’t think my job search would be successful).

Making the Final Decision

Okay, it’s decision time.

(Yes, you do have to make one.)

Three things to keep in mind here:

- be clear about your deadline - assert your deadline continually - use your final decision as your trump card

When you start negotiating, you don’t have to be clear about your timeline because you probably don’t have one yet. But once you get into intermediary stages, you should set for yourself a deadline on which you’ll sign. It can be for an arbitrary reason (or no reason at all), but just pre-committing to a deadline will allow you to negotiate more clearly and powerfully.

“A weekend with the family” I found works nicely, as it has the added benefit of roping other decision makers in. Then when companies push you to end negotiations early, you can re-assert this deadline.

Companies should all be totally aware of when you’re going to make your decision. This will raise the stakes and galvanize negotiations as the deadline approaches.

This deadline also lets you defer your decision while still improving offers. Your narrative should basically be “I want to see the strongest offer your company can muster. Then I will go into my cave, meditate for 10 days, and when I emerge I will have decided in my heart which company to join.” This gives you enormous power to avoid any on-the-spot decision points or premature promises.

Eventually, deadline day will come. Try to make this a business day (say, a Friday or a Monday) so that you can communicate with recruiters during this day. If a hail mary is going to happen, it’ll happen here.

Even if there’s only one company in the running, you should always always wait until the last day to sign your offer. Yes, even if you’re certain you’re going to sign and even if it’s your dream job. I’ve seen many scenarios in which offers spontaneously improved as deadlines approached, or a fallen player gets up and presents you the holy grail in the 11th hour. Either way, there’s no harm.

Finally, your trump card. Save this for the very end. Your trump card is these words:

“If you can do X, I will sign.”

Note, this is NOT “If you give me X, the offer will be more compelling blah blah blah.” We’re past that. It’s time to make a promise.

Every company that’s still on the table, let them know what it would take to sign you (unless there’s nothing they could do). And when you make the final ask, don’t forget reason-giving, even if it’s the same reason as before!

“Hi Joel, I’ve been thinking it over and it’s genuinely a really tough decision for me. I loved everyone at [COMPANY] but the one thing that makes it hard for me is the salary. As you know I’m trying to pay off my student loans so salary is really important to me right now. If you can improve the salary by 10K a year, then I’ll be totally ready to sign.”

With luck, they meet you half-way. Or, with a little more luck, they’ll meet all of it.

And just because I know someone will ask — yes, once say you’re going to sign, you should always sign. Never go back on your word. It’s a small world. People talk. These kind of things will come back to haunt you. (More importantly, never go back on your word because you’re the kind of person who never goes back on their word.)

Tell all of the other parties that you’ve made your final decision. Thank them for the negotiation. If you did it well, they’ll usually thank you back, tell you to keep in touch, and to reach out again in a couple years next time you’re on the market.

And that’s it. You did it! Congratulations! You’re still alive, right?

… You’re not moving.

Well, that’s fine. It’s time to celebrate your new job, you beautiful fool! (Drinks are on you.)

If you got some value out of this article, share it with a friend who’d benefit from it. Or better yet, follow me on Twitter and I can be your friend.

There’s a lot more in the works.

Until next time,

—Haseeb

 

For Haseeb's first software developer job, he was able to negotiate a total compensation package of US $250,000 for his first year at Airbnb. He believes negotiation is a skill that can be learned, just like any other. And it isn't particularly elusive or hard to understand. In this episode, he explains how anyone can negotiate effectively.

Written and Read by Haseeb Qureshi: https://twitter.com/hosseeb

Haseeb's original article: https://fcc.im/2FiLq0v

Learn to code for free at: https://www.freecodecamp.org

Intro music by Vangough: https://fcc.im/2APOG02

Transcript: 

When the story of how I landed a job at Airbnb went viral, I was surprised at how infatuated people were with my negotiations. Media stories portrayed me as some kind of master negotiator — a wily ex-poker-player who was able to con the tech giants into a lucrative job offer.

This is silly. It’s silly for a lot of reasons, but one of the main ones is that in reality, my negotiation skills are nothing special. There are lots of job candidates who are better negotiators than I, to speak nothing of recruiters and other professional negotiators.

It just so happens that most people don’t negotiate at all, or if they do, they negotiate just enough to satisfy themselves that they did.

Worse yet, most of the advice out there on negotiation is borderline useless. Almost anything you read on the subject will be a vague and long-winded exhortation to “make sure you negotiate” and “never say the first number.” Beyond those two morsels of advice, you’re pretty much on your own.

I thought to myself: why is there so little actionable advice out there about negotiation? I suspect it’s because deep down, many people believe that negotiation is inexplicable, that it’s something some people can do and others can’t, and that there’s no real way to break it down so anyone can learn it.

I say that’s BS. Negotiation is a skill that can be learned, just like any other. I don’t believe it’s particularly elusive or hard to understand. So I’m going to try to explain how anyone can do it.

Three caveats.

First: I’m not an expert. There are people who really are experts at this, and when my advice contradicts theirs, you should assume I’m wrong.

Second: negotiation is tricky to generalize about because it’s deeply intertwined with social dynamics and power. The appropriate advice for an Asian male in Silicon Valley may not be appropriate for a black woman in Birmingham, Alabama. Racial, sexual, and political dynamics accompany you to the negotiating table.

At the same time, I want to caution against overemphasizing these factors. Being afraid to negotiate out of fear of discrimination can often be just as deleterious as discrimination itself.

Ceteris paribus, negotiate aggressively.

Third: I’m the first to admit that negotiation is stupid. It’s a practice that inherently benefits those who are good at it, and is an absurd axis on which to reward people. But it’s a reality of our economic system. And like most collective action problems, we’re probably not going to be able to abolish it any time soon. In which case, you might as well improve at it.

So here’s my guide to negotiation. It’s going to be split into two parts: this first part will be about conceptualizing the negotiating process, about how to begin the process and set yourself up for maximal success. The second part will be advice on the actual back-and-forth portion of negotiating and how to ask for what you want.

Let’s take it from the top.

What it means to “get a job”

In our culture we call entering the employment market “trying to get a job.” This is an unfortunate turn of phrase. “Getting a job” implies that jobs are a resource out in the world, and you’re attempting to secure one of these resources. But that’s completely backwards. What you are actually doing is selling your labor, and a company is bidding for it.

Employment is just striking a mutual deal in the labor market.

Like any market, the labor market only functions well if it’s competitive. This is the only way to ensure fair and equitable pricing. Imagine you were a farmer selling watermelons. Would you just sell your watermelons to the first buyer who agreed to purchase them? Or would you survey the marketplace of buyers, see the best price (and business partner) you could get, and then make an informed decision on which buyer to sell to?

And yet, when people talk about the labor market, they think “oh, a company wants to give me a job! What a relief!” As though having a job were in itself some special privilege for which a company is the gatekeeper.

Dispel yourself of this mindset.

A job is just a deal. It is a deal between you and a company to exchange labor for money (and other things you value).

This might sound like an abstract point, but you should absolutely approach negotiation from this perspective.

The role of negotiation

Negotiating is a natural and expected part of the process of trying to make a deal. It’s also a signal of competence and seriousness. Companies generally respect candidates who negotiate, and most highly attractive candidates negotiate (if for no other reason, because they often have too many options to choose from).

At the risk of spouting truisms: always, always negotiate. It doesn’t matter how good or bad you think you are. You never damage a relationship by negotiating.

In all my time as an instructor at App Academy, out of hundreds of offers negotiated, only once or twice were offers ever rescinded in negotiations. It basically never happens. And when it does, usually the candidate was being an unconscionable asshole, or the company was imploding and needed an excuse to rescind the offer.

You might think to yourself: “well, I don’t want to set high expectations, and the offer is already generous, so I ought to just take it.”

No. Negotiate.

Or maybe: “I don’t want to start off on the wrong foot and look greedy with my future employer.”

No. Negotiate.

“But this company is small and — “

No. Shut up. Negotiate.

We’ll talk more in the next section about why a lot of these objections are BS, and fundamentally misapprehend the dynamics of hiring. But for now, just trust me that you should always negotiate.

The ten rules of negotiating I’ve tried to boil down negotiation to ten rules. The rules, in order of appearance, are:

- Get everything in writing - Always keep the door open - Information is power - Always be positive - Don’t be the decision maker - Have alternatives - Proclaim reasons for everything - Be motivated by more than just money - Understand what they value - Be winnable

We’ll only get through some of these in this blog post, and the rest will appear in the second part. But I’ll explain each rule as we get to it.

So let’s start from the top and try to walk through a negotiation process from the very beginning. For most, that starts when you receive an offer.

The offer conversation

You’ve just received the phone call: your interview went well, and after much deliberation they decided they like you. They want to make you an offer. Congratulations!

Don’t get too excited though. The fun is just getting started.

Thank your recruiter. Sound excited — hopefully this won’t be hard. Before jumping into details, try to ask for specific feedback on your interview performance. If they give it to you, this will help you gauge how much they want you, as well as tell you things you can improve on in your next interview(s).

Now time to explore the offer.

Rule #1 of negotiating: have everything in writing.

Eventually, they’ll give you information about the offer. Write it all down. Doesn’t matter if they’re going to send you a written version later, write everything down. Even if there are things that are not directly monetary, if they relate to the job, write them down. If they tell you “we’re working on porting the front-end to Angular,” write that down. If they say they have 20 employees, write that down. You want as much information as you can. You’ll forget a lot of this stuff, and it’s going to be important in informing your final decision.

Depending on the company, they’ll also tell you about the equity package. We’ll look more specifically at equity in part II, but be sure to write everything down.

The rule from here on out is that everything significant you discuss will have some kind of a paper trail. Often, the company won’t even send you an official offer letter until a deal is finalized. So it falls to you to confirm all of the important details in subsequent e-mails.

So yadda yadda, lots of details, writing stuff down, oh there’s a joke, time to laugh. Now the recruiter is done talking and you’re done asking all of your questions.

Your recruiter will now say something along the lines of “so what do you think?”

This seems innocuous, but your reply here is critical, because there’s a lot you can say to weaken your position. This is your first decision point.

A decision point is a moment in the negotiation where your interlocutor wants to compel you to make a decision. If they succeed in tying you to a position, they will close the door on further negotiating. Of course “what do you think?” is a subtle prod. But it is the beginning of many attempts to get you to make a premature commitment.

This leads to rule #2 of negotiating: always keep the door open. Never give up your negotiating power until you’re absolutely ready to make an informed, deliberate final decision.

This means your job is to traverse as many of these decision points as possible without giving up the power to continue negotiating. Very frequently, your interlocutor will try to trick you into making a decision, or tie you to a decision you didn’t commit to. You must keep verbally jiu-jitsu-ing out of these antics until you’re actually ready to make your final decision.

Protecting information

There’s an uncomfortable silence by now, and their “what do you think?” is hanging in the air.

If you say “yes, that sounds amazing, when do I start?” you implicitly accept the offer and completely close the door on the negotiation. This is your recruiter’s number one favorite thing to hear. It stands to reason you probably shouldn’t do this.

But their second favorite thing to hear you say is “can you do 90K instead of 85K?” This also closes the door, but for a different and more subtle reason. And it’s the number one reason why most people suck at negotiation.

Rule #3 of negotiating: information is power. To protect your power in the negotiation, you must protect information as much as possible.

A company doesn’t give you insight into what it’s thinking. It doesn’t tell you its price range, how much it paid the previous candidate with your experience, or anything like that. It intentionally obfuscates those things. But it wants you not to do the same.

A company wants to be like a bidder in a secret auction. But unlike the other bidders, it wants to know exactly how high all of the other bids are. It then openly intends to exploit that knowledge, often by bidding one cent more than the second highest bid.

Yeah, no. Screw that. It’s a silent auction, and to keep it that way, you must protect information.

In many situations, the only reason why you have any negotiating power at all is because the employer doesn’t actually know what you’re thinking. They might not know how good your other offers are, or how much you were making in your last job, or how you weigh salary vs equity, or even how rational you are as a decision-maker. Bottom line, you want them to be uncertain on exactly what it would take to sign you.

When you say “can you do 90K instead of 85K,” you’ve told them exactly what it will take to make you sign. The sheet’s pulled back, the secret auction is up, and they’re going to bid 90K (or more likely, 87K). And they know there’s almost no risk in doing so, because you’ll probably accept.

What if you were the kind of person who wouldn’t even consider an offer below 110K? Or the kind of person who wouldn’t consider an offer below 120K? If you were, you wouldn’t ask for 90K, and if they offered it as conciliation, you’d tell them to stop wasting your time.

By staying silent, they don’t actually know which of those kinds of people you are. In their mind, you could be any of the three.

A corollary of this rule is that you should not reveal to companies what you’re currently making. There are some exceptions, but as a rule you should assume this. If you must divulge what you’re making, you should be liberal in noting the total value of your package (incorporate bonuses, unvested stock, nearness to promotion etc.), and always mention it in a context like “[XYZ] is what I’m currently making, and I’m definitely looking for a step up in my career for my next role.”

Companies will ask about your current compensation at different stages in the process — some before they ever interview you, some after they decide to make you an offer. But be mindful of this, and protect information.

So given this offer, don’t ask for more money or equity or anything of the sort. Don’t comment on any specific details of the offer except to clarify them.

Give away nothing. Retain your power.

Say instead:

“Yeah, [COMPANY_NAME] sounds great! I really thought this was a good fit, and I’m glad that you guys agree. Right now I’m talking with a few other companies so I can’t speak to the specific details of the offer until I’m done with the process and get closer to making a decision. But I’m sure we’ll be able to find a package that we’re both happy with, because I really would love to be a part of the team.”

Think like the watermelon farmer. This offer is just the first businessman who’s stopped by your watermelon patch, glanced over your crops, and announced “I’ll take all of these right now for $2 a melon.”

Cool. It’s a big market, and you’re patient — you’re a farmer after all. Just smile and tell them you’ll keep their offer in mind.

And this is super important: always be unequivocally positive.

The importance of positivity

Staying positive is rule #4 of negotiation. Even if the offer sucks, it’s extremely important to remain positive and excited about the company. This is because your excitement is one of your most valuable assets in a negotiation.

A company is making you an offer because they think you’ll do hard work for them if they pay you. If you lose your excitement for the company during the interview process, then they’ll lose confidence that you’ll actually want to work hard or stay there for a long time. Each of those makes you less attractive as an investment. Remember, you are the product! If you become less excited, then the product you’re selling actually loses value.

Imagine you were negotiating with someone over buying your watermelons, but the negotiation took so long that by the time you’d reached an agreement, your watermelons had gone bad.

Companies are terrified of that. They don’t want their candidates to go bad during a negotiation. Hence why they hire professional recruiters to manage the process and make sure they remain amicable. You and the recruiter share the same interest in that regard. If a company feels like you’ve gone bad, suddenly they’re a lot less willing to pay for you.

So despite whatever is happening in the negotiation, give the company the impression that 1) you still like the company, and that 2) you’re still excited to work there, even if the numbers or the money or the timing is not working out. Generally the most convincing thing to signal this is to reiterate you love the mission, the team, or the problem they’re working on, and really want to see things work out.

Don’t be the decision-maker

You can wrap up the conversation now by saying:

“I’ll look over some of these details and discuss it with my [FAMILY / CLOSE_FRIENDS / SIGNIFICANT_OTHER]. I’ll reach out to you if I have any questions. Thanks so much for sharing the good news with me, and I’ll be in touch!”

So not only are you ending the conversation with the power all in your hands, but note there’s another important move here: you’re roping in other decision-makers.

Rule #5 of negotiation: don’t be the decision-maker. Even if you don’t particularly care what your friends/family/husband/mother thinks, by mentioning them, you’re no longer the only person the recruiter needs to win over. There’s no point in them trying to bully and intimidate you; the “true decision-maker” is beyond their reach.

This is a classic technique in customer support and remediation. It’s never the person on the phone’s fault, they’re just some poor schmuck doing their job. It’s not their decision to make. This helps to defuse tension and give them more control of the situation.

It’s much harder to pressure someone if they’re not the final decision-maker. So take advantage of that.

Okay!

We have our first offer. Send a follow-up e-mail confirming all of the details you discussed with your recruiter so you have a paper trail. Just say “just wanted to confirm I had all the details right.”

Groovy. Next step is to leverage this to land other offers and find the best deal we can find in the job market.

Getting other offers

Turns out, it doesn’t matter that much where your first offer is from, or even how much they’re offering you. Just having an offer in hand will get the engine running.

If you’re already in the pipeline with other companies (which you should be if you’re doing it right), you should proactively reach out and let them know that you’ve just received an offer. Try to build a sense of urgency. Regardless of whether you know the expiration date, all offers expire at some point, so take advantage of that.

“Hello [PERSON], I just wanted to update you on my own process. I’ve just received an offer from [COMPANY] which is quite strong. That said, I’m really excited about [YOUR AMAZING COMPANY] and really want to see if we can make it work. Since my timeline is now compressed, is there anything you can do to expedite the process?”

Should you specifically mention the company that gave you an offer? Depends. If it’s a well-known company or a competitor, then definitely mention it. If it’s a no-name or unsexy company, you should just say you received an offer. If it’s expiring soon, you should mention that as well.

Either way, send out a letter like this to every single company you’re talking to. No matter how hopeless or pointless you think your application is, you want to send this signal to everyone who is considering you in the market.

Second, if there are any other companies you are looking to apply to (whether through referral or cold application), or even companies at which you’ve already applied but haven’t heard back, I would also follow up with a similar e-mail.

So why do this? Isn’t this tacky, annoying, or even desperate?

None of the above. It is the oldest method in history to galvanize a marketplace — show that supplies are limited and build urgency. Demand breeds demand. Not every company will respond to this, but many will.

Isn’t it stupid that companies respond to this though?

Why companies care about other offers

When I wrote about the story of my own job search, I mentioned how having an offer from Google made companies turn around and expedite me through their funnels. Many commentators lamented at the capriciousness of these companies. If Uber or Twitch only talked to me because of Google and until then weren’t willing to look at me, what did that say about their hiring processes? What legitimately are they evaluating, if anything at all?

I think this response is totally backwards. The behavior of tech companies here is actually very rational, and you would do well to understand it.

First, you must realize what a company’s goal is. A company’s goal is to hire someone who will become an effective employee and produce more value than their cost. How do you figure out who will do that? Well, you can’t know for certain without actually hiring them, but there are a few proxies. Pedigree is the strongest signal; if they did it at other companies, they can probably do it at yours. And if someone trusted within the organization can vouch for them, that’s often a strong signal as well.

But turns out, almost everything else is a weak signal. Weak in the sense that it’s just not very reliable. Interviews, if you think about it, are long, sweaty, uncomfortable affairs that only glancingly resemble actual employment. They’re weird and can’t tell you that much about whether an individual will be good at their job. There’s no way around this. There are a few stronger signals, like bringing someone in for a week or two on a contract-to-hire position, but strong candidates won’t consider this. So candidates as a whole have effectively forced companies to assume almost all of the risk in hiring.

The truth is, knowing that someone has passed your interview just doesn’t say that much about whether they’ll be a good employee. It’s as though you knew nothing about a student other than their SAT score. It’s just not a lot of data to go off.

Nobody has solved this problem. Not Google nor anyone else.

And this is precisely why it’s rational for companies to care that you’ve received other offers. They care because each company knows that their own process is noisy, and the processes of most other companies are also noisy. But a candidate having multiple offers means that they have multiple weak signals in their favor. Combined, these converge into a much stronger signal than any single interview. It’s like knowing that a student has a strong SAT score, and GPA, and won various scholarships. Sure, it’s still possible that they’re a dunce, but it’s much harder for that to be true.

This is not to say that companies respond proportionally to these signals, or that they don’t overvalue credentials and brands. They do. But caring about whether you have other offers and valuing you accordingly is completely rational.

So this is all to say — tell other companies that you’ve received offers. Give them more signal so that they know you’re a valued and compelling candidate. And understand why this changes their mind about whether to interview you.

As you continue interviewing, remember to keep practicing your interview skills. The single strongest determinant of your final offer will be the number and strength of offers that you receive.

Some advice on timing

You want to be strategic about the timing of your offers. Generally, you should try to start interviewing at larger companies earlier. Their processes are slower and their offer windows are wider (meaning they allow you more time to decide). Startups are the other way around.

Your goal should be to have as many offers overlapping at the same time as possible. This will maximize your window for negotiating.

When you receive an offer, often the first thing you should ask for is more time to make your decision. Especially in your first offer, more time is by far the most valuable thing you can ask for. It’s time that enables you to activate other companies and end up with the strongest possible offer. So be prepared to fight for time.

How to approach exploding offers

Hoo boy.

Exploding offers are offers that expire within 24–72 hours. You won’t see this much at big companies, but they’re becoming increasingly common among startups and mid-sized companies.

Exploding offers suck, and I share most people’s disdain for this practice. But I do understand it. Exploding offers are a natural weapon for employers to combat a strong hiring market for tech workers. Companies know exactly what they’re doing with exploding offers — they play on fear and limit your ability to seek out counteroffers.

In a sense, it’s unsurprising that if startups have more difficulty attracting and securing talent, they’d resort to this practice. What I don’t like is the dishonesty about it. Employers often justify this by saying:

“If you need more time than this, then that’s a sign you’re not the kind of person we’re looking for.”

Please don’t buy this crap or feel guilty over it. They’re simply doing this to improve their chance of closing candidates. Needing more than three days to make a life decision isn’t a sign of anything other than thoughtfulness.

So what should you do if you receive an exploding offer?

Exploding offers are anathema to your ability to effectively navigate the labor market. Thus, there is only one thing to do. Treat the offer as a non-offer unless the expiration window is widened.

In no uncertain terms, convey that if the offer is exploding, it’s useless to you.

Example conversation:

“I have one big concern. You mentioned that this offer explodes in 48 hours. I’m afraid this doesn’t work at all for me. There’s no way that I can make a decision on this offer within a 48 hour window. I’m currently wrapping up my interview process at a few other companies, which is likely to take me another week or so. So I’m going to need more time to make an informed decision.”

If they push back and say this is the best they can do, then politely reply:

“That’s really unfortunate. I like [YOUR COMPANY] and was really excited about the team, but like I said, there’s no way I can consider this offer. 48 hours is just too unreasonable of a window. The next company I join will be a big life decision for me, and I take my commitments very seriously. I also need to consult with my [EXTERNAL_DECISION_MAKER]. There’s no way that I can make a decision I’m comfortable with in this short an amount of time.”

Pretty much any company will relent at this point. If they persist, don’t be afraid to walk away over it. (They probably won’t let that happen, and will come grab you as you’re walking out the door. But if they don’t, then honestly, screw ‘em.)

I was given several exploding offers during my job search. And every time, I did essentially this. Every single offer immediately widened to become more reasonable, sometimes by several weeks.

I want to emphasize, lest I be misunderstood here — what I’m saying is not to just silently let an exploding offer expire, and assume that everything will be fine and they’ll still hire you. They won’t. For exploding offers to be a credible weapon, a company has to have a reputation of enforcing them. I’m saying explicitly call this out as an issue when they make the offer.

Don’t let a company bully you into giving away your negotiating power.

The Negotiating Mindset

Before we enter into the actual back-and-forth, I want to examine the mindset you should have as a negotiator. This applies not just to how you approach the conversation, but also to how you think about the company.

Do not fall into the trap of valuing companies solely along one dimension. That means don’t just value companies based on salary, equity, or even on prestige. Those are all important dimensions, but so are cultural fit, the challenge of the work, learning potential, later career options, quality of life, growth potential, and just overall happiness. None of these inherently trump any of the other. Anyone who tells you “just choose wherever you think you’ll be happiest” is being just as simplistic as someone who says “just choose the one that offers the most money.” All of these things matter, and your decision should be genuinely multi-dimensional.

Be open to being surprised as you explore different companies.

It’s also important to understand that companies don’t all value you along the same dimension either. That is, different companies are genuinely looking for different skills, and there are some companies at which you will be more and less valuable. Even at peer companies this is true, especially so if you have a specialized skill-set.

The more companies you talk to, the more likely you are to find a company to which you are significantly more valuable than the rest. Chances are this is where you’ll be able to negotiate your strongest offer. It might surprise you which company this turns out to be; keep an open mind, and remember that a job search is a 2-sided process.

One of the most valuable things you can do for yourself in this process is to really try to understand how employers think and what motivates them. Understanding your interlocutor is extremely important in negotiation, and we’ll be exploring that a lot in the next blog post.

But most of all I want to emphasize: be curious about the other side. Try to understand why employers think the way they do. Be sympathetic toward them. Care about what they want and help them try to get it. Adopting this mindset will make you a much stronger negotiator, and accordingly, a much better employee and team member.

Okay. That’s as far as we’re going for today. In the next blog post, I’m going to cover the last four rules of negotiation. I’ll also go over the actual back-and-forth process — how to ask for what you want, how to strengthen offers, and how to dismantle the tricks that companies will try to pull on you. Also a lot more on the theory of negotiation, which I really dig.

Roger explains why everyone should learn to code, even if they don't intend to go pro. "Learning something difficult, however, is beneficial in and of itself. The process is the prize. Struggling with code, while frustrating, is medicine for the mind."

Written and Read by Roger Collier: https://twitter.com/RogerAFCollier

Original article: https://fcc.im/2keLLrU

Learn to code for free at: https://www.freecodecamp.org

Intro music by Vangough: https://fcc.im/2APOG02

Transcript: 

It was far past midnight. My wife and kids had long gone to bed. But sleep was not an option for me. I had to figure it out. So I tweaked the code again, for the googolth time, and hit run.

Hmm, looks promising.

If I click here, the program should call the “compute next move” function. Yes. And if I click here, that function should call itself. Good. Now, if I click here, I should get…not that.

Argh.

More tweaks. More errors. More hours tick by.

Learning programming is hard, I thought. My next thought?

Yes, and that’s why I like it.

How programming became my hobby

I began to learn how to code using JavaScript four months ago, starting with freeCodeCamp’s front-end curriculum. For me, programming became a hobby.

Over the past few years, I had become disappointed with my creation-to-consumption ratio. Too much of my free time was spent consuming. Netflix, podcasts, Twitter, magazines, televised sports, Facebook, blogs, Medium, newspapers, novels — the list goes on.

There is nothing wrong with any of these activities, but they are all pure input. Even reading a great book is an act of consumption.

Sure, I was generating plenty of output in my job as a journalist, but I could no longer accept the fact that hard work was something I did only when it would result in a paycheck.

With a family and a career and other obligations, I had only so much free time. I was spending far too much of it scarfing down media. And I felt like a pig.

So far, my programming hobby hasn’t result in all that much output. I made one simple app, which I wrote about in a previous article. I’ve completed all the front-end challenges and projects on freeCodeCamp.

But it’s a start. My goal is not to create amazing things to impress people. It is simply to immerse myself in the act of creation, to challenge myself, to attempt something difficult — if for no other reason than to finish it.

Harder is better

In my home province — Ontario, Canada — there is a movement to improve physical health called Make Your Day Harder. The basic premise is that making small tweaks to daily routines to increase physical activity can add up and improve health.

Take the stairs instead of the elevator. Get off the bus one stop before your destination. Take the parking spot farthest away from the entrance at work.

I couldn’t agree more. Those elevator-hating far-parkers are onto something.

Of course, sitting in front of a computer writing code isn’t going to improve your physical health. JavaScript is great for building apps, not abs.

I don’t think it’s too much of a stretch, though, to suggest that learning how to program is healthy for your brain. Healthier, at least, than bingeing Iron Fist or thumbing through celebrity Instagram accounts.

For me, even after I started coding, the default during downtime is still too often leisure. This month, for instance, I have already spent dozens of hours watching genetic outliers throw a ball at a metal ring. This is otherwise known as the NBA playoffs. Since I’m a Toronto Raptors fan, you could also call it self-induced torture.

Does watching so much basketball — alone, in my basement — benefit me in any way? Well, I drink more beer when I watch sports. I eat more nachos and wings and potato chips. Mike and Ikes have made several appearances. Oh, and I often stay up late to watch the West Coast games, so I’m getting less sleep.

In other words, watching sports, for me, is a vice. I enjoy it, but it’s actually bad for me. It provides me with entertainment, but nothing else. Except for love handles and the occasional mid-afternoon yawn attack.

But it’s easy. It’s oh so easy. Plop on couch. Crack open Corona. Kick up your feet. Sit there for three hours.

The easy path is more tempting. The difficult path is more rewarding.

Embracing difficulty

I was again reminded of the value of embracing difficulty while watching the movie Hidden Figures. The film featured an excerpt of John F Kennedy’s “We choose to go to the moon” speech. The United States pursued space travel not despite it being difficult, the president declared, but rather because it was difficult.

“We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win, and the others, too.” — John F Kennedy

The words “hard” and “difficult” are often used to describe something negative. In many cases, that’s appropriate. It is hard to watch a loved one fall ill and suffer. It is difficult when a relationship fails or a pet dies. Some situations are all pain, no profit.

Learning something difficult, however, is beneficial in and of itself. The process is the prize. Struggling with code, while frustrating, is medicine for the mind.

If you happen, along the way, to create something amazing and users flock to your app with open wallets, that’s great. If not, code anyway. If you master JavaScript and become a YouTube guru with more subscribers than the New York Times, that’s great. If not, code anyway.

Many people learn programming to attain a specific goal. Perhaps your job is boring and you want a more challenging one. Nothing wrong with that. Maybe you want to break into tech because you need a higher income to support your family. Hey, someone has to buy the bagels and flip flops, and keep the WiFi pumping.

But you don’t need an endgame in mind to start your coding journey. Just begin. And if that journey becomes difficult, don’t despair. It means you’re on the right path. The hard one.

 

Genius is a fickle beast. Sometimes you have the good fortune to work with a mad genius. Other times you are doomed to work with pure madness. There are also times when it is hard to tell the difference.

In this episode we explore "brilliant jerks" and how to save your development team from them.

Written and Read by: Jonathan Solórzano-Hamilton

Follow him on Twitter: https://twitter.com/jhsolor

His full article on freeCodeCamp's Medium publication: https://fcc.im/2BAhnm6

Learn to code for free at: https://www.freecodecamp.org

Intro music by Vangough: https://fcc.im/2APOG02

 

Transcript:

“You will never be able to understand any of what I’ve created. I am Albert F***ing Einstein and you are all monkeys scrabbling in the dirt.”

And so our resident genius, our Dr. Jekyll, explosively completed his transformation into Mr. Hyde.

He declared this in front of the product design team, developers, management, and pre-launch customers. One of our project sponsors had the temerity to ask when the problem crippling our product would be fixed.

Genius is a fickle beast. Sometimes you have the good fortune to work with a mad genius. Other times you are doomed to work with pure madness. There are also times when it is hard to tell the difference.

This story is about the fall from grace of an extremely gifted team member with a deep understanding of our product’s architecture. He had an uncanny ability to forecast future requirements, and a ton of domain-specific knowledge.

He was our top contributor. He was killing our flagship project.

We’ll call this person “Rick.”

Rick was universally recognized on the team as the top talent. He was the lead developer and architect of our software projects.

Any time anyone had a question about code or needed help with a task, they would go to Rick. Rick had a giant whiteboard installed in his office used only for this purpose. It was always cluttered with the ghosts of past discussions that wouldn’t quite erase.

Any time there was a particularly challenging problem, Rick would handle it. Rick had a server with the same specs as our production server installed at his desk. He used this to run the entire application stack independently and troubleshoot every layer at once.

Rick didn’t need anybody else. Rick preferred to work alone in his private work-space.

Rick didn’t need anything anybody else built. He built everything he needed from scratch because it was infinitely better than the paltry offerings of mere mortals.

Soon, Rick stopped attending meetings. Rick didn’t have time for meetings any more because there was too much to code.

Rick closed his door. His whiteboard lay fallow. Rick no longer had time to train anyone because he had too much to solve on his own.

A backlog grew behind Rick. Bugs were popping up in old tools he’d built. They sapped his attention from meeting commitments on new product development.

Of course, these bugs were happening because the users had misstated their assumptions. Of course there wasn’t any problem in his work. Of course.

On our project dashboard, green flags changed to yellow. Yellow changed to red. Red lights started blinking. One by one, task statuses changed to “Impeded.” Everyone was waiting for Rick.

The project manager got a six-month extension from the sponsor. At the end of the six months, production-readiness was estimated to be seven months away. At the end of a year, production-readiness was two years out.

Rick was churning out code faster than ever. He was working seven-day weeks, twelve hours a day.

Everyone knew only Rick could pull the team out of this mess. Everyone held their breath and waited for Rick to invent the miracle cure that would mend this crippled project.

Every day, Rick grew more belligerent and isolated. The mask was coming off. Jekyll was becoming Hyde.

I participated in my first meeting with the project team about two years after the original agreed release date. I’d been aware of the project for a while, because it had grown infamous in my organization, but hadn’t been assigned to it.

I was sent in to see if we could save it.

My first meeting on the project was the aforementioned “Albert Einstein” meeting.

Hmm.

I dove into the source code. Rick was right: no-one could possibly understand what Rick had created. Except for Rick. It was a reflection of the workings of his own mind. Some of it was very clever, a lot of it was copy-pasta, it was all very idiosyncratic, and it was not at all documented.

I went to our CIO with the verdict. Only Rick would ever be able to maintain this product. Plus, every day that Rick worked on the project moved the delivery date back a week. Rick was destroying our product faster than he was creating it.

We sat down with Rick and had a conversation about his role in the project. We reviewed our concerns. We sidestepped his self-comparison to Albert Einstein.

We explained our new strategy. The team was going to collaborate on building a new product from scratch.

This effort would be very limited in scope and would only provide the bare essentials to get us to production. The whole team would contribute and be able to support it. No more bottlenecks.

How did Rick react to this?

The only way Rick could. Rick exploded.

Rick wanted no part of this farce. If we couldn’t appreciate his genius, that was our fault, not his. Rick predicted that within months we’d come crawling back to him begging him to save us.

Rick screamed that we lacked the basic mental capacity to appreciate genius when it was staring us in the face.

Sadly, after this, Rick rejected months of overtures by leadership. He refused to take time off or allow any work to be delegated. He rejected repeated attempts to introduce free open source frameworks to replace his hard-to-maintain bespoke tools.

He reverted code changes — including tested bug fixes — by other developers. He asserted that he wouldn’t be held accountable for supporting other people’s work. He continued publicly belittling his colleagues.

We fired Rick.

It took about a week for the dust to settle. It took time for the shocked team to gather themselves after losing their embattled guru.

Then I saw them huddled around a whiteboard.

They collaborated. They designed a replacement product. It would be much simpler.

It wouldn’t have all the bells and whistles. Nor would it anticipate requirements from five years down the product road map.

Rick’s product supported a dynamic workflow with over fifteen thousand permutations. In reality 99% of our use cases followed one of three paths. The team hard-coded the workflow. This removed over 30% of Rick’s work.

It wouldn’t have custom hand-coded components for every task. They stripped out every bespoke dependency that they could buy instead of build.

This removed hundreds of hours of Rick’s contribution. But it also removed thousands of hours of technical debt.

We obtained an agreement from the project sponsor to shut off some edge-case functionality.

This had served only 5% of our pre-launch user group and was responsible for about a quarter of the product’s complexity.

We re-released the product to this group. It consisted of 10% of Rick’s original code which was pretty stable. It also had a few thousand lines of new code to replace about 150,000 lines of incomprehensible mess.

The team had replaced five years of work in about six months. Over the next few months we expanded from pilot to full customer release.

Not only had we replaced what Rick had built, we sped past him and fully launched the product — all in under a year. The result was less than a fifth the size and complexity of what Rick had built.

It was also hundreds of times faster and nearly bug-free despite having been assembled in a fraction of the time and serving ten times as many customers.

The team went back to Rick’s other products. They threw away his old code there, too.

They re-released another product of his after three years in development, with three months of concerted team effort.

There were no Ricks left on the team. We didn’t have any mad geniuses building everything from scratch. But our productivity was never higher.

Rick was a very talented developer. Rick could solve complex business logic problems and create sophisticated architectures to support his lofty designs. Rick could not solve the problem of how to work effectively on a team.

Rick’s presence was destructive in several ways.

First, he created a cult of dependence. Any problem eventually became a Rick problem, a myth he encouraged. Developers learned to stop trying and just wait for Rick.

Second, he didn’t write maintainable code. He never documented or tested anything, and so failed in spite of his own intelligence. His belief in his personal infallibility trumped common sense.

Third, he was personally destructive. Team members didn’t want to speak up and offer their own ideas because he always berated them for it. Rick only respected Rick and went out of his way to make everyone else feel small.

Fourth, he lacked all personal accountability. No failure was his fault. He sincerely believed this, and it prevented him from learning from his own mistakes.

I don’t believe Rick started out this way. I saw him at his worst. This was after years of working escalating overtime and facing increasing criticism from customers and colleagues.

It’s sad that Rick descended this far. His manager shares in this responsibility. In fact, the original management team was held accountable: they were let go first.

Unfortunately Rick was so far gone that he couldn’t, or wouldn’t, be brought back. No amount of coaching, feedback, time off, or assignment to other projects changed his toxic behavior.

By this point the whole team knew he was destructive. But the cult of dependence was so strong that everyone believed he was the only option.

There is always another option.

Your team’s strength is not a function of the talent of individual members. It’s a function of their collaboration, tenacity, and mutual respect.

Focus on building teams that value each other and try to bring the best out of one another.

Together, they’ll be able to tackle greater challenges than Rick could ever fathom.

I have published a follow-up story with our lessons learned if you are interested in reading more! You may also be interested in reading about my first job at a startup, which happened to be imploding around me.

You can follow me here or on Twitter @jhsolor for more updates.

Note: Some details (such as names) have been changed. I’ve never actually worked with anyone named Rick.

Madison tells her story of how she went from being a fashion model with no college degree to full-time software engineer in just one year. She used free online resources including freeCodeCamp, and worked for free at a startup until they hired her.

Written and read by Madison Kanna: https://twitter.com/MadisonKanna

Article link: https://fcc.im/2ApFnXO

Learn to code for free at: https://www.freecodecamp.org

Intro music by Vangough: https://fcc.im/2APOG02

Resources mentioned:

https://discoverpraxis.com

https://www.freecodecamp.org

https://www.udacity.com

https://frontendmasters.com/

Transcript:

In 2015 I knew almost nothing about coding. Today, I’m a software engineer and a teacher at a code school for kids.

When people find out I work as an engineer, they often ask, “How can I get a job as a software engineer coming from a nontraditional background?”

Well, you can’t get more nontraditional than me. I was homeschooled growing up, and I’m a college dropout.

When I dropped out, I signed with an agency and modeled for fashion brands. I didn’t know what I wanted to do with my life, but my sister was a software engineer and she loved it. So one day, I took Udacity’s “Intro to Computer Science” course. And I loved it. Coding became my biggest passion.

I knew I would become a software engineer. I also knew it might be the hardest thing I ever did. But I resolved to see it through. I was going to make this happen.

If you love to code, and keep working toward your goal of becoming a developer, you will get there — no matter where you come from.

Here’s how I did it.

Figured out how you learn best.

After months of teaching myself to code, I knew I needed that next step, so I applied to several coding bootcamps. Yet I realized that I learn best not by studying, but when I am working.

Figuring out how I learn most efficiently was a huge help. For you, maybe you need to immerse yourself fully at a bootcamp, or take a part-time online program. For me, I realized I would learn best by jumping headfirst into an engineering internship.

But… how could I get one?

Build your personal brand.

I knew I wanted real-world experience. So I enrolled in Praxis, a program that places young people into apprenticeships at startups. But Praxis focuses on marketing and sales roles, and I was determined to become an engineer. So, I decided to find myself an engineering internship and use Praxis to help me build my personal brand to increase my chances of being hired.

I worked with Simon from Praxis, who helped me prepare for interviews and create my online presence.

My mom, an entrepreneur and brand expert, encouraged me to blog about coding, speak at meetups, start a YouTube channel, and continue to build my GitHub portfolio.

I kept sharing whatever I was learning about. Eventually, when you Googled me you could immediately see that I was passionate about coding.

Google yourself. What do you see?

Work for free and love the work.

While originally I had hoped to get a paying internship, I quickly realized I had a better chance of getting experience as an engineer if I did free work.

I found a startup I wanted to work for and pitched myself to them: I’d work for for free as an engineering dev for a few months. Then they could either promote me or let me go depending on how I did. They agreed, and I spent the next few months working harder than I ever have.

I relished every moment I spent just fixing one little bug in the app. Later on, I realized that although I didn’t have a ton of technical skills going in, my passion to learn and my excitement to be a part of the team shone through and got me the internship.

Even though I was working for free, I loved the work and the team more than any paying job I’ve ever had.

Make your nontraditional background a strength, not a weakness.

At first, I didn’t want to highlight just how nontraditional my background was. I feared I already stuck out enough just being a female programmer, let alone someone without a CS background. Then my mom said, “Own who you are. Use your previous experiences as a strength.”

For my first dev internship, I made it clear I would help out the startup in any way that I could. I talked about the variety of other skills I had picked up way back when I worked for my mom’s company, and how I could utilize those skills while I was also growing into the role of junior developer.

I didn’t just try to be an engineering intern. The first week of my internship, I did anything from uploading YouTube videos to writing code to making copy changes.

For many startups, they want people who are hungry to learn and get things done — not just code monkeys. What skills from your previous career can you utilize to make yourself valuable, not just as a developer but as a member of the team?

A few months into my internship, the company’s CEO, Bryan, sent me a Slack message. “Madison, we want you to work for us.”

I was promoted to junior developer. For the first time, I was getting paid to code.

Use the haters to push you forward.

Many times, when I told someone I was working towards being an engineer, they would look at me and say, “You? An engineer? Are you sure?”

For awhile this frustrated me. Then I realized that I wasn’t going to let what anyone said stop me. Each time I heard those comments, I went home and started coding. I used the haters as fuel to keep pushing myself towards my goal.

People will always tell you that you can’t do it. When you ignore what they say and just keep going, you develop a trust in yourself and a determination that becomes unstoppable.

On the other hand, having a support system who believes you can do it is immensely helpful. I couldn’t have become an engineer without the support of my family.

Just keep coding.

Getting that first junior developer position was the toughest and most rewarding thing I’ve done. If you focus on your love of code and just keep pushing forward, you will get there. No matter where you’re coming from.

So what are you waiting for? Let’s code!

Quincy explores Felix Feng's journey from bootcamp grad to professional developer, and how he went from getting $60,000 job offers to $125,000 job offers through sheer practice and persistence.

Article by Felix Feng: https://twitter.com/felix2feng

Read by Quincy Larson: https://twitter.com/ossia

Article link: https://fcc.im/2iX0LtS

Learn to code for free at: https://www.freecodecamp.org

Intro music by Vangough: https://fcc.im/2APOG02

Resources mentioned:

https://www.interviewcake.com

https://www.hiredintech.com/classrooms/system-design/lesson/60

https://www.educative.io/collection/5642554087309312/5679846214598656

https://www.reddit.com/r/cscareerquestions/comments/1jov24/heres_how_to_prepare_for_tech_interviews/

https://github.com/h5bp/Front-end-Developer-Interview-Questions

https://leetcode.com

The email tool Felix uses: https://rapportive.com/

 

Transcript: 

A less-talked about part of the bootcamper’s journey is what happens after you graduate — when you’re searching for that six-figure developer position.

< 3% of applications became offers

I completed Hack Reactor in July 2016 and took almost 3 months before accepting an offer with Radius Intelligence. I applied to 291 companies, did 32 phone screens, 16 technical screens, 13 coding challenges, 11 on-sites, and received 8 offers. The offers ranged from $60-125k in salary from companies all over the US, and for both front end and full stack roles. In total, 2.8% of applications became offers.

Here are 5 things I wish I’d known before I began my job search.

Insight #1: Get through to real people

At first, I applied for companies using the shotgun approach. I applied through Indeed.com, AngelList, LinkedIn, StackOverflow, Hacker News, company websites, and even Craigslist.

I’d submit a resume for any role that wanted React, Node, or JavaScript experience. In the first week, I applied to 15–20 companies a day.

Pro-Tip: Find companies using this easy-application repo.

My yield was low. Less than five percent of companies responded to me. I was throwing applications into a black hole.

Everything changed when one of my cohort-mates, a former recruiter, shared a guide to the job search. He told us to send emails directly to real people with each application. It could be anybody. As long as someone read it.

From then on, whenever I submitted an application, I searched for the company on LinkedIn and emailed someone on their engineering or hiring team.

For most small companies or C-level executives, the email format is usually [email protected]. For larger companies, it may be [email protected].

To verify emails, I used Rapportive to cross-check emails with social media accounts.

The results were amazing. With 150+ emails sent, my response rate was a whopping 22%.

It also felt great to hear from real people. Surprisingly, CEOs and CTOs responded to me. Sometimes they even interviewed me themselves.

Takeaway: If you’re applying through the front door, make sure you’re getting to human beings.

Insight #2: Start small and work your way up

You will face Level 1 interviews (a non-tech company that needs any dev), where interviewers ask you nothing more than JavaScript trivia.

You will face Level 9 interviews (Google/Facebook level), where interviewers ask difficult data structure and algorithm questions.

I strategically set up my process so that I had lower-level interviews earlier, and higher-level interviews later on.

Early on, I gained experience, built confidence, and secured offers from companies that had less intensive interviews.

As I got more experience, I effectively “leveled up.” I became capable of completing interviews at companies with higher hiring bars. This is illustrated below as a linear correlation between the number of weeks I was into the process and the base salary I was offered.

There’s a direct correlation between time spent interviewing and offer salary.

I unlocked tougher questions. I unlocked higher salaries. And eventually, I unlocked the job I took.

Takeaway: Plan to tackle easier interviews early on and more difficult ones later on.

Insight #3: Study like your future job depends on it (because it does)

I hate to break it to you, but the most important thing you could be doing at any point is studying and preparing.

Why? Because you won’t get the offer if you don’t have good answers to the questions they ask you.

People won’t refer you if they don’t think you’re prepared for their interviews.

Coming out of Hack Reactor, my weaknesses were data structures and algorithms. A study by Triplebyte has found that bootcamp grads are weaker in these areas than computer science grads.

So I learned and practiced. Every day.

I devoted entire days to learning sorting algorithms. Other days, I focused on understanding how the internet worked.

If I didn’t fully understand a concept, I’d spend the day watching YouTube videos or searching StackOverflow until I did.

I found the following study materials useful:

InterviewCake: My favorite resource for data structures and algorithms. It breaks down solutions into step-by-step chunks — a great alternative to Cracking the Code Interview (CTCI). My only gripe is that they don’t have more problems!

HiredInTech’s System Design Section: A great guide for system design interview questions.

Coderust: If you’re avoiding CTCI like the plague, Coderust 2.0 may be perfect for you. For $49, you get solutions in almost any programming language, with interactive diagrams.

Reddit’s How to Prepare for Tech Interviews: I constantly used this as a benchmark for how prepared I was.

Front End Interview Questions: An exhaustive list of front-end questions.

Leetcode: The go-to resource for algorithm and data structure questions. You can filter by company, so for example, you could get all the questions that Uber or Google typically ask.

Takeaway: There’s no such thing as too much preparation.

Insight #4: Put your best foot forward

Breaking into the industry is hard. You have to perform well, even when you’re not fully prepared. In order to succeed, you have to be your own advocate.

Sell Yourself

At Hack Reactor, we’re trained to mask our inexperience. In our personal narratives, we purposely omit our bootcamp education.

Why? Otherwise, companies automatically categorize us into junior developer roles or tag us as “not enough experience.”

In one interview with a startup, the interview immediately went south once they realized I’d done a bootcamp. One company used it against me and made me a $60k offer, benchmarking against junior developers.

Ultimately, you need to convince companies that you can do the job.

At the same time, you need to convince yourself that you can do the job.

You can. Focus on your love for programming. Focus on what you’ve built with React and Node. Focus on demonstrating your deep knowledge in JavaScript and any other languages you’ve learned.

Only then can they justify giving you the job.

It’s a Two-way Conversation

Interviewing is a mutual exploration of fit between an employee and an employer. While it’s your job to convince employers to hire you, it’s also their job to win you over.

Don’t be ashamed of using the interview as an opportunity to evaluate the job opportunity.

I talked to any company, even if I had only the slightest interest.

I did on-sites all over the country with any company that invited me out. I asked questions, and sucked up knowledge on engineering team organization, technologies and tools used, company challenges, and system architecture.

Pro-Tip: During interviews, ask the following questions:

What are some technical challenges you’ve recently faced?

What do you enjoy about working at X company?

How are teams structured and how are tasks usually divided?

I treated every interaction as a learning opportunity. Each interaction helped me improve my presentation, interview, and technical skills. Each failure helped me find my blind spots.

Takeaway: Don’t sell yourself short! And remember, it’s a mutual exploration.

Insight #5: It’s a marathon, not a sprint

The journey is by no means easy. For 3 months, I grinded 6 days a week. But I tried to take care of myself.

What a typical day could look like in JavaScript

Some days, I’d study with friends. Other days, I’d go find a cafe and study alone, or hang out at Hack Reactor’s alumni lounge. And every week I’d check in with our career counselor to talk about my progress.

It’s easy to burn out during the process. Eat well, sleep, and exercise.

It can get lonely. Spend time with friends who are going through the same experience.

Takeaway: Prepare for the long game and make sure you take care of yourself.

In summary, the key takeaways are:

Get through to real people

Start small and work your way up

Study like your future job depends on it

Put your best foot forward

It’s a marathon, not a sprint

The process may seem endless, but you’re going to make it. Keep putting in the hours. Keep sending in the applications. Keep taking caring of yourself. All of it pays off in the end.