Episodes

  • 00:28:12

    Ep. 26 - The Essential Guide to Take-Home Coding Challenges

    The freeCodeCamp Podcast starstarstarstarstar
    add

    Jane wanted to help others with non-traditional backgrounds succeed on take-home coding challenges. So she wrote an extensive guide for anyone who has received such a challenge and wants to attack it in the best possible way. She divulges mistakes to avoid, how to get organized, and how to go above and beyond.

    Written by Jane Philipps: https://twitter.com/janephilipps

    Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn

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

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

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

    Transcript:

    Introduction

    Hi, I’m Jane. I wrote this guide because I want to help others with non-traditional backgrounds succeed on take-home coding challenges. Please read it, take notes, apply the material, and let me know about your results. You can reach me via email at jane@fullstackinterviewing.com.

    This guide is intended for anyone who has received a take-home coding challenge as part of the technical interview process and wants to attack it in the best way. This Essential Guide is a distilled version of a longer Ultimate Guide to Take-home Coding Challenges, which goes into much more detail and walks through an example challenge from start to finish.

    So, if you’ve just received a challenge and are anxious to get started, start here, and then check out the full guide when you want to learn the material more deeply. Good luck!

    Mistakes to avoid making when working on a take-home coding challenge

    There are several mistakes you can make with take-home challenges. Some of these are small mistakes that are easily correctable, while others will leave you frustrated and unable to finish your assignment. I want to address these mistakes first, so when you’re given a take-home challenge, you know exactly what not to do.

    Here are four mistakes you can make:

    1. Time management and scope creep

    2. Trying to learn too many new things at once

    3. Making too many assumptions

    4. Starting to code right away

    Let’s look at each one in detail.

    1. Time management and scope creep

    Time estimation is one of the hardest problems in programming, and even experienced engineers struggle with it. This plays into take-home challenges in a couple of ways.

    First, some challenges come with “estimated time.” I usually ignore these, as they are rarely based in reality. Second, some challenges are open-ended. Many people, especially newer developers, will want to add tons of features because they think it will be impressive. Actually, it’s more impressive if you keep the scope relatively narrow, but finish everything you set out to do. In this situation, it’s better to do one thing really well than to do a million things poorly.

    A good question would be: what counts as “going above and beyond” versus what counts as “scope creep?” My rule of thumb would be if your idea accomplishes or improves on the requirements of the assignment, that is likely a good idea, but if it seems tangentially related or “just cool,” it’s probably scope creep. But, as I describe later, always make it work first.

    2. Trying to learn too many new things at once

    While a take-home coding challenge can be an excellent opportunity for learning, it is possible to take on too much learning. If you’re given a challenge where you must use a specific language or framework, but you’re not familiar with it, don’t add additional complexity by setting out to learn something new on top of that. For example, if you are using a new backend framework for a full stack app, stick to a frontend framework that you’re already comfortable with.

    If your challenge is language/framework agnostic, but you’ve been itching to try out some new technology, pick JUST ONE to experiment with. Between reading the docs, getting your challenge properly set up, and getting used to any new syntax, you will have your hands full. Even learning one thing will eat up a lot of your time, so I would highly suggest limiting yourself to one new piece of technology per challenge.

    3. Making too many assumptions

    As a developer, if you make too many assumptions, you are bound to build an application where the requirements are off, or the user experience is bad. When given a set of requirements for a take-home challenge, ALWAYS take the time to review the requirements and make sure you fully understand them. And, if you have any questions at all, always ask.

    First, this shows that you are willing to ask for help when you don’t quite understand something, an important trait for a developer to demonstrate. Second, many companies will intentionally give you product requirements that are vague or not fully fleshed out in order to see how you react in these situations. They are actually testing your ability to make sense of requirements that may have gaps in them.

    So, when in doubt, ask questions. Asking questions is also a signal that you are engaged and interested in the challenge.

    4. Starting to code right away

    One last mistake you can make is to jump in and start coding right away. I guarantee if you do this, you will regret it. Why? Two reasons:

    Without proper planning, your code will suffer

    Without first getting organized and making sure you fully understand ALL of the technical requirements, you may find yourself missing edge cases or rewriting parts of the functionality. I know it seems counter-intuitive, but you will actually SAVE yourself time if you plan ahead.

    You will spin your wheels trying to get your app set up properly

    Especially for newer developers, initial app setup can be one of the hardest parts of a take-home coding challenge. It’s not something you do every day, so it often takes some research and reading documentation to get reacquainted with the process and ensure you’re going about it in the best way.

    So, there you have it — a summary of mistakes to avoid making. You’ll find that a lot of these are also applicable to your day to day work as a developer. In the next section, we’ll dive into further detail on how to get organized before you write a single line of code.

    Get organized: how to plan before you write a line of code

    Now it’s time to get to work! But, it’s NOT time to write any code YET.

    Why?

    Because, as you’ll see, a lot of the work actually happens before you write a single line of code. This may seem counterintuitive, but again — the more time you spend up front planning, the less time you will spend writing code.

    So, now you have your coding challenge in hand and you are ready to get started with the planning process. Here are my six suggested steps:

    1. Understand the requirements and ask any questions

    2. Identify technical decisions you need to make

    3. Technical design & whiteboarding

    4. Test plan

    5. App setup plan

    6. Organize your tasks

    1. Understand the requirements and ask any questions

    First, you need to make sure you completely, absolutely, 100% understand the requirements of the project. If any part of the requirements are unclear, it is up to you to reach out to your contact and ask questions.

    Sometimes companies will purposefully make their requirements vague, in order to see how you approach the problem. In these cases, it is always best to ask questions as it shows you are thinking about the problem and not just making assumptions and building an app to a vague spec.

    2. Identify technical decisions you need to make

    Your next step will be to identify the technical decisions that you need to make. Making a list of all of your technical decisions up front and thinking about them before you’re in the middle of building your app will help you immensely. Not only will it cut down on time figuring things out later, but it will allow you to make big picture decisions up front, as opposed to trying to focus on both the big picture and the small details at the same time.

    3. Technical design & whiteboarding

    Now it’s time to plan out the rest of your app. For anything that you need to draw out, now is the perfect time to do that. Thinking through these decisions at the start serves two purposes:

    You’ll be able to reference these drawings and your original plan while you’re building your app. Then if you get stuck at any point, you can always come back to your notes.

    Later, when you are having a discussion with an engineer about your coding challenge, you can use these notes as a reference when they ask you why you made certain design or architecture decisions.

    Once you’ve thought through and answered some of the bigger design and architecture questions for your challenge, the next step is research. If you’re planning to use a new technology or something you’re a bit rusty with, use this time to search for documentation and other resources.

    4. Test plan

    Another very important step to take before writing a line of code is developing a test plan. Although you won’t get peer feedback on this test plan, it will help you look at the challenge from a different angle, making sure you’re meeting all of the requirements. By thinking through and writing out a test plan before you start coding, you are able to brainstorm possible edge cases that you should account for in your code and you will use this as a basis for testing your app later.

    5. App setup plan

    If you’re starting an app from scratch, figure out if there are any generators you can use to make your app setup easier and faster. Application setup is one of the hardest parts of take-home coding challenges, because it’s something that developers do rather infrequently. Best practices are always changing, so it’s easy to forget how to do. Also, when setting up an app with a specific combination of technologies for the first time, it can be challenging to get everything configured and working together properly.

    If you are not using a generator, reading documentation and finding working examples are the two most important steps you can take. Being able to play with a working example and compare it to your own app will help you if you get stuck.

    6. Organize your tasks

    The last step before you start coding is to break down and organize your tasks. Breaking down your tasks is essential because it will help you stay on track as you’re working on your challenge, and it will give you a game plan for execution. Note that you shouldn’t be a perfectionist here, because there will always be unexpected bumps in the road.

    Here is an example task list for a classic Tic Tac Toe app:

    - Understand requirements
    - Choose technologies
    - Brainstorm test plan
    - Hello World app setup
    - Build board with HTML/CSS
    - Implement Tic Tac Toe gameplay with Javascript
    - Add reset button
    - Make board responsive
    - Add ability to add additional boards
    - Error handling & tests
    - Code cleanup
    - README

    Some of these tasks can be broken down even further into smaller steps. For example, in order to implement the Tic Tac Toe gameplay with Javascript, here are some smaller tasks:

    - Add a click handler to each square that logs a message
    - Get click handler to add an X to the square that is clicked
    - Get clicks to alternate between X and O
    - Don’t allow a square to be clicked more than once
    - Implement a function to find the winner and end the game
    - Handle a tie game

    3. Writing tests: just do it!

    Testing can be overwhelming, because there are so many different types of tests: acceptance tests, integration tests, and unit tests, not to mention test driven development vs. ad hoc testing.

    Why should you include tests in your take-home coding challenge? It’s simple: your tests will make your submission shine.

    First, adding tests shows that you know or are willing to learn another technology/framework. It also demonstrates that you take ownership of what you’re building, because you are taking responsibility to make sure it works. Testing also shows that you’ve considered edge cases, which many newer engineers often overlook.

    Many companies take tests very seriously. Some will not tell you that they expect tests for your coding challenge, but will automatically reject you if you leave them out. Therefore, my recommendation is to write tests no matter what when given a take-home challenge. Not only will it make you a better developer, but for companies that were not expecting tests, you will stand out even more!

    How do you go about writing a tests? First, create a plan. Here’s my 80/20 suggestion for how to come up with the right test cases:

    1. Test the happy path

    For the classic Tic Tac Toe example, the happy path is starting with an empty board and playing a game until X wins.

    2. Think about variations on the happy path

    A variation on the happy path would be if O wins, or if there is a tie game.

    3. Think of edge cases

    An edge case would be if a player tries to play a move in the same square more than once.

    4. Test anything that is complex

    The algorithm to find the winner is the most complex part of this example.

    Here’s a sample test plan:

    - Test that the initial state of the board is correct (i.e. board is
    visible and empty)
    - Test that a move can be played
    - Test that moves alternate between X and O
    - Test that a move can be played to a square only once
    - Test that a winner can be found in a row
    - Test that a winner can be found in a column
    - Test that a winner can be found in a diagonal
    - Test that a draw can be found

    So, now it’s your turn. Think about your app and, as a baseline, think of 5–10 tests that you can write.

    4. Make it work, then make it pretty, then make it fast

    The title of this section sums it up pretty well, but when you’re working on building out your challenge, you should follow these 3 steps IN THIS ORDER:

    1. Make it work

    2. Make it pretty

    3. Make it fast

    1. Make it work

    When you’re given a take-home coding challenge, no matter what you do, the most crucial part of the challenge is to make it work. If you submit an app that has a nice UI, that will not matter if your app does not work or meet all of the requirements. Because building features to spec is a key aspect of your future job as a developer, you first and foremost need to focus on the functionality of your app and prioritize that above all else.

    This is also key if you are low on or run out of time. Coding challenges can be a lot of work, especially if you want to go above and beyond to ensure that you make it to the next interview round. But, I can guarantee that you will not make it to the next round if your app doesn’t function properly or is missing some key components.

    So, if you’re building a front-end app, this means focusing on making it work first, and styling/UI last. If you are building a back-end or full-stack app, focus on making it work before trying to refactor your code into the most elegant solution, and only then worry about optimization.

    Even if you end up without any time to go back and refactor your code or style your UI, having a working app to present is more important. You can always talk to the interviewer about how you would improve your app, and refactoring some of your code might even be part of the next round of interviewing.

    2. Make it pretty

    Make it pretty has two interpretations here. One is making the code pretty, and the other is making the UI pretty. Making the code pretty can be done in several ways. First, ensure indentation is consistent and your code is readable. Second, if you got something to work in a quick, hacky way, think about how you can refactor it to be a more elegant solution without overcomplicating it.

    If you’re doing a front-end or full-stack challenge, you can also make the UI pretty as part of this step. Whether you use a library or write your own custom styles for your app, making the UI look good will show your interviewer that you’re taking the user experience into consideration when building a feature.

    For some more front-end-focused challenges, you’ll be given a specific mockup to match. In these cases, making sure you’re detail oriented down to the last pixel is incredibly important. Part of your role may involve translating mockups from designers into user interfaces, so companies want to get a sense of how you approach those types of tasks.

    3. Make it fast

    Once you’ve made your app work, made it pretty (in the code, UI, or both), it may be time to make it fast! This is where understanding performance and BigO notation comes in handy.

    You should take a look at your code and see if there are any areas where increasing the scale might be an issue. For example, are you using a double for loop somewhere? What if the arrays you’re looping over become super long?

    If you think about these kinds of edge cases, you can then come up with plan to improve your code. Taking something that would have been running O(n) and making it O(1) will show that you’re thinking about performance when you’re building things.

    How to make your code shine

    When given a take-home coding challenge, many people think about how to build an app that works, but stop there. In this section, I’ll go over things an engineer reviewing your code will look for, so you can take your challenge to the next level and make your code shine.

    When an engineer is reviewing your code, they will look for several different things. They will likely try to run your app to play around with it and see it working. After that, they will delve into the actual code, looking to see how you organized your app architecture and reading code in individual files.

    There are several things you can do to make your code stand out. You want your code to be:

    Readable
    Easy to follow
    Well organized
    Clean (properly indented, free of syntax errors and unnecessary whitespace)

    These are the basics that don’t take much effort outside of mindfulness to get right. Now let’s talk about three of the more involved code style considerations:

    1. How to name things

    2. How to use comments effectively

    3. How to format your code as you write it

    1. How to name things

    Naming is one of the hardest problems in programming. One of the keys to naming things is to make sure you’re naming them in a way that another developer who is unfamiliar with the code can easily jump in and understand.

    For functions, think about what exactly the function is doing. Is the function checking whether there is a winner on a row of a Tic Tac Toe board? Then a great name would be checkRow. Is your function handling a click on a square of the Tic Tac Toe board? Then a great name would be handleClick.

    One quick tip: if you find yourself losing your flow because you keep stopping to think of the perfect name, split your process into two steps. First, write working code with any names (like foo, bar, and baz). Then take a second pass through to improve them.

    2. How to use comments effectively

    Adding comments can be a great way to capture what you were thinking at the time you wrote a specific piece of code. This can be useful to you, or anyone else who comes across your code in the future and needs to understand it, tweak it, or rewrite it.

    Think of comments as adding clarity to your code. But, pay attention, because there is such a thing as too many comments.

    Here is where you most likely do not need comments:

    When you declare a variable
    When you declare a function

    The variable or function name should be enough to explain exactly what it does. If you need a comment to explain it, then you need to give it a better name!

    Here are some examples of where comments can be useful:

    HTML
    CSS
    Technically tricky lines of code

    First, let’s talk about HTML. Markup seems pretty self-explanatory, right? So, why would you need comments? Let’s say you have a really long HTML file with A LOT of s. Comments can be a good way to signal which tags close which sections.

    In CSS, comments are a good way to divide up your styles if you have a lot of styles in one file. This way, when you come back to the code later and want to make a change, it’s easier to find the styles for that one section you need to update.

    Comments in CSS are also very useful whenever you are hard-coding any math or adding an arbitrary number of pixels as margin, padding, and so on. Comments can be useful to explain things like this that are specific to your application.

    One of the best uses for comments is when you’ve written code that is technically difficult or just not intuitive. You should always strive for simple, understandable code as much as possible. However, sometimes you will have confusing code — maybe you’ve chained a bunch of methods together or are using a complex regular expression — and it would help to explain what is happening in a comment.

    You are almost done learning how to make your code shine! Just one more step.

    3. How to format your code as you write it

    I’m a STICKLER about formatting when it comes to code. And, it’s not just me. You’ll find that the best engineers also care about well-formatted, clean code. Why? First, it’s much easier to read! Coding can be really challenging, so when code is easier to read, it makes our jobs as developers that much easier. Also, writing clean code sends a message to your interviewers that you take pride in the craft of writing code, and for many teams, this is a big deal.

    So, how do you make sure the code style sticklers will approve of your code? There are a few simple tricks you can use as you’re working through your coding challenge to ensure the end result comes out clean and you don’t have to spend time at the end reformatting everything.

    Choose tabs or spaces and be consistent across your entire application (i.e. no 2 spaces in some files, 4 spaces in others)

    Indent your code properly as you go so that it stays readable and isn’t all over the place

    Get rid of trailing whitespace! Whitespace can sometimes wreck havoc, so it’s best to just get rid of it as you write your code.

    Keep your syntax consistent throughout your entire app. If you’re using a linter, this will be easier, but requires setting one up. If you don’t have time to set one up, pay attention. Don’t use ES5 in some places in your app and ES6 in others. Pick one and stick with it!

    Remove unnecessary logging and debug statements when you’re done using them! Unless logging is part of your application, you’ll want to remove any temporary statements you were using while building your app.

    Always leave a newline at the end of every file

    That’s it! It’s pretty simple, and once you’re in the habit of doing this, not only will your code be easier for you to read, but it will also be easier for others to read and maintain. Many new developers haven’t been exposed to very much code maintenance, but trust me, when you have to clean up code someone else has written, you will be more thankful if it was neatly organized to start. Pay it forward!

    How to take your challenge to the next level

    Here are 3 ideas for how you can take your coding challenge to the next level:

    1. Bonuses

    2. UI/UX design (for front-end or full-stack challenges)

    3. Data validation and error handling

    1. Bonuses

    Not all coding challenges come with bonuses, but if yours does and your goal is to get a job offer, do them! Why? It’s pretty simple. If you go above and beyond in your coding challenge, it will show that you will go above and beyond once you’re hired at this company. Completing bonus requirements is a high competence trigger for the interviewer.

    2. UI/UX design (for front-end or full-stack challenges)

    Some front-end or full-stack challenges will mention UI/UX design as a bonus, but if they don’t, putting in some effort to make the UI look nice and be easy to use will go a long way. You can either go the route of adding your own custom CSS or plugging in a library or two to help make your styling even more painless. If you use a library, just make sure that you understand how it works enough to explain how you’ve used it.

    3. Data validation and error handling

    Data validation and error handling are key components in production apps. Adding either one of these (or both!) to your challenge will help make it stand out. Many developers who are new to coding and haven’t worked in a production codebase before don’t have a ton of exposure to either of these, so if you add error handling for edge cases it will show that you thought through a lot of different situations.

    How to write an awesome README

    You may be done writing code, but you’re not done writing yet — it’s time to write your README.

    Why you should include a README

    READMEs are incredibly important, both for professional developers and for job seekers working on take-home challenges. Including a README shows that you care about documentation.

    Documentation helps spread knowledge across teams and serves as a supplement to your code. Having documentation for your take-home challenge ensures that anyone else (or future you) can jump into your code with a clear understanding of what you’ve built without any guessing games.

    Your README is also the KEY to making sure that everyone reviewing your challenge has the most painless experience possible. Finally, your README is a way of proving to your reviewer that you successfully met the requirements of the challenge.

    How to write your README

    Writing a great README is not hard, and you will stand out a great deal from the other applicants with one. Here are the five sections I’d recommend you include:

    1. Installation instructions

    2. Discussion of technologies used

    3. A section demonstrating that you met the requirements

    4. If there are bonuses, a section demonstrating that you met them

    5. For algorithms and data structures, time and space complexity

    1. Installation instructions

    When writing your README, don’t make any assumptions. Write out all of the steps to run your app locally and test them yourself. This includes cloning the repo from Github, running installation commands, and starting up a server. Also, make sure to include versions of software that you are using. This will ensure that the developer reviewing your code has a seamless experience setting up and running your app, and if they do happen to run into any trouble due to versioning, they will have all of the information they need right there in the README.

    2. Discussion of technologies used

    This section is as simple as it sounds — make a list of all of the technologies you used including frameworks and libraries. If you had to find a library for a specific piece of functionality in your take-home challenge, mention it here and include a link to the docs.

    3. A section demonstrating that you met the requirements

    Usually your take-home challenge will come with some sort of requirements spec, so make sure to include a section in your README where you describe the requirements and how you met them. In some cases, you can take the product spec you were given and write a short explanation of how you met each requirement in a list. In other cases, you can simply include a short paragraph explaining how you satisfied the requirements. It’s totally up to you how you do it, just make sure you include it.

    4. If there are bonuses, a section demonstrating that you met them

    Similar to the requirements section above, you’ll want to highlight any bonuses you completed while working on the take-home challenge. If you attempted a bonus, but couldn’t quite get something to work, then the README is also a good place to address that. You can discuss the approach or approaches you tried and what worked or didn’t work.

    5. For algorithms and data structures, time and space complexity

    If you had to write any algorithms or data structures as part of your take-home challenge, it’s helpful to include the space-time complexity of your final algorithm. This can be done in Big O notation.

    One final word of advice: write your README in markdown so it looks nice! This will demonstrate that you know (or are willing to learn) another language that will come in handy as a full-time developer.

    Final steps before you hit send

    Now that you’ve written your README, you’re almost ready to hit send! Before you do that, take the time to double check all of your work using the following checklist:

    Re-read the take-home challenge instructions to make sure you didn’t miss any requirements

    Review your app’s code to ensure that it shines

    Run your app’s automated tests and make sure they are all passing

    Test your app manually and make sure everything is working properly

    Test your app installation instructions from your README

    Start an email draft and copy your README into it for convenience

    If requested, make sure to attach a zip file of your code

    Write an email to your contact at the company

    Your email can be short and sweet — I always like to highlight something I enjoyed about the challenge or something I learned. Here’s an example:

    Hi ,
    I hope you had a great week! I had fun diving back into React with this challenge. Here is my Github repo and I’ve included my README below. Please let me know if you have any questions.
    Just so you know, I’m interviewing with a few other companies and I just received an offer yesterday — I need to get back to them next week. Of course, I am excited about the opportunity at , so I’m looking forward to hearing from you!
    Thanks,

    Note that you should only mention interviewing with other companies or offer deadlines if either is actually the case. I feel you should be honest and candid about your situation and maintain leverage for a potential future compensation negotiation at the same time.

    Now, finally, hit send!

    Conclusion

    I hope this Essential Guide was helpful and you learned something that you can apply to a take-home challenge or in your day-to-day work. If you have any comments, questions, or other feedback, please don’t hesitate to reach out. You can reach me at jane@fullstackinterviewing.com.

  • 00:07:05

    Ep. 25 - I'm 56 and learning to code. Here's an epic beat-down of my critical inner self.

    The freeCodeCamp Podcast starstarstarstarstar
    add

    If you're over the age of 20, you might think you're too old to learn how to code. But 56 year old VM Vaughn's here to tell you that's not true. In this podcast, he shares his epic beat-down of his critical inner self and lays out his path towards an exciting second career.

    Written by VM Vaughn: https://twitter.com/vmvaughn

    Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn

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

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

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

    Transcript:

    I’m 56 years old and learning to code.

    Why? Because I love it. And I’ve got a knack for it.

    That doesn’t mean it’s easy. It’s hard. And that’s OK.

    I love losing myself in an algorithm challenge. I love squeezing in a few extra minutes testing just one more thing. I love thinking “maybe I’ve got it this time.” And getting to “Yes! It finally works!”

    But here’s the thing. I’ve never been one for hobbies. I don’t like activities that don’t pay. I can’t keep on doing something simply for the fun of it.

    What I work on during my off time has to have some economic upside for me.

    OK, coding pays. It can pay big. So what’s the problem?

    Well, before I could fully embrace myself as a 56-year-old programming rookie, I had to deal with my Critical Inner Self (let’s call him CIS for short).

    Learning all this stuff is hard enough without my CIS whispering in my ear the whole time.

    If I can give my CIS an epic beat-down, then I should be able to handle anyone who appears to work on his behalf. And these agents of CIS often appear out of no where, asking critical questions.

    CIS: Why are you doing this at your age?

    Me: What you really mean is how much longer will I live. And do I really have enough time left to make money programming. Let’s break that down.

    I’m an American. My life expectancy is 78.8 years. So that means I’ve got a better than average chance of living another 22.8 years. That may not seem like a lot when you’re 20, but I’m 56 and dancing in the street over here.

    (And because I’m 56, I’ve got better odds of making it to 78 than a 20 year old. But that’s beside the point.)

    Now, let’s say I’m a snail and it takes me 4 years to finish Free Code Camp’s 1-year curriculum to become a fledgling full stack developer. That puts me at 60 years old looking for a job as a junior developer.

    Let’s say it takes me another 2 years to land a job because of my age, and let’s assume that 70 is the limit for how long an employer wants me hanging around.

    That’s 8 years to practice my craft. That’s plenty of runway to get pretty good. And because I’ve been around the block and know the grass ain’t always greener on the other side, I’m much more likely to stay with that employer who hired me first.

    What 20-year-old stays with their first developer job that long?

    CIS: But who’s going to pay you the kind of money that you already make now?

    Me: You could ask me that even if I didn’t learn to program. But I know what you’re getting at. Chances are an entry level developer job will pay me less than I’m making now.

    Well here’s a thought for you. My paycheck is less today than it was five years ago. And that’s with 5 more years of experience.

    There’s no guarantee that the job I have now will last. And when it doesn’t, I’ll have to find a new job anyway. At my age, I very well may have to accept entry level wages doing something… anything.

    I’d rather have the skills and portfolio to go for an entry level position that can lead to much greater earnings — or at least the ability to beat the bushes and pick up some freelance work.

    CIS: But all the big tech companies want to hire young kids right out of college.

    Me: That’s easy. I don’t want to move to Silicon Valley and I’m not looking to work for a big tech company.

    You’ve read the same stats as me. By 2020 there will be 1,000,000 more programming jobs than people trained to fill them. Not all of those openings will be at the “big 4” — Google, Facebook, Amazon, or Microsoft. In fact, most programming jobs aren’t even in the technology industry.

    My first computer job was in a hospital. I didn’t program, but most of the employees in the IT department were programmers.

    And that was way back in 1982.

    CIS: Then how are you going to get a job?

    Me: First things first, I’m going to apply to a lot of jobs, build a network of hiring managers, and make sure I get a lot of interviews. It’s a numbers game and I’m going to play it.

    All that wonderful stuff I did before the year 2000? Gone from my resume.

    Once I’m in the door for an interview, it’s not like I’m going to act like someone’s grandfather. I’ll be just another candidate who’s passionate about programming and excited to learn more. And I won’t act like I know more than I do.

    And most importantly, I’ll be prepared for common coding challenges and whiteboard interview questions.

    I’m sure I’ll mess up a few interviews. But the good news? There are plenty of companies out there hiring developers. I’ll keep trying.

    CIS: Programming teams are full of young people. How are you going to fit in?

    Me: If by “fit in” you mean how do I become one of the bros? In that case, you’re right. I won’t fit in.

    At my current job, I show up every day knowing that somebody at work has something to teach me. So I listen. I don’t presume to know everything that’s going on in my boss’s day, so I give him a break. And when I mess up, I say so.

    That’s how I’ve fit in at every job I’ve had over the last 36 years.

    CIS: You’ve got a decent job. Why not just accept it? You are where you’re going to be, especially at your age.

    Me: Accept it? Too late. I’ve already re-framed it.

    Learning to program energizes me. Working toward a second career gives me the boost I need to get through the daily slog of the one I’ve got now.

    And really? You know where I’m going to be at 60, 70, and (hopefully) beyond? I sure don’t.

    CIS: How do you know you’re not just wasting time?

    Me: What you’re really asking is: “What if you don’t get a 9-to-5 paycheck after this?”

    My answer: “So what?”

    I can get good enough, in time enough, to program well enough:

    to build web apps to build an audience…and offer them even more value from my billable services.

    to grow a web business helping local businesses grow and nurture their own customers.

    to combine my programming know-how with existing SaaS APIs to offer a productized service to a niche community.

    To put it another way, I can learn how to build an idea. To put it out there for people to use. To offer value. To make money.

    With or without a 9-to-5 J.O.B.

    So that’s why even though I’m 56, I’m learning to code.

  • Missing episodes?

    Click here to refresh the feed.

  • 00:16:48

    Ep. 24 - How to run a successful development process (even if you're not technical)

    The freeCodeCamp Podcast starstarstarstarstar
    add

    This episode is for anyone who wants to effectively orchestrate a development process without becoming the butt of their team’s water-cooler jokes. It's more attainable than you think, because it's all about process. Don't be a Bill Lumbergh - be awesome.

    Written and read by Jonathan Solórzano-Hamilton: https://twitter.com/jhsolor

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

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

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

    Transcript:

    Laurence Peter formulated the principle that “managers rise to the level of their incompetence” in 1969. In particular, non-technical leaders have earned a poor reputation with software developers.

    Office Space depicts the non-technical manager in Bill Lumbergh, pictured above. Dilbert provides the classic “Pointy-Haired Boss.”

    This article is for anyone who wants to effectively orchestrate a development process without becoming the butt of your team’s water-cooler jokes. I’ll share what I’ve learned over the years managing development and release processes as a manager and software architect at UCLA and Stanford University.

    The biggest lesson I’ve learned is that the key to sustaining successful software releases is completely non-technical.

    It’s about process.

    Some aspects of a development process benefit from technical know-how, but it’s not required. Successfully releasing software into production is much more a question of robust process architecture than design or code alone.

    For the purpose of this article, we’ll assume you’ve already agreed to start building something. The product approval pipeline is a different process. Today we’re focusing on getting the agreed-upon product from concept to production.

    What to build

    Your team needs to assemble a clear roadmap for their code. Architects and manufacturers use blueprints. You should too.

    Your roadmap should include a set of schematics which each fulfill a different purpose. These schematics differ for individual applications. A user-interface mock-up, application architecture diagram, and business process model are common. More detailed component diagrams such as Unified Modeling Language (UML) diagrams and flow models are often useful as well.

    Technical expertise lets you use these schematics to critique your team’s architecture and ensure they’re on the right track. Even without technical skill, these schematics will be critical.

    You can use them to drive productive conversations about product completion. No more will you have to draw a “% complete” out of thin air or best-guess from the development team. You can track the status of each item on the diagram to determine how close the app is to completion. You can also project future velocity based on how quickly the team completed prior components.

    There is no “right” amount of pre-development documentation, but there is one wrong amount: none. Work out with your team what constitutes an acceptable roadmap before they start coding. The first checkpoint in your development process will be to review this documentation and ensure they’ve met this agreement.

    What not to build

    Your team can’t build everything. Nor should they. You need to ensure that your developers have a laser focus on what they actually need to build.

    Why are you building this app in the first place? Define the key differentiation from existing products. 80% of your team’s time should go toward supporting that differentiation.

    The schematics you should now have will be helpful here. Does your application include a logging component? A sign-up and login process? There are already excellent free, open-source software (FOSS) frameworks in most languages for these components. Some are available under extremely permissive licenses.

    Tesla provides a great illustration of this concept. Their first key differentiator was to use a lithium-ion battery to make electric cars competitive with gas. Lithium-ion achieved this by reducing battery weight and increasing range.

    The first Tesla prototype simply converted a pre-existing electric sports car from lead-acid to lithium batteries. Their first production run was mostly a Lotus Elise roadster (a pre-existing sports car) that had a Tesla battery and motor.

    The lesson for your team is to use what already exists wherever possible. If you can use or adapt a FOSS package, do it. Even if you need to license for-pay code from somewhere else, it’s almost always worth it.

    Get all the scaffolding in place quickly so you can test your “lithium-ion battery.” Then you can iterate through and replace whatever will help further differentiate your product without stressing about delaying production-readiness.

    The second checkpoint of your development process is to review the planned architecture with your team and identify what very limited part they intend to build from scratch.

    If it sounds like something that already exists, and it’s not the core focus of your product, challenge your team to see why they believe they need to re-do it.

    Don’t just throw it over the wall

    Once you have identified what pre-built technologies you’ll use, make sure to review these with your production support group.

    Database and server administrators will need to plan for installing and supporting any new technologies. This is the third checkpoint in your development process: operations readiness.

    Keeping the production support team in the loop early is 90% of the secret sauce known as “DevOps.” If you haven’t heard of this, DevOps is the idea that software development and production operations teams should unify under common goals.

    The proposed benefits include much quicker releases, more reliable code, and more time spent developing due to automation. These are all great boons, but they follow from a strong communication process. Automation follows, not replaces, collaboration.

    Implementation and Testing

    Now your team writes the code. Collaborate with your implementation team to devise a process for dividing the work among themselves. There’s no one-size-fits-all approach, and this is where the “soft skills” of leadership dramatically outweigh any technical skill.

    Some developers will want to hog all the “interesting” work and ignore any drudge work. They may believe that they’re the smartest person in the room and should get their pick of assignments. Others may resist change and only want to do the same kind of work they’ve done before.

    Lead your team into an equitable distribution of work. Challenge everyone to grow appropriately and to share and collaborate.

    One more technical aspect of the implementation is that the code must include sufficient automated tests. These are code-defined tests that a test system can execute.

    If the code’s going to crash, don’t you want these guys’ resumes to be on the line instead of your own? (public domain: US Government photo)
    Manual “test scripts” where a human interacts with the code to see if it works are insufficient and reflect technical debt. Your technical team should at least include unit tests. Test-driven development is a popular approach for ensuring that critical code is always tested.

    You can drive a non-technical conversation with your team about their “test coverage” (the portion of the code that is tested). It’s pretty simple: ask them to list their assumptions. Then ask where and how they test these assumptions.

    The checkpoint at which the code is believed complete by the developers is referred to in my shop as dev-complete. It means the primary development (dev) process is over, but additional code may be written to address issues that come up in the review process.

    In an agile development process, you will typically divide the implementation process into multiple checkpoints instead of one all-or-nothing deadline. These are typically called iterations.

    Refer to the roadmap you defined in the first step. Before starting new component(s), ensure that what you’ve already started is at least dev-complete. This provides you with an accurate view of the speed of development and reduces risk.

    As you complete the iterations, you can push the code to an environment for “acceptance testing.” This involves pilot or test users (or an internal team playing that role) who interact with the partial product. They test to ensure it meets the design expectations and provide feedback on how it could be better.

    Acceptance testing is not a substitute for the unit testing mentioned earlier. It serves a different purpose. Letting your development team lean on acceptance testing to catch basic functional bugs is a recipe for disaster.

    Feedback from the acceptance testers can be incorporated into the next iteration. This is another good reason not to bite off a big chunk of the product all at once. You want to leave room to change course once people start playing with the product.

    Once you’ve accumulated enough tested code to constitute a sufficient product release, you’re ready to begin the release management process.

    Looking for bugs in all the right places

    Your developer or team has reached a point where they believe the code is done. Acceptance testers are satisfied with the way the product is working. The next checkpoint in the process is to validate the belief that you have code ready to become a product. Let’s start reviewing the code!

    You may not be comfortable or have sufficient technical know-how to review the team’s code yourself. That’s ok! You don’t have to. Your process has to.

    Work with your team to identify a process for code review that works for them. If you have more than one developer, peer code review works great. If you don’t, are there other developers in your organization outside of your team? Work across team boundaries to establish a peer code review program.

    If there really is only one developer, then sit down with them and have them walk you through the code. Use your schematics as a reference point, and ask them to tell you how the code accomplishes the schematic’s goals.

    At the conclusion of the code review process, the developer and reviewer(s) should feel comfortable with being held accountable for the code.

    The code review is also a good time for reviewing two other critical points: documentation and security.

    I’ve already written about a sustainable documentation architecture — check it out if you’re interested!

    Security review should be a part of any code review. In general, this involves taking a second look at the code to spot weaknesses where an attacker could exploit it to reveal private data or gain control of the server. It must be done by a technical person.

    The Open Web Application Security Project (OWASP) publishes a free comprehensive guide to security review.

    Your developer can do this if they’re the only one on the team, even if they just run an automated security code analysis tool. There are free tools for helping with this process which are linked through the OWASP wiki.

    Eject, eject, eject!

    The code has passed the review process. It’s ready to become a product. But that doesn’t mean it’s ready for production.

    The last checkpoint to clear is deployment readiness. Is your code in a state where it’s easy to deploy to production? This should involve as few manual steps as possible.

    It also means you need to have a plan for reverting the change in case the code doesn’t work as planned. This is called a “rollback plan.”


    If you have a separate software operations team, this is where they come back into the picture. They should review the deployment and rollback documentation and let you know if it’s sufficient.

    If you don’t have these personnel you can perform this step yourself. Make sure that there are clear, simple instructions for deploying the product. There should be very few manual steps, as each manual step introduces a chance for human error.

    There should be a clear, sufficient plan for returning to the prior state of affairs if the deployment doesn’t succeed. This may be as simple as restoring a backup, or it may involve customer communication or data conversion.

    Whether the plan is sufficient depends on how thoroughly your team tested the code, and how widely the product is being released. Consider also any risks associated with the product or with this particular release.

    Once you’ve passed this checkpoint, push that code into production!

    Post-release

    Succeed or fail, it’s important to circle back and review how the process went.

    Did your team accurately estimate the effort required to release a product? Did the testing adequately model the production scenario? Revisit the implementation and testing checkpoints, and review how well the team performed.

    How is the product running in production? It’s a good idea to visit the operations staff and obtain their feedback. This further creates trust between the development and operations teams, and will lead to more DevOps benefits down the road.

    Where are the remaining gaps in your product? If they’re in third-party code, now’s the time to consider whether to customize your packages or re-implement from scratch. Otherwise, you now have input on what to build for the next release.

    Above all, hold yourself and your team accountable for the results of your effort.

    Accountability facilitates independence and promotes individual growth. As your team grows accustomed to being held accountable for each step in this process, they’ll adjust their performance accordingly.

    Conclusion

    You don’t have to be the least bit technical to run a successful software release process. Technical skill can help, but it can also become a crutch.

    The key to successful software release is a well-documented, well-understood process for moving software through the pipeline from idea to product. You now have a starting point for drafting your own software release process.

    What’s most important is that you participate with your team in filling in the blanks and creating a repeatable process that works for all of you.

    It doesn’t have to be perfect for anyone, but it does have to be understood by everyone.

    You also need to ensure that the velocity of your product through these checkpoints matches the demand for the product. None of these items need to be multi-day show-stoppers. It could be a simple one-page checklist. You need to define a process that fits your environment.

    As with any process, you should also iterate. Just like with the code, your first, untested draft isn’t likely to be perfect. Tune the process on each run-through and you’ll end up with a smooth, predictable software release path.

    And remember to brush your hair. You don’t want it looking…pointy.

  • 00:12:45

    Ep. 23 - We studied how students performed in technical interviews. Where they went to school didn't matter.

    The freeCodeCamp Podcast starstarstarstarstar
    add

    Given the state of college recruiting today, your chances of interacting with companies on campus are slim - unless your campus is a top school. It’s not fair, and it sucks, but that's the way it is. But does it have to be? Does where you went to school really affect your performance in technical interviews? Turns out: it doesn't.

    Written by Sam Jordan: sam@interviewing.io

    Recorded by Abbey Rennemeyer: https://twitter.com/abbeyrenn

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

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

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

    Transcript:

    interviewing.io is a platform where engineers practice technical interviewing anonymously. If things go well, they can unlock the ability to participate in real, but still anonymous, interviews with top companies like Twitch, Lyft and more.

    Earlier this year, we launched an offering specifically for university students. It was intended to help level the playing field right at the start of people’s careers.

    The problem

    Here’s the sad truth: given the state of college recruiting today, if you haven’t attended one of a very few top schools, your chances of interacting with companies on campus are slim. It’s not fair, and it sucks, but university recruiting is still dominated by career fairs. Companies pragmatically choose to visit the same few schools every year. Despite the fact that the career fair is one of the most antiquated, biased forms of recruiting that there is, the format persists. This is likely because there doesn’t seem to be a better way to quickly connect with students at scale.

    So, despite the increasingly loud conversation about diversity, campus recruiting marches on, and companies keep doing the same thing expecting different results.

    In a previous blog post, we explained why companies should stop courting students from the same five schools.

    Regardless of how important you think this idea is (for altruistic reasons, perhaps), you may still be skeptical about the value and practicality of broadening the college recruiting effort. You probably concede that it’s rational to visit top schools, given limited resources. Society is often willing to agree that there are perfectly qualified students coming out of non-top colleges, but they maintain that they’re relatively rare.

    We’re here to show you, with some nifty data from our university platform, that this is simply not true.

    To be fair, this isn’t the first time we’ve looked at whether where you went to school matters. In a previous post, we found that taking Udacity and Coursera programming classes mattered way more than where you went to school. And way back in the day, one of our founders figured out that where you went to school didn’t matter at all — but that the number of typos and grammatical errors on your resume did.

    So, what’s different this time? The big, exciting difference is that these prior analyses were focused mostly on engineers who had been working for at least a few years already. This made it possible to argue that a few years of work experience smoothes out any performance disparity that comes from having attended (or not attended) a top school.

    In fact, the good people at Google found that while GPA didn’t really matter after a few years of work, it did matter for college students. So, we wanted to face this question head-on and look specifically at college juniors and seniors while they were still in school. Even more pragmatically, we wanted to see if companies limiting their hiring efforts to just top schools were getting higher caliber candidates.

    Before delving into the numbers, here’s a quick rundown of how our university platform works and what kind of data we collect.

    The setup

    For students who want to practice on interviewing.io, the first step is a brief (~15-minute) coding assessment on Qualified to test basic programming competency. Students who pass this assessment (that is, those who are ready to code while another human being breathes down their necks) get to start booking practice interviews.

    When an interviewer and an interviewee match on our platform, they meet in a collaborative coding environment with voice, text chat, and a whiteboard and jump right into a technical question. Interview questions on the platform tend to fall into the category of what you’d encounter during a phone screen for a back-end software engineering role. Interviewers typically come from top companies like Google, Facebook, Dropbox, Airbnb, and more.

    After every interview, interviewers rate interviewees in a few different categories, including technical ability. Technical ability gets rated on a scale of 1 to 4, where 1 is “poor” and 4 is “amazing!” On our platform, a score of 3 or above has generally meant that the person was skilled enough to move forward.

    On our platform, we’re fortunate to have thousands of students from all over the U.S., spanning over 200 universities. We thought this presented a unique opportunity to look at the relationship between school tier and interview performance for both juniors (interns) and seniors (new grads).

    To study this relationship, we first split schools into the following four tiers, based on rankings from U.S. News & World Report:

    “Elite” schools (like MIT, Stanford, Carnegie Mellon, UC-Berkeley)
    Top 15 schools (not including top tier, like University of Wisconsin, Cornell, Columbia)
    Top 50 schools (not including top 15, like Ohio State University, NYU, Arizona State University)
    The rest (like Michigan State, Vanderbilt University, Northeastern University, UC-Santa Barbara)

    Then, we ran some statistical significance testing on interview scores vs. school tier to see if school tier mattered for both interns (college juniors) and new grads (college seniors). Our sample comprised a set of roughly 1,000 students.

    Does school have anything to do with interview performance?

    In the graphs below, you can see technical score distributions for interviews with students in each of the four school tiers (see legend). As you recall from above, each interview is scored on a scale of 1 to 4, where 1 is the worst and 4 is the best.

    What’s pretty startling is that the shape of these distributions, for both juniors and seniors, is remarkably similar. Indeed, statistical significance testing revealed no difference between students of any tier when it came to interview performance.

    Just to note: of course, this hinges on everyone completing a quick 15-minute coding challenge first, to ensure they’re ready for synchronous technical interviews. We’re excited about this because companies can replicate this step in their process as well!

    What this means is that top-tier students are achieving the same results as those in “no-name” schools. So the question becomes: if the students are comparable in skill, why are companies spending egregious amounts of money attracting only a subset of them?

    Okay, so what are companies missing?

    Besides missing out on great, cheaper-to-acquire future employees, companies are missing out on an opportunity to save time and money. Right now, a ridiculous amount of money is being spent on university recruiting. We’ve previously cited the $18k price tag just for entry to the MIT career fair. In a study done by Lauren Rivera through the Harvard Business Review, she reveals that one firm budgeted nearly 1 million dollars just for social recruiting events on a single campus.

    The higher price tag of these events also means that it makes even less sense for smaller companies or startups to try and compete with high-profile, high-profit tech giants. Most of the top schools that are being heavily pursued already have enough recruiters vying for their students. Unwittingly, this pursuit seems to run contrary to most companies’ desire for high diversity and long-term sustainable growth.

    Even when companies do believe that talent is evenly distributed across school tiers, there are still reasons why companies might recruit at top schools. There are other factors that help elevate certain schools in a recruiter’s mind. There are long-standing company-school relationships (for example, the number of alumni who work at the company currently). There are signaling effects, too — companies get Silicon Valley bonus points by saying their eng team is comprised of a bunch of ex-Stanford, ex-MIT ex-and so on students.

    A quick word about selection bias

    Since this post appeared on Hacker News, there’s been some loud, legitimate discussion about how the pool of students on interviewing.io may not be representative of the population at large. Indeed we do have a self-selected pool of students who decided to practice interviewing.

    Certainly, all the blog posts we publish are subject to this (very valid) line of criticism, as is this post in particular.

    As such, selection bias in our user pool might mean that 1) we’re getting only the worst students from top schools (because, presumably, the best ones don’t need the practice), or 2) we’re getting only the best/most motivated students from non-top schools — or both.

    Any subset of these results is entirely possible, but there are few reasons why we believe that what we’ve published here might hold truth regardless.

    First of all, in our experience, regardless of their background or pedigree, everyone is scared of technical interviewing. Case in point: before we started working on interviewing.io, we didn’t really have a product yet. So before investing a lot of time and heartache into this questionable undertaking, we wanted to test the waters to see if interview practice was something engineers really wanted — and more so, who these engineers that wanted practice were.

    So, we put up a pretty mediocre landing page on Hacker News…and got something like 7,000 signups on the first day. Of these 7,000 signups, roughly 25% were senior (4+ years of experience) engineers from companies like Google and Facebook. Now, this isn’t to say that they’re necessarily the best engineers out there, but it does suggest that the engineers the market seems to value the most still needed our services.

    Another data point comes from one of our founders. Every year, Aline does a guest lecture on job search preparedness for a technical communication course at MIT. This course is one way to fulfill the computer science major communication requirement, so enrollment tends to span the gamut of computer science students. Before every lecture, she sends out a survey asking students what their biggest pain points are in preparing for their job search. Every year, trepidation about technical interviewing is either at the top of the list of 2nd from the top.

    And though this doesn’t directly address the issue of whether we’re only getting the “best of the worst or the worst of the best” (and I hope the above has convinced you there’s more to it than that), here’s the distribution of school tiers among our users. I expect it mirrors the kinds of distributions companies see in their student applicant pool as well:

    So what can companies do?

    Companies may never stop recruiting at top-tier schools entirely. But they ought to at least include schools outside of that very small circle in the search for future employees.

    The end result of the data is the same: for good engineers, the school they attended means a lot less than we think. The time and money that companies spend to compete for candidates within the same select few schools would be better spent creating opportunities that include everyone. They could also develop tools to vet students more fairly and efficiently.

    As you saw above, we used a 15-minute coding assessment to cull our inbound student flow, and just a short challenge leveled the playing field between students from all walks of life. At the very least, we’d recommend employers do the same thing in their process. But, of course, we’d be remiss if we didn’t suggest one other thing.

    At interviewing.io, we’ve proudly built a platform that grants the best-performing students access to top employers, no matter where they went to school or where they come from. Our university program, in particular, allows us to grant companies the privilege to reach an exponentially larger pool of students, for the same cost of attending one or two career fairs at top target schools.

    Want diverse, top talent without the chase? Sign up to be an employer on our university platform!

  • 00:10:51

    Ep. 22 - Our team broke up with "instant legacy" code releases. Here's how yours can, too.

    The freeCodeCamp Podcast starstarstarstarstar
    add

    The concept of a legacy usually conveys permanence, value, and greatness. But what about in relation to your code? In this article, Jonathan explains how his team broke up with their legacy codebase, why it was necessary, and how your team can do the same.

    Written and read by Jonathan Solózano-Hamilton: https://twitter.com/jhsolor

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

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

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

    Transcript:

    The concept of legacy conveys permanence, value, and the greatness we bequeath to our children and our successors in the community.

    People make ludicrously generous donations to charitable causes to establish their legacy. They create eponymous endowments or buildings and strive to protect the name their children will inherit.

    It’s therefore striking that software developers have gotten their “legacy” so catastrophically wrong.

    Google “legacy,” and you’ll see the first definition matches what I’ve laid out for you here. It’s a definition that’s persisted since the 14th or 15th century.

    The second definition provides a shocking contrast:

    legacy. adjective (computing) “denoting software or hardware that has been superseded but is difficult to replace because of its wide use.

    Dictionaries around the internet agree with this definition. It applies only to the field of computing. We developers have managed to invert the definition of our own legacy in the historical eye-blink that is computer science. That’s almost impressive!

    If you’re an experienced developer, you’ve certainly been tasked with supporting at least one legacy system in your career. For the uninitiated, well — buy a lot of caffeinated beverages.

    I’m about to relate to you the brief story of our toxic relationship with our legacy codebase. I’ll then describe how we broke up with it, and what we’ve changed to avoid falling back into bad relationships with high-maintenance code.

    The Breakup

    It took eight months of seven-day weeks and twelve-hour days to complete our last legacy system overhaul.

    Our predecessors had pushed code into production for years without writing a single line of documentation. In fact, some of it wasn’t even in source control, as we later learned. But that’s another story.

    I’m sure you’ve seen gems like this before:

    ... hundreds of line of incomprehensible code
    // TODO: Fix this bug!!!
    ... hundreds more lines in the same method, no idea where or what the bug is

    That is the approximate ratio and quality of the only documentation we had on the project.

    I wasn’t exposed to direct sunlight again until April, and I’d had enough. It was time for a break-up.

    The importance of documentation

    In his book “The Art of Unit Testing,” Roy Osherove defines legacy code as any code that doesn’t have tests. He was an optimist. I more loosely regard as legacy any code which contains more technical debt than the time it took to write.

    As our organization had, many development teams fall into the trap of instant-legacy code: code that already fits the “legacy code” label at the time of release.

    In my experience, documentation is the most important aspect of avoiding such legacy code.

    I have yet to meet a developer who loves the idea of documentation. On the other hand, I also have never met a developer who loves crawling inside the skull of a stranger to reverse-engineer a legacy implementation without any documentation.

    As they say, breaking up is hard to do. But in this case, I promise it will be worth it.

    So let’s get started on converting your legacy into something you’ll be proud to bequeath to your successors. Let’s get documenting!

    Our approach: four layers of documentation

    We created, and began rigorously following, a four-layer architecture for documentation. We maintain three layers of persistent documentation for the project through its life-cycle. We also communicate through one layer of ephemeral documentation during our release management process.

    The three persistent layers of documentation correlate to three different velocities in our development process. We include documentation review as part of code review to avoid falling back into bad habits.

    // The front lines: in-line comments keep maintainers sane

    The most granular tier of explicit documentation is in the code. We perform complete documentation of all classes and methods, their inputs, expected outputs, and exception pathways. We also document “unusual” code in-line.

    As a predominantly C# shop we use /// documentation ubiquitously. This decorates class, interface, and method declarations. The /// helper auto-generates XML stubs to document the nuts and bolts of the API.

    These pop up when your code is being referenced by an external project or DLL (dynamic-link library), provided that you’ve distributed the debugging files. Our IDE (integrated development environment) renders this as tool-tip help wherever a reference appears. This greatly aids developers, who are diving into our code for the first time, when trying to fix a bug or extend it for a new use case.

    It’s worth researching your language and IDE of choice to learn how to extend it with contextual help for your libraries. If you’re not used to documenting your APIs, I suggest reading these articles to get started.

    We also include regular // comments beyond API documentation. We add these wherever the code is counter-intuitive, or if we’ve found a particularly elegant solution to a problem. We also use these to create “to-do’s” for later refactor when putting in a quick-and-dirty fix.

    These are invaluable to whoever has to come along and revert the change or fix the code.

    Because it’s in-line with the source code, this documentation changes at the highest velocity — right along with the code it supports.

    README: making implementation a breeze

    We use README files as an implementer’s guide. This documentation is for whoever will be consuming our libraries. It serves a secondary purpose as tactical-level documentation of the particulars of the implementation.

    We use GitHub for source control, so we place readme.md (Markdown) files in each folder in our GitHub repository. GitHub very nicely renders Markdown files and automatically shows the rendered readme.md files in each folder. This results in a much more usable help file than a simple .txt document.

    Storing this documentation in the code-base helps developers maintain the documentation. Anyone making a code change can easily open the .MD file in their source code editor or an online markdown editor, and immediately update the documentation.

    Thus the source-controlled Markdown files live next to, but not within, the code they support. It’s also somewhat more “zoomed out” than inline comments. These two factors result in a lower velocity of updates on this documentation. Because you can still include it in the same commits it changes with higher velocity than offline documentation.

    The final advantage of this format is that anyone who downloads the source code has immediate access to the implementation guides. Coupled with the inline documentation, this provides both maintainers and consumers with sufficient documentation. They can develop a basic understanding of the project without jumping into another system, such as a wiki.

    Wiki: where business meets development

    We use the wiki-level documentation to marry the implementation to the business requirements. This documentation consists primarily of requirements, enterprise architecture diagrams and considerations, and tactical diagrams such as unified modeling language (UML) flow charts and class diagrams.

    We also use pages (on the same wiki) as meeting minutes, and to record decisions. We use a wiki which has versioning so that we can see a complete history of how requirements and designs have changed over time.

    We thereby ensure a complete history of the requirements process and how it relates to the changing architecture. Incidentally, GitHub also provides a wiki feature, but we use a third-party wiki which integrates with our project management software.

    Release management: commit and pull request comments

    Our release management process includes code review. Our code review includes documentation review.

    As GitHub is our source control platform, we bake code review into our pull requests. The platform supports commenting upon check-in, inline comment threads on portions of commits, and a conversation thread on the pull request.

    The key to using these communication channels successfully is to ensure that all discussions result in a tangible output. Either clarify the code itself, or extend the permanent documentation in response to questions.

    If the reviewer doesn’t understand the code as it is written, future developers won’t either. Rewrite the code to be more self-explanatory, or extend the in-line or readme documentation.

    It’s not sufficient to end the conversation by replying to the thread: we treat this documentation as ephemeral, and on a long-lived code-base it’s a pain to review the full commit history.

    Bonus round: self-documenting code

    Finally, one quick plug for so-called “self-documenting code.” I’m a firm believer that the code should be self-explanatory at the surface. Explicit documentation should provide context or improve maintainability.

    There are already good articles about this (here’s one), so I won’t go into detail here.

    Final thoughts

    I hope that you learn from our experience. Our four-layer documentation architecture may not work for you, but it’s important to figure out what will.

    The big take-aways? First, it’s necessary to develop a healthy understanding of yourself and your own needs before you entangle yourself with a new code base.

    Second, it’s easier to stay out of a bad relationship with legacy code than to extract yourself once you’re already committed.

    And third, you only leave one legacy. But every commit you make contributes to it. They won’t all be good, they won’t all be bad, but they should at least be clear. Please think about what you’re leaving for those who come after you.

    Together we can reclaim our legacy as developers.

  • 00:06:58

    Ep. 21 - What is an API? In English, please.

    The freeCodeCamp Podcast starstarstarstarstar
    add

    Many people have a vague or incorrect idea of what the fairly common term "API" means. Heads up: it's not a type of beer! Petr lays out the basic details of an application programming interface in plain English so you'll never be confused again.

    Written by Petr Gazarov: https://twitter.com/PetrGazarov

    Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn

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

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

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

    Transcript:

    Before I learned software development, API sounded like a kind of beer.

    Today I use the term so often that I have in fact recently tried to order an API at a bar.

    The bartender’s response was to throw a 404: resource not found.

    I meet lots of people, both working in tech and elsewhere, who have a rather vague or incorrect idea about what this fairly common term means.

    Technically, API stands for Application Programming Interface. At some point or another, most large companies have built APIs for their customers, or for internal use.

    But how do you explain API in plain English? And is there a broader meaning than the one used in development and business? First, let’s pull back and look at how the web itself works.

    WWW and remote servers

    When I think about the Web, I imagine a large network of connected servers.

    Every page on the internet is stored somewhere on a remote server. A remote server is not so mystical after all — it’s just a part of a remotely located computer that is optimized to process requests.

    To put things in perspective, you can spin up a server on your laptop capable of serving an entire website to the Web (in fact, a local server is what engineers use to develop websites before releasing them to the public).

    When you type www.facebook.com into your browser, a request goes out to Facebook’s remote server. Once your browser receives the response, it interprets the code and displays the page.

    To the browser, also known as the client, Facebook’s server is an API. This means that every time you visit a page on the Web, you interact with some remote server’s API.

    An API isn’t the same as the remote server — rather it is the part of the server that receives requests and sends responses.

    APIs as a way to serve your customers

    You’ve probably heard of companies packaging APIs as products. For example, Weather Underground sells access to its weather data API.

    Example scenario: Your small business’s website has a form used to sign clients up for appointments. You want to give your clients the ability to automatically create a Google calendar event with the details for that appointment.

    API use: The idea is to have your website’s server talk directly to Google’s server with a request to create an event with the given details. Your server would then receive Google’s response, process it, and send back relevant information to the browser, such as a confirmation message to the user.

    Alternatively, your browser can often send an API request directly to Google’s server bypassing your server.

    How is this Google Calendar’s API different from the API of any other remote server out there?

    In technical terms, the difference is the format of the request and the response.

    To render the whole web page, your browser expects a response in HTML, which contains presentational code, while Google Calendar’s API call would just return the data — likely in a format like JSON.

    If your website’s server is making the API request, then your website’s server is the client (similar to your browser being the client when you use it to navigate to a website).

    From your users perspective, APIs allow them to complete the action without leaving your website.

    Most modern websites consume at least some third-party APIs.

    Many problems already have a third-party solution, be it in the form of a library or service. It’s often just easier and more reliable to use an existing solution.

    It’s not uncommon for development teams to break up their application into multiple servers that talk to each other via APIs. The servers that perform helper functions for the main application server are commonly referred to as microservices.

    To summarize, when a company offers an API to their customers, it just means that they’ve built a set of dedicated URLs that return pure data responses — meaning the responses won’t contain the kind of presentational overhead that you would expect in a graphical user interface like a website.

    Can you make these requests with your browser? Often, yes. Since the actual HTTP transmission happens in text, your browser will always do the best it can to display the response.

    For example, you can access GitHub’s API directly with your browser without even needing an access token. Here’s the JSON response you get when you visit a GitHub user’s API route in your browser (https://api.github.com/users/petrgazarov).

    The browser seems to have done just fine displaying a JSON response. A JSON response like this is ready for use in your code. It‘s easy to extract data from this text. Then you can do whatever you want with the data.

    A is for “Application”

    To close off, let’s throw in a couple more examples of APIs.

    “Application” can refer to many things. Here are some of them in the context of API:

    A piece of software with a distinct function.

    The whole server, the whole app, or just a small part of an app.

    Basically any piece of software that can be distinctively separated from its environment, can be an “A” in API, and will probably also have some sort of API.

    Let’s say you’re using a third-party library in your code. Once incorporated into your code, a library becomes part of your overall app. Being a distinct piece of software, the library would likely have an API which allows it to interact with the rest of your code.

    Here’s another example: In Object Oriented Design, code is organized into objects. Your application may have hundreds of objects defined that can interact with one another.

    Each object has an API — a set of public methods and properties that it uses to interact with other objects in your application.

    An object may also have inner logic that is private, meaning that it’s hidden from the outside scope (and not an API).

    From what we have covered, I hope you take away the broader meaning of API as well as the more common uses of the term today.

  • 00:23:46

    Ep. 20 - Basics of Machine Learning - interview with Nishant Shukla

    The freeCodeCamp Podcast starstarstarstarstar
    add

    Nishant Shukla is the author of Machine Learning in TensorFlow, and is also the VP of Engineering at a startup focussing on Artificial Intelligence technologies for education. In this episode, he discusses the basics of machine learning. Learn more about his book at http://tensorflowbook.com/

    Interviewer: Beau Carnes - https://twitter.com/CarnesBeau

    Interviewee: Nishant Shukla - https://twitter.com/binroot

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

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

  • 00:13:54

    Ep. 19 - Don't worry, be happy: how to build your future tech career in 5 simple steps

    The freeCodeCamp Podcast starstarstarstarstar
    add

    Changing careers is very difficult. Add in a full-time job and a couple of kids, and the task seems nearly impossible. But even if you're busy, you can make the time to build the skills to level up your career. Here's how Michael Tombor did just that.

    Written and read by Michael Tombor: https://twitter.com/michaeltombor

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

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

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

    Transcript:

    “Instead of saying “I don’t have time” try saying “It’s not a priority,” and see how that feels.” — Laura Vanderkam

    Changing careers is very difficult. Add in a full-time job and a couple of kids and the task seems nearly impossible. Yet, even if you are busy, you can prioritize and make the time to focus on what matters to you and build the skills to level up your career.

    Engineer your future with code

    I started my coding journey just six months ago. Now I am one project away from completing my front-end developer certificate on freeCodeCamp. I’ve also completed the web developer boot camp course by Colt Steele on Udemy. And I did this all while raising two kids and working in a full-time job.

    When I began using these tips, I saw my progress increase tenfold. I know I would have accomplished much more if I had implemented them earlier in my journey. I have not only benefited from increased productivity, but I feel more balanced and am having more fun than ever before.

    My pivot into web development

    After being in health care for the last five years, I realized that it wasn’t what I wanted to do for the rest of my life. Don’t get me wrong - I loved helping people on their path to health, but I hated seeing the system break down for them. I hated when people could not afford their medication, or when their care plan wasn’t in sync with the treatment they needed.

    I wanted to do more to help these people. But I knew that I couldn’t do more unless I took a step back and looked at the bigger picture.

    I was not always interested in coding, but the more I looked at the forces making real change in today’s world, the more I saw that tech was behind these advances.

    I saw an opportunity to make meaningful change, and that is when I became interested in coding.

    Why are you coding?

    Whatever the reason is, really think about it and pin it down. Use it as motivation to propel you towards your coding goals. Having this end goal will help you bust through plateaus and push through the hard parts (coding is hard).

    Every day that I spend at my current day job motivates me to get home, boot up my laptop, and continue my journey of learning how to code.

    The good news is that building coding skills is simple. All you have to do is code a lot. But unfortunately, this is where the hard part comes in. Fitting time into your busy life to routinely code is difficult, to say the least.

    How to climb the coding mountain

    There is a gap between where you are now and where you want to be. That is why you are reading this article. That is why you work day in and out, and end up sacrificing time with your family and loved ones.

    If we are spending all this time working towards our goal, it is paramount to make the most of the time we spend learning how to code.

    Here are five steps to turn this dream into a reality:

    Create your personalized goals

    To make the most of your time, nothing is more important than making actionable short-term goals. This will not only help you feel a sense of accomplishment every time you meet a goal, but it will help make the coding journey feel a lot less daunting.

    Goals Exercise!

    To help you come up with focused goals, I want to encourage you to do a quick exercise that I picked up from Laura Vanderkam.

    1. Picture yourself one year from now. You have crushed ALL your coding goals and landed your dream job. You have given five talks at conferences around the world, and you built up your App and it was successful. Whatever success looks like to you, picture your future self. Please be ambitious, maybe even dream a little.

    2. What 3 - 5 goals did you accomplish in that year that made it so successful?

    3. Write these goals down.

    4. Repeat this exercise for your personal life goals. It is impossible to work all the time, and to be successful you need work life balance (or you will burn out).

    Now you have 6 - 10 ambitious goals that you want to accomplish during the next year. To break these larger goals down into action items, think about and plan about how you can meet these goals.

    For example, if you want to complete the freeCodeCamp front end certificate, you need to schedule time to work on it throughout the week. If you want to run a marathon, you need to buy running shoes, sign up for a marathon, and schedule time to train regularly.

    2. Make a Schedule

    I’ll be honest - I am definitely not the scheduling type. I thought that I could wing it day by day. But realistically, you need to set time aside to focus, or your goals will pour over into the rest of your life. I found myself feeling anxious about coding during time with my family or when I was putting my kids to bed, because I hadn’t coded yet that day.

    The thing I looked forward to all day (coding) started to negatively impact my quality of life.

    Splitting your time into focused blocks allows you to be 100% in the present moment. When it is coding time, you can have tunnel vision and hack away. When it is time to unwind, or hang out with people you care about, you can be present because you coded that morning, or have time scheduled later in the day.

    I schedule a lot of family time. Family is really important to me. Your schedule will look a lot different, but the point is to create a schedule that will allow you to meet your goals without you hating life along the way. Just try to account for everything, so you can stick to your schedule.

    3. Audit yourself to find time opportunities

    Write down all the activities in a given day or week and see what you really do with your time. You will likely be surprised by exactly how much time you spend mindlessly scrolling through your Instagram feed, or binge watching a new Netflix show (I love Stranger Things).

    I’m not telling you to cut all of it out but keep a balance. You can definitely turn some of that idle time into some serious coding gains.

    There is more time than you think

    If you are still thinking to yourself, “yeah, but I still work a lot and (insert excuse here) so I can’t find time”, then here is a fun fact! There are 168 hours in a week. If you work a full 40 hour week and subtract 8 hours of sleep per night (which I definitely don’t get) you still end up with 72 hours of “free” time.

    Look at all the time you have in your life situation and squeeze as much “good” stuff into that time as you can. There IS time.

    4. Fill your time with quality


    Here are some tools that I use to help me accomplish my coding goals and stay focused on my learning path:

    freeCodeCamp

    Seriously one of the best tools for meeting goals. The curriculum is right there for you to follow and work on, it even tracks your progress!

    JavaScript 30

    30 JavaScript projects really help you master array methods while filling up your portfolio with projects (plus it is tons of fun). Wes Bos is a solid instructor who provides a quality free course. You can complete it in 30 consecutive days, or work it into your learning schedule.

    100 Days of code on Twitter

    This 100 day challenge consists of coding every day and tweeting about what you did. It is a great tool for tracking progress and measuring how far you have come. This community is full of inspiring people from all over the world and is a great way to meet like minded developers.

    The Web Developer Boot Camp

    I am almost finished with this course, and it has patched a lot of holes in my coding knowledge. Colt doesn’t just show you how to do something, he also explains why you do it a certain way. Plus, there is now an advanced web developer boot camp that I am going to take once I’m done.

    Live It!

    This isn’t a resource, but you should embrace the tech community by living it. Listen to podcasts while you drive to work or do the dishes. Follow leaders in the industry on Twitter. Read articles. Immerse yourself in tech and you will learn without realizing you are learning.

    5. Multiply your time

    We have set goals, and now have several larger goals broken down into actionable goals. We have gone through how to fit these goals into your busy life and I have helped give you some ideas on how to fill your time. Now, I want to tell you how you can make the most out of the time you put into coding.

    The Answer: Be Happy!

    What does being happy have to do with managing time, you ask? Simply put: it is everything. The idea is called multiplying your time.

    Being present and deeply focused leads to increased productivity. This in turn multiplies the time you spend by increasing efficiency. Plus, who doesn’t want to be happy?

    According to Shawn Achor, who studied the effects of happiness and its link to productivity, your brain performs 31% more productively when you feel happy.

    Dopamine, which floods into your system when you feel positive, does two things:

    It makes you happier (duh!)

    It turns on the learning centers in your brain. They help you learn things more easily, and allow you to spend less time on learning while retaining more information.

    Turn your brain into a dopamine producing machine!

    You can release more dopamine by creating lasting, positive change. There are five things you can work into your routine to turn your brain into a dopamine producing machine:

    1. Write three new things that you’re grateful for each day. This creates the habit of scanning the world for positive things, instead of negative ones.

    2. Journal about a positive experience you had in the last 24 hours. This allows you to relive the positive experience which leads to the same dopamine response.

    3. Exercise. Go on a short walk before a coding session, or bust out a quick workout. Exercise releases tons of dopamine.

    4. Meditate. Meditation trains your brain to focus more on the task at hand, all while releasing dopamine.

    5. Random acts of kindness. Thank someone in your social support network for helping you, or help someone out. This not only releases dopamine for you, it also does the same for the person you helped (and they may pay it forward).

    Use blocks of time to build your future

    Even if we are busy, we must take out time for the things that matter the most. When you focus on what matters, you can build the life you want with the blocks of time you have.

  • 00:18:04

    Ep. 18 - Why I studied full time for 8 months for a Google interview

    The freeCodeCamp Podcast starstarstarstarstar
    add

    It’s true. John spent thousands of hours reading books, writing code, and watching computer science lectures, all to prepare for his dream job interview at Google. When things didn't go his way, he shifted gears. Here's his story.

    Written by John Washam: https://twitter.com/startupnextdoor

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

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

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

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

    Transcript:

    It’s true. I’ve spent thousands of hours reading books, writing code, and watching computer science lectures, all to prepare for the Google software engineer interview.

    How I Got Here

    I started programming in middle school, but when it came time for college I pursued a degree in Economics. My rationale was that there would be too many programmers looking for jobs by the time I graduated. Boy, I was wrong.

    Later, I joined the Army to become a programmer, but the recruiter talked me into a military intelligence position, and I spent the next two years studying the Korean language. I served in South Korea for 2 years afterward.

    Before I left the Army, I attempted to get back into programming and was surprised at the difficulty. I had learned BASIC in middle school and kept programming it through high school. But I restarted my programming studies with C++, and the leap was too large. I just couldn’t grasp it.

    I did enjoy making websites, however, but I used software with a Word-like interface that I used to publish my websites. I didn’t know how to make websites from scratch.

    After the Army, I decided to stay in Korea for a year and teach English. I used my nights and weekends to study web programming, using Perl, HTML, CSS (which was new at the time), JavaScript, and SQL.

    After a year of intense study, I landed a job in the Seattle area, and I’ve been here ever since.

    I’ve been a web developer now for 15 years. I’ve started 3 companies, 2 of which are still running and generating revenue. I’ve worked at large and small companies, helped startups launch and grow, and recruited and managed teams. I’ve been a product manager, a CEO, a designer, and a marketer.

    I’ve had a successful career and learned a lot along the way. But I’m not done yet.

    Seeking a Career Change

    Remember the part where I didn’t get a computer science degree? It has made a difference.

    A few years ago, I thought I could get hired anywhere. I thought I was hot stuff: the elusive full-stack web developer. But during my job search in 2013, I realized my skills were lacking. I had spent so much time chasing dollars by running startups in my spare time, that I had let my skills atrophy. I hadn’t kept up with technology.

    For years, I had learned just enough to get by. I had a wide skill set but wasn’t an expert in anything.

    Don’t get me wrong, I could still get hired, but not in the technologies or areas I wanted to work in. I could get hired for areas where the tech stack was somewhat outdated, like me. There’s big money in there, but I didn’t see exciting prospects.

    The realization reached its peak last year at a career fair. I was interested in perhaps working for one of the local companies that were startup labs run by venture capital firms. However, the fact that I lacked a computer science degree, and the skills and knowledge that accompany such a degree, meant I didn’t have a chance.

    I was working full-time on my businesses at the time, and still am today.

    At the beginning of 2016, I decided it was time to make a career change from web developer to software engineer. I would need to study hard and practice in order to compress a computer science degree into a few months, but once I did, I could start a new career.

    You may not see web development and software engineering as different positions. Both involve programming and craftsmanship, but software engineering adds to it knowledge of data structures and algorithms, compiled languages, memory considerations, and understanding the impact of coding and architecture decisions on the machines where they reside.

    Large companies that hire for software engineering positions expect candidates to have this knowledge.

    I reached out to an acquaintance who works at Google and asked him questions about his experience at the company. I had been reading How Google Works and was pretty familiar with Google already.

    Through another contact, I received a copy of Google’s coaching notes that are provided to interview candidates. This became the basis of my study plan.

    Google is a pretty awesome place to work, but before I even knew that, Google was my goal.

    Why Google?

    Google sets a very high bar for hiring. They want to hire only the best. So if I set my sights high (getting hired at Google), I’ll still be quite hireable elsewhere even if I’m not selected.

    The more I learn about Google, the more I want to work there.

    In brief, Google is a company that hires smart, creative people, and treats them well. Google rewards merit, encourages big ideas, and gives employees the freedom to make good decisions for the user.

    The hiring process is calibrated to bring in smart, passionate people. Google has honed the recruitment and interview process over the years. The brain teaser questions are long gone. Nowadays candidates are chosen based on coding ability, technical knowledge, and Googleyness. There’s a lot going on in that one word.

    Management is different. Managers don’t micro-manage. They trust engineers to make the right decisions. Trusting employees changes the role of managers at Google from what most folks envision when they think of management. In addition, managers can’t unilaterally, hire, fire, or promote. Many of the important management decisions that could be perceived as office politics are handled by a committee to remove that danger.

    Google’s people operations (HR) has learned what works over time, and they use data and employee feedback to improve evaluation systems, the hiring process, promotions, compensation, benefits, and more. Read Work Rules! by Laszlo Bock (SVP, People Operations) for more.

    Yes, the benefits are amazing. I went on a tour of the Google office in Kirkland, WA, and it surpassed my expectations. And my expectations were already high.

    Google Interview University

    Remember the coaching notes I received telling me what to study? The list of topics seemed manageable, even though I didn’t know anything on the list.

    I turned the topics on the notes into an outline and started filling in the topics with YouTube videos of lectures from MIT and UC Berkeley. A video on linked lists in one place, a video about queues in another. The list started to grow.

    I published the list on Github because my Github account was pretty empty. Since all the code I wrote for my businesses and work was private, my Github account made it look like I didn’t code at all. I needed to build up a portfolio. I originally called the project “Project 9894”. Google launched on Sept 4, 1998. Hence the name. I later renamed it to “Google Interview University”.

    Over time I added some optional topics that I discovered along the way.

    I was pretty amazed I had gotten so far in my career without even knowing how a CPU processed a program, how memory worked, or any of it. I had known “just enough” to be a success.

    My little Github project started getting a few stars, and I published a blog post celebrating 20 stars.

    One morning, I awoke to find it had grown to 120 stars. Someone famous had tweeted about it during the night, and that led to it ending up on the Github daily trending report. I was #1 trending on Github for a few days.

    Many kind people reached out to thank and encourage me. It turns out there are thousands of people who want to not only work at Google but want to work as a software engineer, and this list was just the to-do list they needed.

    It’s now at over 21,000 stars.

    I still can’t believe it.

    What If I Don’t Get the Job?

    It won’t be the end of the world.

    I’ve put the time and dedication into my studies for the goal of getting hired as a Google software engineer, but even if I fail, I’ll still be armed with the skills and knowledge required to work as a software engineer at any company.

    Wherever I end up, I’m going in as an entry-level software engineer. I’m not going in with 15 years of software engineering experience because I simply don’t have it. When it comes to this stuff, I’m the equivalent of a fresh CS grad.

    But I have the enthusiasm of a new grad, too. This is a new world for me. I’m just getting started. I’m not afraid to make mistakes. I know I will. I also want to learn everything I can and be an excellent addition to any team.

    Don’t Study As Much As I Did

    Yes, I took 8 months. But I could have abbreviated the process. Like any startup with a big goal, you make mistakes and do things that waste time. There are many things I wish I go back and do differently.

    I studied topics I didn’t need to, some because I thought I would need them for the interview, and some because I wanted to have the knowledge on hand for when I started working. I didn’t want to be a burden on the team I’m assigned to. It turns out I simply over-prepared.

    I spent 3 weeks reading a 1,000-page book on C++. I don’t remember 1,000 pages worth, but I know a good bit about C++ now. As it turns out, I’m using Python for the interview, not C++. I had assumed I needed C++, C, or Java, but I was wrong. It’s good to ask, not assume.

    I read way more books than I needed to. There are only 3 or 4 books I should have read.

    I have a code catalog of dozens of algorithms that I review, most of which I wouldn’t expect in an interview. You don’t need to do that.

    I watched many hours of YouTube videos but could have watched far less, and spread out topics over time.

    I should have stopped reading books and watching videos earlier and started on coding problems sooner. I would have been able to spend more time applying the topics I learned.

    Spaced repetition is the key to memorization. Once you learn something, review it again later, and again even later. At each repetition, you reinforce your learning. Spending hours and hours at one time on priority queues won’t make you an expert. You become an expert by revisiting and reviewing over time. If you do so, you’ll get to the point where can’t forget details.

    To help review, I made 1,792 flashcards (digital flashcards). This is way too many. I review them on my phone or tablet whenever I get a spare moment (such as during Christmas shopping). Flash cards and spaced repetition go hand-in-hand. Once I get an answer on a flashcard right, I don’t mark it as known. I keep it in the deck and once I’ve seen it and answered it correctly many times, then I mark it as known.

    My sense of fear (“What if they ask me a question about red-black trees?”) led me to study far more topics than I needed to.

    But I didn’t want to just prepare for the interview, I wanted to prepare for a career at Google, solving large-scale problems. That means knowing algorithms that will save computing resources of time, space, and I/O.

    I may never need to know a maximum flow algorithm (Ford-Fulkerson), but it’s nice to know I have that tool available if the situation arises (without memorizing the implementation), and can recognize its application to a problem space.

    Conclusion

    Early on, I wished I could skip all this learning, and just hurry up and get hired so I could instead spend my time learning the languages and tools for the team I join. But along the way, I realized how important this knowledge is, and even though most of it may not be applicable on a daily basis, I’m glad I put in the effort. I have a new appreciation of the history of computing, the greats in the field, data structures and algorithms (and how they complement each other), and how computer systems work at low-level.

    I’ll be putting in my application soon. It’s been a long journey getting to this point — almost an entire year. It began back in January, but I wasn’t able to commit to full-time study until April.

    I’m about as prepared as I can be. I can’t keep studying and putting off the application forever. At some point, I have to take the leap.

    I see a bright future ahead.

    First of all, thank you to everyone who cheered me on and supported me with your kind words over the last few months. I appreciate all of you so much. Your encouragement helped me get back to the whiteboard every day and practice.

    Why didn’t I get hired?

    I don’t know why.

    Last week I received a rejection email from the recruiter, and at first, I thought it was a mistake, and laughed it off. I checked in with my referral and he inquired into it and lobbied on my behalf, but in the end, it didn’t change the situation.

    The thing that bothers me is that I didn’t even get a phone screen. I didn’t even talk to a recruiter over the phone. After all this work and enthusiasm, I didn’t even get a chance to prove myself.

    I’ve done a lot of speculation about the reason why, but I won’t do that here. It’s all just guessing, which accomplishes nothing.

    But I still like Google. However, I don’t know if I’ll apply again in the future. I want to get hired and stay at a company for a long time. I don’t want to hop around. The company that ends up hiring me will get a loyal, hardworking, enthusiastic employee. There are a lot of places where I can strive for greatness and have that effort rewarded.

    Respect your Recruiter

    Recruiters look at hundreds of resumes every day, and they are highly tuned to detecting quality candidates and rejecting those who don’t match up with their model. For some reason, I just didn’t fit the profile. They probably are doing me a favor. It’s possible that I would have been in over my head and continually dragged my team down. Google is known for having false negatives in their selection process, but if you’re good enough for Google, you’ll eventually get in.

    Recruiters know what works, and what doesn’t. So respect their decision and be polite. I’ll bet they deal with irate rejected candidates on a daily basis, so don’t be like that. Just get more experience and knowledge and try again later.

    As you may know, the last 11 months have been very difficult for me. As a self-taught web developer of 15 years, my computer science study plan took me months to get through, and the main motivator was to start a new career as a software engineer, tackling large problems at a large tech company.

    Google was the company I had audaciously set my sights on, but in the end that turned into disappointment. If you haven’t read about my story, you’re missing out. Go ahead and read it first.

    Well, I reached out to my network, and made a lot of new friends. I got connected with every tech giant in the Pacific northwest. Of all of them, Amazon had always stood out — even more than Google — as the most innovative company over the last 10 years. I applied via a referral, whom I had met at a startup event in 2013, and got the process rolling.

    After so many months of non-stop effort, sacrifice, and worry, I’m pleased to announce that I finally made it!

    Today I accepted an offer to be a Software Development Engineer at Amazon.com.

  • 00:17:32

    Ep. 17 - From side project to $17,000/month business

    The freeCodeCamp Podcast starstarstarstarstar
    add

    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.

  • 00:15:10

    Ep. 16 - From programming with a Nokia feature phone to working for an MIT startup

    The freeCodeCamp Podcast starstarstarstarstar
    add

    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.

  • 00:26:45

    Ep. 15 - How I replicated an $86 million project in 57 lines of code

    The freeCodeCamp Podcast starstarstarstarstar
    add

    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.

  • 00:15:57

    Ep. 14 - How to Go From Hobbyist to Professional Developer

    The freeCodeCamp Podcast starstarstarstarstar
    add

    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.

  • 00:34:35

    Ep. 13 - Ten Rules for Negotiating a Job Offer Part 2

    The freeCodeCamp Podcast starstarstarstarstar
    add

    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

  • 00:27:29

    Ep. 12 - Ten Rules for Negotiating a Job Offer

    The freeCodeCamp Podcast starstarstarstarstar
    add

    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.

  • 00:10:50

    Ep. 11 - Programming is hard. That’s precisely why you should learn it.

    The freeCodeCamp Podcast starstarstarstarstar
    add

    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.

  • 00:13:42

    Ep. 10 - We fired our top developer talent. Best decision we ever made.

    The freeCodeCamp Podcast starstarstarstarstar
    add

    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.

  • 00:11:29

    Ep. 9 - How I went from fashion model to software engineer in 1 year

    The freeCodeCamp Podcast starstarstarstarstar
    add

    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!

  • 00:09:48

    Ep. 8 - I spent 3 months applying to jobs after a coding bootcamp. Here’s what I learned.

    The freeCodeCamp Podcast starstarstarstarstar
    add

    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 firstName@dreamCompany.com. For larger companies, it may be firstName.lastName@dreamCompany.com.

    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.

  • 00:09:59

    Ep. 7 - The code I’m still ashamed of

    The freeCodeCamp Podcast starstarstarstarstar
    add
    Canadian software engineer Bill Sourour recounts a tragic experience early in his developer career when writing code for a pharmaceutical company. He explores developer ethics, the responsibilities developers have, and the challenges they face in sticking to their values. Written by and read by Bill Sourour: https://twitter.com/billsourour
    Original Article: https://medium.freecodecamp.org/the-code-im-still-ashamed-of-e4c021dff55e The Future of Programming by Bob Martin: https://youtu.be/ecIWPzGEbFc Business Insider Story: "Programmers are having a huge discussion about the unethical and illegal things they’ve been asked to do” http://www.businessinsider.com/programmers-confess-unethical-illegal-tasks-asked-of-them-2016-11?op=1 CBC Interview http://www.cbc.ca/radio/the180/stop-subsidizing-seniors-good-judges-can-make-bad-decisions-and-which-canadian-city-is-the-most-american-1.4028473/creating-a-code-of-ethics-for-coders-1.4028677 Code Newbie Interview https://www.codenewbie.org/podcast/the-ethics-of-coding Developer Ethics on FCC Guide https://guide.freecodecamp.org/developer-ethics Learn to code for free at: https://www.freecodecamp.org Music: "Sounds of Wonder" by Vangough: https://fcc.im/2yQOq0q Transcript:


    If you write code for a living, there’s a chance that at some point in your career, someone will ask you to code something a little deceitful – if not outright unethical.

    This happened to me back in the year 2000. And it’s something I’ll never be able to forget.

    I wrote my first line of code at 6 years old. I’m no prodigy though. I had a lot of help from my dad at the time. But I was hooked. I loved it.

    By the time I was 15, I was working part-time for my dad’s consulting firm. I built websites and coded small components for business apps on weekends and in the summer.

    I was woefully underpaid. But as my dad still likes to point out, I got free room and board, and some pretty valuable work experience.

    Later, I managed to help fund a part of my education through a few freelance coding gigs. I built a couple of early e-commerce sites for some local small businesses.

    By age 21, I managed to land a full-time coding job with an interactive marketing firm in Toronto, Canada.

    The firm had been founded by a medical doctor and many of its clients were large pharmaceutical companies.

    In Canada, there are strict limits on how pharmaceutical companies can advertise prescription drugs directly to consumers.

    As a result, these companies would create websites that present general information about whatever symptoms their drugs were meant to address. Then, if a visitor could prove they had a prescription, they were given access to a patient portal with more specific info about the drug.

    The home page of edfactscanada.com circa 2001, via The Internet Archive

    One of the projects I was assigned to involved a drug that was targeted at women. The graphics and general style of the website made it clear that the client wanted to specifically target teenage girls.

    One of the features of this website was a quiz that asked girls a series of questions and recommended a type of drug based on their answers.

    Remember, this website was posing as a general information site. It was not clearly an advertisement for any particular drug.

    When I received the requirements, they contained the questions for the quiz, along with multiple choice answers for each question.

    Missing from the requirements was any indication of what I should do with the answers at the end of the quiz. So what rules determined what treatment the quiz would recommend?

    I spoke to the Account Manager about this. She emailed the client and got me the requirements. With those, I proceeded to code up the quiz.

    Before submitting the website to the client, my project manager decided to give it a quick test. She tried the quiz, then came over to my desk:

    “The quiz doesn’t work,” she said.

    “Oh. What’s broken?” I asked.

    “Well, it seems that no matter what I do, the quiz recommends the client’s drug as the best possible treatment. The only exception is if I say I’m allergic. Or if I say I am already taking it.”

    “Yes. That’s what the requirements say to do. Everything leads to the client’s drug.”

    “Oh. Okay. Cool.”

    And she was off.

    I wish I could tell you that when I first saw those requirements they bothered me. I wish I could tell you that it felt wrong to code something that was basically designed to trick young girls. But the truth is, I didn’t think much of it at the time. I had a job to do, and I did it.

    Nothing that we were doing was illegal. As the youngest developer on my team, I was making good money for my age. And in the end, I understood that the real purpose of the site was to push a particular drug. So, I chalked this tactic up to “marketing.”

    The client was extremely pleased with the site. So much so that their rep invited me and the entire team out to a fancy steak dinner.

    The day of the dinner, shortly before leaving the office, a colleague emailed me a link to a news report online. It was about a young girl who had taken the drug I’d built the website for.

    She had killed herself.

    It turned out that among the main side effects of that drug were severe depression and suicidal thoughts.

    The colleague who had emailed me didn’t show up to dinner.

    I still went. It was difficult and awkward. I never mentioned the news report. I just ate my steak quietly and tried to force a smile when I could.

    The next day, I called my sister. She was 19 at the time. We had discovered while working on the project that she had actually been prescribed the very drug I was building a site for.

    When we first talked about it, we thought the whole thing was a neat coincidence. Now, the tone of our conversation was very different. I advised her to get off the drug ASAP. Thankfully, she listened.

    There are a million and one ways for me to rationalize my part in later suicides and severe depression. Even today, there is ongoing litigation with former patients.

    It’s easy to make an argument that I had no part in it at all. Still, I’ve never felt okay about writing that code.

    Not long after that dinner, I resigned.

    As developers, we are often one of the last lines of defense against potentially dangerous and unethical practices.

    We’re approaching a time where software will drive the vehicle that transports your family to soccer practice. There are already AI programs that help doctors diagnose disease. It’s not hard to imagine them recommending prescription drugs soon, too.

    The more software continues to take over every aspect of our lives, the more important it will be for us to take a stand and ensure that our ethics are ever-present in our code.

    Since that day, I always try to think twice about the effects of my code before I write it. I hope that you will too.