The freeCodeCamp Podcast

For several days not that long ago, Jordan Reid's site, ramshackleglam.com, did not belong to her. She got it back, but only after the involvement of fifty or so employees of six different companies, middle-of-the-night conferences with lawyers, FBI intervention, and what amounted to a massive sting operation. Here's her story. 

Written by Jordan Reid: https://twitter.com/ramshackleglam

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

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

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

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

Transcript: 

For several days not so long ago, RamshackleGlam.com — the domain name that I have owned and operated since March of 2010 — did not belong to me, but rather to a man who goes by the name “bahbouh” on an auction website called Flippa, and who was attempting to sell off the site to the highest bidder (with a “Buy It Now” price of $30,000.00). He promised the winner my traffic, my files, and my data, and suggested that I was available “for hire” to continue writing posts (alternatively, he was willing to provide the winner with “high-quality articles” and “SEO advice” to maintain the site’s traffic post-sale).

I learned that my site was stolen on a Saturday. Three days later I had it back, but only after the involvement of fifty or so employees of six different companies, middle-of-the-night conferences with lawyers, FBI intervention, and what amounted to a sting operation that probably should have starred Sandra Bullock instead of…well…me.

Of course I’ve heard of identity theft, and of cyber hacking, but honestly, my attitude towards these things was very much “it could never happen to me.” And even if it did…I didn’t exactly understand why it was such a huge deal. Couldn’t you just explain to people what had happened, prove who you were, and sort it all out? We live in such a highly documented world, it seemed completely impossible to me that someone could actually get away with pretending to be someone else with any real consequences beyond a few phone calls and some irritation.

It’s much, much worse — more threatening, more upsetting, and more difficult (if not impossible) to fix — than I’d ever imagined.

I found out about the hacking from my father. His friend Anthony (who runs a web development and consulting company called ThoughtBox) had been surfing around on Flippa and had — in an impossibly lucky coincidence — noticed that my site was up for auction, with what appeared to be a highly suspicious listing. Suddenly, I remembered the email I had gotten the day before — an email that I had disregarded as spam — from someone “interested in the purchase” of my “weblog.” I remembered the notification from YouTube that someone had accessed my account from a different location — a notification I had ignored, assuming that I had logged in on a mobile device or that my husband had accidentally logged into my account instead of his own.

But even after I saw the listing, I didn’t panic: this seemed like something that could be fixed with a couple of emails. Except the auction site was located in Australia and didn’t appear to have a phone number, and when I sent an email with a scanned ID and proof of ownership what I got back was a form letter. And when I called HostMonster, the site I pay to operate my website, I discovered that I was no longer the owner of my site: someone had used their email confirmation system to authorize the transfer of my domain name into a private account at GoDaddy (another web registrar service of whom I’m also a client).

Why is this a big deal?

If you have a business that depends on a URL, you understand why this was such upsetting news: With control over my website’s domain name, a hacker would be able to take the site down, or redirect it elsewhere. Further, it was later verified that the hacker had control over all of the site’s content, as well; he could have just rerouted everything I’ve ever written to any location he wanted.

Ramshackle Glam may be “just” a lifestyle blog about things like parenting and fashion and decor…but it’s also a site that I’ve spent five years of my life building, and the idea of it falling into the hands of someone with malicious intent was heartbreaking. I could switch to a new URL and export a copy of my content (which I do back up), but that would result in the loss of a substantial amount of traffic. The website is my primary source of income, and with a house, two children, a book coming out, and a husband in business school, this was not a joke. The loss of my URL had the potential to be devastating for my business and for my family in a very real way.

So what did I do?

The events of the next few days were complicated, so rather than go through them chronologically I’m going to explain how each path I took ended up panning out (I’m going into detail so that I can be as much help as possible to anyone who goes through this themselves).

1. I tried to resolve the situation directly with GoDaddy and HostMonster. This did not work.

From Sunday through Tuesday, I spent most of the day (and much of the night) on the phone with GoDaddy, HostMonster, or both at the same time, and nearly every person I spoke with gave me the same response: “Sorry, can’t help you.”

HostMonster maintained that because they no longer controlled the domain name, there was nothing they could do. GoDaddy maintained that because the account was private and the person had obtained ownership of the domain through a transfer from HostMonster, there was nothing they could do.

What finally made a difference: I cited ICANN’s policy on Domain Name Dispute Resolution.* This got my case upgraded, but it did not result in action.

Here’s why: the legal department at HostMonster informed me that in order for them to initiate a transfer dispute that would result in GoDaddy releasing the domain back to me, their “internal investigation” would have to turn up evidence that they had done something wrong in releasing the site. In other words, they would have to admit that they had screwed up…which would in turn open them up to a lawsuit.

Needless to say, I never heard from the legal department again. Despite the fact that everyone seemed clear on the fact that I owned my website and that it had been transferred without my authorization, nothing was going to be done unless I initiated a time-consuming and costly lawsuit that, in any case, would not result in action quick enough to save my domain name from being sold.

So that avenue came to an end.

2. I called the FBI. This was a major step in the right direction.

The morning after I found out about the unauthorized transfer, I also called the FBI. I felt silly and dramatic making the phone call, but the reality is that this is an international cyber crime issue, and that’s FBI territory. And this is my business. It’s how I support my family, and it may be a “small matter” in the grand scheme of things, but it is not a small matter to me.

And let me tell you: of all the surprises I’ve had over the past week or so, most surprising of all has been the FBI. They responded immediately, with follow-up phone calls and emails, an in-person interview with two special agents at my own home within 24 hours, and a follow-up visit from two agents yesterday. Beyond that, each and every agent I have interacted with over the past week has been, without fail, compassionate, thoughtful, invested, respectful, and committed to action…in addition to treating me not like a case number, but like a human.

What I expected was to leave a message with a general mailbox and at some point receive a form letter; I certainly did not expect to see an active investigation opened immediately. I’m not going to write more about the investigation because it’s still ongoing (although I did ask for and receive permission to write about this), but I think it’s important to say how absolutely blown away I have been by the FBI’s response.

3. I tried to regain control by dealing directly with the “seller”. This worked, but not without considerable drama.

While all of the above was going on, I was also working to regain control over the site directly from the individual who was trying to sell it.

I didn’t want to contact the “seller” directly, because I felt that if he thought the “real” owner of the site was aware of the sale, he would try to extort more money. So I asked Anthony — the person who had found the original listing, and who had an active account with a positive history on Flippa — to DM “bahbouh” to see if he was interested in a “private sale”. After some back-and-forth we reached an agreement, and it was decided that a third-party money-transfer website (Escrow.com) would be used to make the sale: the money would only be released to the seller upon confirmation that the domain name had been transferred.

This appeared to be going smoothly until Tuesday night, when the seller suddenly demanded that the funds be released immediately (prior to receipt of the website). When we pushed back, he announced that he was selling it to someone else: “Sorry, bye.”

So here was my thought process: if we did not release the money to the seller, we were guaranteed to not get the website. If we did release the money to him, there was a possibility that he would take the money and run, and also a possibility that he would deliver the site as promised. It wasn’t a gamble I wanted to take…but I didn’t see any option. And so I authorized the wire transfer.

I spent twenty minutes sitting in front of the dummy GoDaddy account I had created to receive the domain name from the seller, waiting to see whether I was out thousands of dollars and a domain name, or just thousands of dollars.

And then it came through.

I immediately transferred the domain into a different account and placed it (and all of my other domain names) on what amounted to lockdown. And then I called the wire transfer company and placed a stop on the payment.

The end result

RamshackleGlam.com is back in my possession, thanks to a number of people who dedicated hours (in some cases days) out of their lives to doing whatever they could to help me. My other accounts — bank accounts, et cetera — have been secured. I don’t have my money back yet, but the man who stole my site from me doesn’t have it, either, and won’t be getting it, ever.

And that’s an ending I’m pretty damn thrilled with.

So why am I still angry?

Of course I’m angry with the person or people who stole the site, but that’s out of my hands. The reason I’m writing this post is to let people know that this really can happen — to anyone — and to offer suggestions for how to minimize the chances that it will happen to you (below), but beyond that, I’m writing this post because this incident made me very, very angry at GoDaddy and HostMonster. And I want you to know why.

No one at either company questioned my statement (supported by written proof) that the website belonged to me. No one doubted that it had been transferred without my authority. And yet I had to spend days — days during which the hacker could have done virtually anything he wanted — trying to reach one single person who was able to do anything, because the support staff and supervisors I spoke with (who had to have numbered fifty or more) were completely uninformed as to how to handle this situation beyond saying, “Jeez, that sucks. Can’t help you.”

And once I reached people who could help me — who could literally make a single phone call or push a single button and return my property to me (or simply freeze it so that it could not be sold or destroyed) — they would not. They hid behind their legal departments and refused to do anything, knowing full well that their inaction would force me to either interact with and pay off a criminal, or lose an essential component of my business.

And hackers know that these companies will do this.

They rely on it.

There is a serious problem when a criminal enterprise not only exists “despite” a company’s policies, but actually thrives as a direct result of that company’s prioritization of their own interests over the security of the clients they allegedly “protect”. Do I understand why companies like HostMonster and GoDaddy are focused on protecting themselves against lawsuits? Of course I do. But the fact is that they not only do not “help” their customers, but actively contribute to creating situations that threaten small businesses and the families that they support.

And these companies know that when they stonewall clients whose property has obviously been stolen that these clients will have no other recourse than to pay off criminals or watch their businesses — sometimes their very lives — collapse. They know that by standing in the way of immediate action they create the very environment that these criminals depend upon to perpetuate their business model. And they do nothing.

This has to change.

My opinion, for what it’s worth

Support personnel at hosting companies should be made intimately familiar with ICANN regulations involving domain disputes, and should be able to initiate a plan of action the first time a client makes them aware of a situation, not after hours and hours of repeated calls.

Further, the establishment of a TEAC** should result in an immediate freeze on the account in dispute until the situation has been resolved. This should not require an admission of culpability on the part of any parties; simply an acknowledgement that a dispute exists and an awareness that while the dispute exists the domain must be held safe from sale or transfer.

What you can do to reduce the chances that this will happen to you:

Have a really, really good password, and change it often. Your password should not contain “real” words (and definitely not more than one real word in immediate proximity, like “whitecat” or “angrybird”), and should contain capital letters, numbers and symbols. The best passwords of all look like total nonsense.

If possible, use a separate computer (an old one or a cheap one purchased for this purpose) for things like banking; if your family computer is the same one that you use for bank transactions you risk having your kids click on a bad link that results in a hacking.

Turn off your computer and personal devices when they’re not in use. Have antivirus software on your computer (but remember that virus scans only catch 30–40% of viruses, so unfortunately a “clean” check doesn’t necessarily mean that you’re safe).

Purchase CyberRisk Insurance (learn more about it here; it basically protects businesses from cyber attacks and data breaches.

But if it does happen to you, here’s what to do:

Begin taking careful notes (and screenshots) immediately. Don’t delete any emails or other information; it could all be important later on.

Immediately change all of your passwords (including — but not limited to — domain registrar, website hosting, website login information, email, bank accounts, wireless home electronics, and Apple ID) according to the rules stated below. I changed mine every few hours while this situation was still up in the air, and am continuing to change them every few days for the time being.

Contact the registrar(s), citing the ICANN policy below, and see if together you can arrive at a speedy resolution. Don’t be surprised if you find yourself running into dead ends.

Make sure to inquire about “filters” and “rules” that may have been placed on your email (basically, any kind of device that the hackers may have placed to forward emails, et cetera).

Contact appropriate law enforcement (I contacted the FBI because it appeared to be an international issue, and was at the very least an interstate issue because Escrow.com is located in California, and I’m in New York).

Note: Every situation is different, and I can’t wholeheartedly recommend the steps that I took that ultimately resulted in me regaining control over my domain name largely because they involved interacting with criminals. Obviously that isn’t ideal, and can have unpredictable consequences. (Although my husband says that he would like it to be known that he thinks I’m a huge badass. While this is ordinarily very far from the truth, in this specific instance…I’ll take it.)

The End. (That was long. Thanks for reading.)

*ICann.Org is the Internet Corporation for Assigned Names and Numbers (ICANN) is responsible for managing and coordinating the Domain Name System (DNS). ICANN’s policy on Domain Name Dispute Resolution essentially states that in the case of a domain dispute, the Losing Registrar (the registrar that maintained possession of the domain name pre-transfer, as opposed to the “Winning Registrar”, who maintains possession of the domain name post-transfer). must immediately establish a Transfer Emergency Action Contact (“TEAC“) in an effort to get the ball rolling in the direction of resolution right away). Once I had this information, my case was immediately upgraded.

**TEAC: A contact that is established by ICANN and used by other registrars and ICANN if there is a need to quickly address issues with domain transfers between two registrars. The contact must respond to inquiries within four hours, though final resolution may take longer.

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 [email protected].

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 [email protected].

 

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.

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.

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: [email protected]

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!

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.

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.

 

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

 

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.

 

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.