Episodes

  • 00:34:35

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

    · The freeCodeCamp Podcast

    For Haseeb's first software developer job, he was able to negotiate a total compensation package of US $250,000 for his first year at Airbnb. He believes negotiation is a skill that can be learned, just like any other. And it isn't particularly elusive or hard to understand. In this episode, he explains how anyone can negotiate effectively. Written and Read by Haseeb Qureshi: https://twitter.com/hosseeb Haseeb's original article: https://fcc.im/2mBOOea Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript:  So you’ve maneuvered through the initial offer conversation. You’ve lined up counteroffers from other companies. Now it’s time to enter the actual negotiation. Naturally, this is the part where everything goes horribly wrong. But don’t worry. I’m going to turn you into a superhero negotiator. (Or at least an eccentric billionaire negotiator, which is sometimes better?) Seriously though. In this article, we’re going to deep-dive into the negotiating process, and discuss my final 4 rules on how to negotiate a job offer. If you didn’t read my first 6 rules, you can read them here (or you can just skip ’em and keep reading): Ten Rules for Negotiating a Job Offer When the story of how I landed a job at Airbnb went viral, I was surprised at how infatuated people were with my… What does it take to be a good negotiator? Most people think negotiating well is just looking the other person in the eye, appearing confident, and asking for tons of money. But being a good negotiator is a lot more subtle than that. What Good Negotiators Sound Like You probably have a friend or family member who’s infamous for refusing to take no for an answer. The kind of person who will march into a department store and bullheadedly argue with the management until they get a purchase refunded. This person seems like they often get what they want. They make you cringe, but perhaps you should try to be more like them. Rest assured, this person is actually a terrible negotiator. They’re good at being difficult and causing a scene, which can sometimes convince a waitress or shift manager to appease them. But this style of negotiating will get you nowhere when negotiating with a business partner (that is, an employer). A good negotiator is empathetic and collaborative. They don’t try to control you or issue ultimatums. Rather, they try to think creatively about how to fulfill both your and their needs. So when you think of negotiating a job offer, don’t imagine haggling over a used car. Think more like negotiating dinner plans with a group of friends, and you’ll fare much better. Slicing up the cake Another important difference between good and bad negotiators is that bad negotiators tend to think of a negotiation as a zero-sum game. Imagine we’re negotiating over a cake. In a zero-sum negotiation if I get one more slice, you get one less. Any gain I make comes at your expense. This seems obviously true with cake, right? So what makes a job negotiation any different? Ah, but it’s not actually true for cake. What if I hate corner pieces and you love them? What if I really like the cherries? What if I’m full and you’re starving, but you’ll agree to treat me to my favorite cake next time? Of course, when I posed the question I didn’t mention anything about cherries or my feelings on corner pieces. It might seem like I just made stuff up. But this is exactly what good negotiators do. They bend the rules. They question assumptions and ask unexpected questions. They dig to find the core what everyone values and look for creative ways to widen the terrain of negotiation. While you were thinking about how to haggle over slices, I’m thinking about how to give both of us more than just half of a cake. Different parties in a negotiation almost always have different value functions. We may value the same things — we both care about cake, after all. But we don’t value them in exactly the same way, so there’s probably a way to give each of us more of what we want. Most people go into a job negotiation thinking they need to stubbornly haggle over salary like slices of cake. They don’t ever stop to ask — hey, what do I actually value? Why do I value it? What does the company value? Why do they value that? There are many dimensions to a job negotiation: - salary - signing bonuses - stock - year-end or performance bonuses - commuter benefits - relocation expenses - equipment - an educational stipend - a childcare stipend - extra vacation time - a later start date - getting a dedicated hour a day to work out or study or meditate or play solitaire. You could choose which team you’re assigned to, what your first project will be, what technologies you’ll be working with, and sometimes even choose your title. Maybe you’re a frosting person, and the company is more into cherries. You never know if you don’t ask. Hold onto this mindset. Okay. Let’s pick up the negotiation where we left off. All the offers are in, and recruiters are eagerly waiting for you to get the ball rolling. Let’s start negotiating. Phone VS Email Your first decision is whether you want to negotiate over the phone, or keep correspondence over e-mail. Talking on the phone not only signals confidence, but more importantly, it allows you to build a strong relationship with your recruiter. Talking on the phone enables bantering, telling jokes, and building connection. You want your recruiter to like you, understand you, empathize with you. You want them to want you to succeed. Likewise, you want to care about your recruiter and understand what’s motivating them. The best deals get made between friends. It’s hard to make friends over e-mail. However, if you don’t have confidence in your negotiation skills, you should try to push the negotiation to e-mail. Written, asynchronous communication will give you more time to strategize and make it easier to say uncomfortable things without being pressured by a recruiter. That said, recruiters will always prefer to get you on the phone. It’s essentially their home turf. They’re also well aware that negotiating is easier over e-mail, and they have little interest in making it easier on you. They’ll often be vague about the offer over e-mail and only offer to discuss specific details on the phone. If you want to stick to email, you have to push back against this. There’s no secret to it: just be honest and ask for what you want. Tell them: “Hi recruiter, I hope your day is treating you well! Re: your previous e-mail, I’d prefer to discuss the details of the offer over e-mail. I sometimes get nervous during important phone calls, so discussing the offer over e-mail helps me to keep a clear head and communicate more clearly. I hope this is okay with you. :)” No BS, no huff-puffery. Just telling the truth and asking for what you want. There’s tremendous power in honesty and directness. Take advantage of it. (Also, note how I wrote “discuss the details of the offer” rather than “negotiate.” Never describe what you’re doing as negotiating — that sounds immediately adversarial and haggley. Describe it instead as a discussion, and they’re less likely to recoil.) Having Alternatives I mentioned before how essential it is to have multiple offers. I’ll reiterate again — it’s very, very valuable to have multiple offers. With other offers on the table, if your negotiation doesn’t work out, they know you’ll just accept another offer. Your negotiating position suddenly becomes a lot more credible because they know you’re willing to walk away. This effect is strengthened if you get an offer from a prestigious company. And the effect goes through the roof if you have an offer from a company’s primary competitor (now they’ll really want to poach you from the big bad competitor-corp). Some of this behavior is stupid tribalism. And some part of it is rational in trying to deprive competitors of talent. Either way, take advantage of it, and be tactical in which companies you aim for. But what if you don’t manage to get any other offers? Does all the negotiating just go out the window? Not at all. What’s important here is not actually having other offers. More specifically, it’s in having strong alternatives. Which is why Rule #6 of negotiating is: have alternatives. A negotiation needs stakes. If there were no risk and you knew for sure the other side would sign a contract, what incentive would you have to offer them anything more? Your alternatives are what give a negotiation its stakes. By signaling your alternatives, you allow your interlocutor to develop a mental model of when and why you’ll walk away from the negotiation. Your alternatives also have an anchoring effect on how much the other side thinks you’re objectively worth. In negotiation literature, your best alternative is often referred to as your BATNA (Best Alternative To a Negotiated Agreement). Basically, it’s what you’d do if you walked away. I like the term BATNA a lot, mostly because it sounds like a gadget Batman would lob at bad guys. So what’s your BATNA if you don’t have other offers? Do you even have one? Of course you do. Your best alternative might be “interview at more companies” or “go to grad school” or “stay at your current job” or “go on sabbatical in Morocco for a few months” (as it was for a friend of mine who was deliberating between joining a startup and gallivanting through North Africa). The point is, you don’t need to have another offer to have a strong BATNA. Your BATNA’s strength comes from: - how strong the other side perceives it to be, and - how strong you perceive it to be. If your recruiter thinks that going to grad school is an awesome thing to do, then they’ll see you as having a very strong alternative, and the stakes of the negotiation will be raised. But even if they think grad school is ridiculous — if you convince them that you’d be totally happy to go to grad school — then the burden is on them to make this deal more attractive to you than going to grad school. Thus, you need to communicate your BATNA. This doesn’t need to be ham-fisted, but you need to make it a background to the negotiation. (Note: usually whenever you signal your BATNA, you should also re-emphasize your interest in reaching an agreement). Examples: “I’ve received another offer from [OTHER CORP] that’s very compelling on salary, but I really love the mission of [YOUR COMPANY] and think that it would overall be a better fit for me.” “I’m also considering going back to grad school and getting a Master’s degree in Postmodern Haberdashery. I’m excited about [YOUR COMPANY] though and would love to join the team, but the package has to make sense if I’m going to forego a life of ironic hatmaking.” Note: one of the biggest mistakes I see here is from people who are currently working. If you already have a job, staying where you are is often your BATNA. This means if you tell your interlocutor that you hate your job, then they know your BATNA sucks, and have no incentive to negotiate with you (on top of potentially thinking that you’re a negative person). Always emphasize the pros of your current company, your seniority, your impact, and whatever else you like about where you currently work. You should make your decision seem like a genuinely difficult one — then it will appear to be a strong BATNA. What a Job Negotiation Means to an Employer I’ve kept saying that in order to be an effective negotiator, you need to understand the other side. So let’s take a look at what it’s like to negotiate as an employer. (I’m going to have to use the tech industry in my examples here, but the details will differ by industry.) First, we have to rewind and understand what brought us to this offer in the first place. What kind of resources have they spent so far in trying to fill this position? - Writing and posting a job description on all appropriate channels ($300) - Reviewing ~100 or more resumes ($1,250) - About 15% of those resumes need to be phone screened, so roughly 15 phone screens ($2,250) - Around 75% of those initial phone screens warrant a technical screen, so roughly 11 technical screens ($9,000) - About 30% pass through to an on-site, so roughly 3 onsites. These onsites require the coordination of 6–7 employees ($10,800) - Finally, they make one offer. The recruiter (and potentially the executive staff) need to spend time on the phone with the offeree convincing and negotiating. ($900) Numbers nabbed from here. All-in-all this process took about 45 days from start to finish. Now say you end up turning down their offer. They’ve spent over $24,000 just extending this single offer to you (to say nothing of opportunity costs), and now they’ll essentially have to start over from scratch. This is what a company faces if you turn them down. Realize what a gauntlet they’ve been through! Realize how important it is that you’re the one! Out of the droves and droves who’ve shown up on their doorstep, you’re the one they want. They want to usher you into their tribe. They went through so much crap to get you here, and now they’ve found you. And you’re worried that if you negotiate, they’ll take it away? Further yet, understand that salary is only one part of the cost of employing you. An employer also has to pay for your benefits, your equipment, space, utilities, other random expenses, and employment taxes on top of all of that. All-in, your actual salary often comprises less than 50% of the total cost of employing you. Which means they expect that your value to the company — in terms of the revenue you’ll generate — to be more than 2x your salary. If they didn’t believe that, they wouldn’t be hiring you at all. So, this is all to say: everything is stacked in your favor. It doesn’t feel that way, but it absolutely is. Realize that, while you are agonizing over whether to ask for another few thousand dollars, they’re just praying with bated breath that you’ll sign the offer. If you don’t sign the offer, they lose. Losing a good candidate sucks. No one wants to believe that their company isn’t worth working for. They want to win. They will pay to win. And yet, you might worry: “but if end up negotiating more, won’t they have higher expectations? Won’t my boss end up hating me for negotiating?” No, and no. It’s your role that will determine your performance expectations, not how much you negotiated. Making 5k more or less in salary doesn’t matter at all. Your manager will literally just not care about this. Remember how expensive it is to even employ you in the first place! Nobody’s going to fire you because you’re performing 5K worse than they expected you to. The cost of firing you and hiring someone else is a lot more than 5K to begin with. And no, your boss won’t hate you now. And in fact, at most big companies the person you’re negotiating with won’t even be your boss. Recruiting and management are totally separate departments, completely abstracted from one another. And even if you’re at a startup, trust me that your boss is used to negotiating with candidates and doesn’t place nearly as much significance on it as you do. In short: negotiating is easier and more normal than you think. Companies are completely willing to negotiate with you. If your intuition tells you otherwise, trust that your mental model is wrong. How to Give the First Number In part 1, I mentioned how valuable it is not to have to give the first number. But there are times when you just can’t avoid it. In these situations, there are ways to give the first number without actually giving the first number. If a company asks you “what are your salary expectations?” you might say: “I don’t have any particular numbers in mind. I’m more interested in learning whether this will be a good mutual fit. If it is, I’m open to exploring any offer so long as it’s competitive.” Sounds good. But they push back, “I understand that, but we need to have a clear idea of what you think is competitive. I need to know whether it’s worth going through the interview process. We’re a young startup, so I need to make sure we’re on the same page as far as compensation.” That’s a strong push. But you can still push back. “I completely hear you, and I agree it’s important that we’re on the same page. I really have no particular numbers in my head. It all depends on the fit and the composition of the offer. Once we decide we want to work together, I think that’s the best time to figure out a compensation package that makes sense.” Most employers will relent here. But there’s a small chance they push further: “Okay, look, you’re being difficult. Let’s not waste each other’s time. What’s an offer that you’d be willing to take?” This is a decision point. They’re trying to take away your negotiating power and pin you to a premature decision. That said, you probably will have to say a number at this point, or risk damaging the trust in this relationship. (They are making a valid point that startups can’t offer the same kind of cash as large companies, nor should you expect them to. They might be sensing that you’re not aware of this.) But you can give a number here without actually giving a number. “Well, okay. I know that the average software engineer in Silicon Valley makes roughly 120K a year in salary. So I think that’s a good place to start.” Notice what I did here. I didn’t actually answer the question “what’s an offer you’d be willing to take,” I merely anchored the conversation around the fulcrum of “the average software engineer salary.” So if you’re forced to give a number, do so by appealing to an objective metric, such as an industry average (or your current salary). And make it clear that you’re merely starting the negotiation there, not ending it. How to Ask for More An offer is out there, and now you want to improve it. As always, be direct and ask for what you want. Here are generally the steps you should take. First, reiterate your interest in the company. This is as simple as “I’m really excited about the problems you guys are working on at Evil Corp…” Now frame why you’re asking for more. There are two choices here: you can say that you’re on the fence and that an improvement might convince you, or you can go stronger and say that you’re outright dissatisfied with the offer. Which approach you choose depends on how much leverage you have, how weak the offer is relative to your BATNA, and whether you have other offers (the weaker your negotiating position, generally the more tentative you should be). Either way, be unfailingly polite. If you’re dissatisfied with the offer, you might say something like “I appreciate the work you guys put into constructing this offer. But there were a couple things I was unsatisfied with.” If you want to be more reserved, you can say something like: “The offer you guys extended was strong. Right now my decision is basically between you and [XYZ CORP]. It’s a genuinely difficult decision for me, but there are a couple of dimensions where if this offer improved, it would be much more compelling.” Don’t just say something like “Thanks for the offer. Here are some ways I think it could improve.” This makes you sound like an ass. Be polite, and if you want to strengthen the offer, tell them clearly how you feel about it. This builds trust and conveys seriousness. Let’s say you want to raise the salary. Now that you have a specific ask, it’s time to employ rule #7: proclaim reasons for everything. We all implicitly know the catch-22 of negotiation: if you say you want more salary, you’ll sound greedy. And no one likes greedy people, right? So why would they want to give more money to a greedy person? I suspect this is the primary reason why so many candidates recoil from negotiating. They don’t want to feel greedy. It goes against all of their social conditioning. And yet, there are some situations in which most people would be totally fine negotiating. Specifically, when they have to. If you had to raise your salary or you wouldn’t be able to afford rent, or if you had to negotiate health insurance to cover a medical condition, you’d negotiate without a twinge of regret. The difference? That you have a reason for what you’re requesting. It’s kind of a brain-hack, both for yourself and for your negotiating partner. Just stating a reason — any reason — makes your request feel human and important. It’s not you being greedy, it’s you trying to fulfill your goals. The more unobjectionable and sympathetic your reason, the better. If it’s medical expenses, or paying off student loans, or taking care of family, you’ll bring tears to their eyes. I told employers that I was earning-to-give, so since I was donating 33% of my income to charity, I had tonegotiate aggressively to leave myself enough to live off. But honestly, even if your reason is inane and unimpressive, it will still carry this effect. Just saying “can you improve the salary?” sounds like you’re boringly motivated by money. But if you say “I really want to buy a house within the next year; what can we do to improve the salary?” This suddenly seems a lot more legitimate. If they turn down your request now, they’re implicitly telling you “No, Jennifer, you can’t buy your house. I guess you don’t deserve one.” No one wants to do that. They want to be the one who says, “All right Jennifer, I talked with the director and I made it happen. You’re getting that new house!” (Of course, it goes without saying that you want money so you can spend it on things. I know. It’s stupid. But it works.) Just go with it, state a reason for everything, and you’ll find recruiters more willing to become your advocate. Assert your Value One effective move you can make in a negotiation, especially after an ask, is to emphasize the unique value you’ll be bringing to the company. Example: “Blah blah blah, I want X, Y, and Z. I know that you guys are looking for someone to build out your Android team. I believe I bring a lot of experience leading a team of Android developers and I’m confident that I’ll be able to bring your mobile offerings up to parity with your competitors. Let me know your thoughts.” Be confident without boasting or trying to hold yourself to specific metrics (unless you’re supremely confident). Whatever you assert should be something you’ve touched on earlier in your discussions. But it’s okay to repeat it now as a gentle reminder. It reminds them of the carrot, and shows that you’re still excited to add value. This is not appropriate in every negotiation, especially for very junior positions, where it’s harder to differentiate yourself. But later in your career (or for more specialized/consulting roles) this can be a really valuable nudge. What to Ask For This brings me to rule #8: be motivated by more than just money. Note, this is not code for “if you seem like you’re motivated by more than just money, you’ll get more money.” There is no bigger turn-off to a company than somebody who only cares about money. This is something you’re not going to be able to fake. Actually be motivated by other things. You should be motivated by money, too, of course, but it should be one among many dimensions you’re optimizing for. How much training you get, what your first project will be, which team you join, or even who your mentor will be — these are all things you can and should negotiate. Among these factors, salary is perhaps the least important. What do you really value? Be creative. Don’t try to haggle over slices of cake when there’s so much more on the table. Of course, to negotiate well you need to understand the other side’s preferences. You want to make the deal better for both of you. That’s why rule #9 is: understand what the company values. How do you figure this out? Well, there are a few good rules of thumb. First, salary is almost always the hardest thing to give, for a few reasons: - It must be paid year after year, so it becomes part of a company’s long-term burn rate. - It is almost always the thing that people gossip about, so paying someone significantly more salary can cause unrest. - It tends to be the most tightly constrained by pay bands, especially at large companies. So if you want more financial compensation, you should think about structuring as much of it as possible outside of salary. A signing bonus, for example, is easier to give than salary. A signing bonus has the advantage of only needing to be paid once. It gets the candidate excited about joining (because everyone likes wads of cash), and it’s generally not as public. Remember that you can always get salary raises as you continue to work at the company, but there’s only one point at which you can get a signing bonus. The easiest thing for a company to give though is stock (if the company offers stock). Companies like giving stock because it invests you in the company and aligns interests. It also shifts some of the risk from the company over to you and burns less cash. If you are genuinely risk-neutral or early in your career, then you should generally try to assume as much stock as possible. If you aggressively trade cash for stock, you can end up with a higher expected value offer (albeit with higher risk). A Brief Primer on Equity First, understand there are two completely different classes of companies: public companies and private companies. If the company is public (i.e., it has IPO’d and is listed on the stock market), then its stock is as good as cash. You will usually be granted RSUs (Restricted Stock Units), which are just shares like you can purchase on the stock market. Once these shares vest (that is, are released to you), you can turn around and sell them on the stock market. This is how they turn into money. If the company is private, then things get a lot more complicated. For private companies, most of the time they will not actually issue you stock grants. Usually, they will issue you stock options. An option is a pre-agreed right to purchase shares of stock at a frozen price. It’s important to note that when you want to leave a company, if you have options, your life becomes really complicated. You may have to pay a bunch of money to actually exercise your option (that is, buy your pre-agreed upon stock at the previous frozen price, or risk losing it), with no way to actually sell it yet. The only way to truly liquidate your options is when the company IPOs or is acquired. And many companies don’t ever do this. Thus, options are very risky. It’s easier to get screwed by options, especially on tax implications. For a lot more information, see this post by Scott Kupor of a16z. Equity Shenanigans Many companies will try to play mind games with you when it comes to equity. Several companies pulled these on me. A common one is presenting the total value of the stock grant rather than the annualized value, despite the stock not vesting evenly, or vesting over 5 years instead of the standard 4. But the most egregious thing that companies will do is tell you absurd stories about the value of their stock. They’ll say: “okay, we’re worth this much now, but at the rate we’re growing, we’re going to be worth 10X that in a year. So really, the value of your options is many millions of dollars!” To not mince words: this is cynically dishonest BS. Don’t buy it even for a second. I got this a few times, and the only reason I didn’t walk away from the offer immediately was because it was always a recruiter pulling this crap. If it was a manager I would’ve turned down the offer outright. Here’s why this is infuriatingly stupid: a company’s valuation is determined by investors. These investors see the financials and the growth rate of the company, and invest at a price that reflects the current growth rate of the company. In other words, they invested at a valuation that already took their 10x growth rate into account. Investors are not idiots. And unless you (or your recruiter) think you have privileged information or insight that the company’s investors don’t, you should probably take the investors’ word for it. Also, a company’s nominal valuation is almost always inflated due to preferred shares, debt, and survivorship bias. But let’s ignore that for now. So if a company gives you this hock of crap, fire back and tell them thank you, but you’ll be considering the stock at the same valuation their investors valued it at. I mean, be nice. But don’t let them try to strong-arm you into accepting this garbage. A job is not a suicide pact. Choose a company that is judicious and transparent, and you’ll be much more likely to find yourself respected and taken care of. Other things you can ask for Because I’d be remiss if I didn’t point out a few other things. Relocation expenses often come out of separate budgets at big companies, so this is generally very easy to get. Look for creative benefits that would be particularly valuable to you. Maybe it’s covering your commuter expenses, asking for dedicated volunteer or learning time, getting sponsored for conferences, or even charity donation matching. Don’t assume anything’s off the table until you’ve tried bringing it up. That said, don’t throw the entire kitchen sink at them. A negotiation can quickly become cumbersome for an employer if you bring up a litany of changes. Keep the changeset as pithy as you can. Negotiating Jiu Jitsu Recruiters love trying to trick you into ending the negotiation early. They’re going to do this relentlessly. Don’t fault them for it — I suspect they can’t help themselves. Just keep breaking out of their shenanigans. Don’t let yourself be pressured into ending a negotiation until you’re actually ready to make a final decision. This is especially grave if you have multiple offers, and you let one company pressure you into canceling the others. Companies succeed in doing this all the time, so I want to equip you with the skills to jiu jitsu out of these techniques. Here are two situations you can break out of. These are both real situations that happened to me during my negotiations, though the numbers and details are invented. Situation 1: I ask for a 10K increase in signing bonus. The company gets back to me and says, “That’s really tough for us to do. I’m going to try. I think you’re worth it. But I can’t really go to my boss and fight for you unless she knows you’re going to sign. Are you going to sign if I get you that 10K?” You should be thinking: ah, this person is trying to force me to a decision point and take away my negotiating power. I respond, “Okay, so what I’m hearing is that you’ll have to expend some personal reputation to get me a 10K bonus. If you end up going to bat for me, are you confident you’ll be able to get that 10K?” “I think I can, it just comes down to you Haseeb. If you’re serious about joining us, then I’ll go fight for you. But I need to know for sure you’ll sign.” Great. Time to jiu jitsu. “That makes sense. Unfortunately I can’t commit to signing yet; I’m not yet at the stage where I can make a final decision. Like I told you before, this weekend I’m going to sit down with my family and talk things over with them. Choosing the company I’m going to spend the next few years at is a commitment I take really seriously. So I want to be sure I’m making a well-considered decision. “But since you’re confident that you can get an extra 10K, let’s do this instead: in my mind, I’ll pretend this offer is [X + 10K] and as I’m considering my final decision, that’s where I’ll value it. I know it’s tough for you to go and get that from your boss, so I don’t want you to do that until I’m certain I’m going to sign.” They then vaguely recant and promptly get approval for the 10K bonus. Situation 2: I ask for a 20% increase in stock package. The hiring manager, knowing that I’m negotiating with other companies, then fires back: “I want to get this stock package for you. And I know I can, we’ve got the budget. But before I do that, I need your word on something.” “What’s that?” “I need you to give me your word that if I improve your offer, you’re not going to just turn around and take our counter-offer to [COMPETITOR_COMPANY] to improve your offer with them.” You should be thinking: so basically they’re asking me not to negotiate. “Let me see if I understand what you’re saying. You are willing to improve my offer, but only if I agree that I won’t tell [COMPETITOR] what you’re offering me. Is that correct?” “Well no, I can’t legally do that. What I mean is… what I mean is, look. I like you. But if I improve your offer and you just take our offer to [COMPETITOR], you’ll be violating my trust.” “Okay, let me be sure I understand you here. If you give me this offer and I tell [COMPETITOR], I will be violating the trust under which you’re granting me this improved offer. Is that correct?” “Uhh… Look. How about this. In my mind, I’m going to go get you this stock package okay? And in my head, I’m going to do it with the assumption that you’re the kind of person I think you are, and you’re going to consider our offer in its own right and not just shop it around. Fair enough?” I nod. He gets the improved offer. I continue to negotiate. Antics averted. (In case you’re wondering, if he had said “yes,” I would have turned down the proposal.) The Path to Signing It’s not enough to just continually ask for stuff. Companies need to sense that you’re actually moving toward a final decision, and not just playing games with them. Your goal in a negotiation is not to be difficult or elusive. True, you should assert your value and carefully consider your options, but you can do so in a way that’s respectful and considerate toward the companies you’re talking to. Don’t go dark on people. Be open and communicative. I keep saying be honest and I mean it — be honest. Aside: I keep talking about honesty, and you might protest that this is antithetical to my earlier rule of “protect information.” It’s not. True, you should protect information that might weaken your negotiating position, but you should be as communicative as possible about everything else (which is most things). Negotiating is all about relationship, and communication is the bedrock of any relationship. This brings me to the final rule, Rule #10: be winnable. This is more than just giving the company the impression that you like them (which you continually should). But more so that you must give any company you’re talking to a clear path on how to win you. Don’t BS them or play stupid games. Be clear and unequivocal with your preferences and timeline. If there is nothing that a company could do to sign you, or you don’t actually want to work for them, then don’t negotiate with them. Period. Don’t waste their time or play games for your own purposes. Even if the company isn’t your dream company, you must be able to imagine at least some package they could offer you that would make you sign. If not, politely turn them down. It costs each company money to interview you and to negotiate with you. I didn’t negotiate with every company I received an offer from, but if there was one key mistake I made in my job search, it was that I still negotiated with too many (in large part because I didn’t think my job search would be successful). Making the Final Decision Okay, it’s decision time. (Yes, you do have to make one.) Three things to keep in mind here: - be clear about your deadline - assert your deadline continually - use your final decision as your trump card When you start negotiating, you don’t have to be clear about your timeline because you probably don’t have one yet. But once you get into intermediary stages, you should set for yourself a deadline on which you’ll sign. It can be for an arbitrary reason (or no reason at all), but just pre-committing to a deadline will allow you to negotiate more clearly and powerfully. “A weekend with the family” I found works nicely, as it has the added benefit of roping other decision makers in. Then when companies push you to end negotiations early, you can re-assert this deadline. Companies should all be totally aware of when you’re going to make your decision. This will raise the stakes and galvanize negotiations as the deadline approaches. This deadline also lets you defer your decision while still improving offers. Your narrative should basically be “I want to see the strongest offer your company can muster. Then I will go into my cave, meditate for 10 days, and when I emerge I will have decided in my heart which company to join.” This gives you enormous power to avoid any on-the-spot decision points or premature promises. Eventually, deadline day will come. Try to make this a business day (say, a Friday or a Monday) so that you can communicate with recruiters during this day. If a hail mary is going to happen, it’ll happen here. Even if there’s only one company in the running, you should always always wait until the last day to sign your offer. Yes, even if you’re certain you’re going to sign and even if it’s your dream job. I’ve seen many scenarios in which offers spontaneously improved as deadlines approached, or a fallen player gets up and presents you the holy grail in the 11th hour. Either way, there’s no harm. Finally, your trump card. Save this for the very end. Your trump card is these words: “If you can do X, I will sign.” Note, this is NOT “If you give me X, the offer will be more compelling blah blah blah.” We’re past that. It’s time to make a promise. Every company that’s still on the table, let them know what it would take to sign you (unless there’s nothing they could do). And when you make the final ask, don’t forget reason-giving, even if it’s the same reason as before! “Hi Joel, I’ve been thinking it over and it’s genuinely a really tough decision for me. I loved everyone at [COMPANY] but the one thing that makes it hard for me is the salary. As you know I’m trying to pay off my student loans so salary is really important to me right now. If you can improve the salary by 10K a year, then I’ll be totally ready to sign.” With luck, they meet you half-way. Or, with a little more luck, they’ll meet all of it. And just because I know someone will ask — yes, once say you’re going to sign, you should always sign. Never go back on your word. It’s a small world. People talk. These kind of things will come back to haunt you. (More importantly, never go back on your word because you’re the kind of person who never goes back on their word.) Tell all of the other parties that you’ve made your final decision. Thank them for the negotiation. If you did it well, they’ll usually thank you back, tell you to keep in touch, and to reach out again in a couple years next time you’re on the market. And that’s it. You did it! Congratulations! You’re still alive, right? … You’re not moving. Well, that’s fine. It’s time to celebrate your new job, you beautiful fool! (Drinks are on you.) If you got some value out of this article, share it with a friend who’d benefit from it. Or better yet, follow me on Twitter and I can be your friend. There’s a lot more in the works. Until next time, —Haseeb  

    starstarstarstarstar
  • Missing episodes?

    Click here to refresh the feed.

  • 00:27:29

    Ep. 12 - Ten Rules for Negotiating a Job Offer

    · The freeCodeCamp Podcast

    For Haseeb's first software developer job, he was able to negotiate a total compensation package of US $250,000 for his first year at Airbnb. He believes negotiation is a skill that can be learned, just like any other. And it isn't particularly elusive or hard to understand. In this episode, he explains how anyone can negotiate effectively. Written and Read by Haseeb Qureshi: https://twitter.com/hosseeb Haseeb's original article: https://fcc.im/2FiLq0v Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript:  When the story of how I landed a job at Airbnb went viral, I was surprised at how infatuated people were with my negotiations. Media stories portrayed me as some kind of master negotiator — a wily ex-poker-player who was able to con the tech giants into a lucrative job offer. This is silly. It’s silly for a lot of reasons, but one of the main ones is that in reality, my negotiation skills are nothing special. There are lots of job candidates who are better negotiators than I, to speak nothing of recruiters and other professional negotiators. It just so happens that most people don’t negotiate at all, or if they do, they negotiate just enough to satisfy themselves that they did. Worse yet, most of the advice out there on negotiation is borderline useless. Almost anything you read on the subject will be a vague and long-winded exhortation to “make sure you negotiate” and “never say the first number.” Beyond those two morsels of advice, you’re pretty much on your own. I thought to myself: why is there so little actionable advice out there about negotiation? I suspect it’s because deep down, many people believe that negotiation is inexplicable, that it’s something some people can do and others can’t, and that there’s no real way to break it down so anyone can learn it. I say that’s BS. Negotiation is a skill that can be learned, just like any other. I don’t believe it’s particularly elusive or hard to understand. So I’m going to try to explain how anyone can do it. Three caveats. First: I’m not an expert. There are people who really are experts at this, and when my advice contradicts theirs, you should assume I’m wrong. Second: negotiation is tricky to generalize about because it’s deeply intertwined with social dynamics and power. The appropriate advice for an Asian male in Silicon Valley may not be appropriate for a black woman in Birmingham, Alabama. Racial, sexual, and political dynamics accompany you to the negotiating table. At the same time, I want to caution against overemphasizing these factors. Being afraid to negotiate out of fear of discrimination can often be just as deleterious as discrimination itself. Ceteris paribus, negotiate aggressively. Third: I’m the first to admit that negotiation is stupid. It’s a practice that inherently benefits those who are good at it, and is an absurd axis on which to reward people. But it’s a reality of our economic system. And like most collective action problems, we’re probably not going to be able to abolish it any time soon. In which case, you might as well improve at it. So here’s my guide to negotiation. It’s going to be split into two parts: this first part will be about conceptualizing the negotiating process, about how to begin the process and set yourself up for maximal success. The second part will be advice on the actual back-and-forth portion of negotiating and how to ask for what you want. Let’s take it from the top. What it means to “get a job” In our culture we call entering the employment market “trying to get a job.” This is an unfortunate turn of phrase. “Getting a job” implies that jobs are a resource out in the world, and you’re attempting to secure one of these resources. But that’s completely backwards. What you are actually doing is selling your labor, and a company is bidding for it. Employment is just striking a mutual deal in the labor market. Like any market, the labor market only functions well if it’s competitive. This is the only way to ensure fair and equitable pricing. Imagine you were a farmer selling watermelons. Would you just sell your watermelons to the first buyer who agreed to purchase them? Or would you survey the marketplace of buyers, see the best price (and business partner) you could get, and then make an informed decision on which buyer to sell to? And yet, when people talk about the labor market, they think “oh, a company wants to give me a job! What a relief!” As though having a job were in itself some special privilege for which a company is the gatekeeper. Dispel yourself of this mindset. A job is just a deal. It is a deal between you and a company to exchange labor for money (and other things you value). This might sound like an abstract point, but you should absolutely approach negotiation from this perspective. The role of negotiation Negotiating is a natural and expected part of the process of trying to make a deal. It’s also a signal of competence and seriousness. Companies generally respect candidates who negotiate, and most highly attractive candidates negotiate (if for no other reason, because they often have too many options to choose from). At the risk of spouting truisms: always, always negotiate. It doesn’t matter how good or bad you think you are. You never damage a relationship by negotiating. In all my time as an instructor at App Academy, out of hundreds of offers negotiated, only once or twice were offers ever rescinded in negotiations. It basically never happens. And when it does, usually the candidate was being an unconscionable asshole, or the company was imploding and needed an excuse to rescind the offer. You might think to yourself: “well, I don’t want to set high expectations, and the offer is already generous, so I ought to just take it.” No. Negotiate. Or maybe: “I don’t want to start off on the wrong foot and look greedy with my future employer.” No. Negotiate. “But this company is small and — “ No. Shut up. Negotiate. We’ll talk more in the next section about why a lot of these objections are BS, and fundamentally misapprehend the dynamics of hiring. But for now, just trust me that you should always negotiate. The ten rules of negotiating I’ve tried to boil down negotiation to ten rules. The rules, in order of appearance, are: - Get everything in writing - Always keep the door open - Information is power - Always be positive - Don’t be the decision maker - Have alternatives - Proclaim reasons for everything - Be motivated by more than just money - Understand what they value - Be winnable We’ll only get through some of these in this blog post, and the rest will appear in the second part. But I’ll explain each rule as we get to it. So let’s start from the top and try to walk through a negotiation process from the very beginning. For most, that starts when you receive an offer. The offer conversation You’ve just received the phone call: your interview went well, and after much deliberation they decided they like you. They want to make you an offer. Congratulations! Don’t get too excited though. The fun is just getting started. Thank your recruiter. Sound excited — hopefully this won’t be hard. Before jumping into details, try to ask for specific feedback on your interview performance. If they give it to you, this will help you gauge how much they want you, as well as tell you things you can improve on in your next interview(s). Now time to explore the offer. Rule #1 of negotiating: have everything in writing. Eventually, they’ll give you information about the offer. Write it all down. Doesn’t matter if they’re going to send you a written version later, write everything down. Even if there are things that are not directly monetary, if they relate to the job, write them down. If they tell you “we’re working on porting the front-end to Angular,” write that down. If they say they have 20 employees, write that down. You want as much information as you can. You’ll forget a lot of this stuff, and it’s going to be important in informing your final decision. Depending on the company, they’ll also tell you about the equity package. We’ll look more specifically at equity in part II, but be sure to write everything down. The rule from here on out is that everything significant you discuss will have some kind of a paper trail. Often, the company won’t even send you an official offer letter until a deal is finalized. So it falls to you to confirm all of the important details in subsequent e-mails. So yadda yadda, lots of details, writing stuff down, oh there’s a joke, time to laugh. Now the recruiter is done talking and you’re done asking all of your questions. Your recruiter will now say something along the lines of “so what do you think?” This seems innocuous, but your reply here is critical, because there’s a lot you can say to weaken your position. This is your first decision point. A decision point is a moment in the negotiation where your interlocutor wants to compel you to make a decision. If they succeed in tying you to a position, they will close the door on further negotiating. Of course “what do you think?” is a subtle prod. But it is the beginning of many attempts to get you to make a premature commitment. This leads to rule #2 of negotiating: always keep the door open. Never give up your negotiating power until you’re absolutely ready to make an informed, deliberate final decision. This means your job is to traverse as many of these decision points as possible without giving up the power to continue negotiating. Very frequently, your interlocutor will try to trick you into making a decision, or tie you to a decision you didn’t commit to. You must keep verbally jiu-jitsu-ing out of these antics until you’re actually ready to make your final decision. Protecting information There’s an uncomfortable silence by now, and their “what do you think?” is hanging in the air. If you say “yes, that sounds amazing, when do I start?” you implicitly accept the offer and completely close the door on the negotiation. This is your recruiter’s number one favorite thing to hear. It stands to reason you probably shouldn’t do this. But their second favorite thing to hear you say is “can you do 90K instead of 85K?” This also closes the door, but for a different and more subtle reason. And it’s the number one reason why most people suck at negotiation. Rule #3 of negotiating: information is power. To protect your power in the negotiation, you must protect information as much as possible. A company doesn’t give you insight into what it’s thinking. It doesn’t tell you its price range, how much it paid the previous candidate with your experience, or anything like that. It intentionally obfuscates those things. But it wants you not to do the same. A company wants to be like a bidder in a secret auction. But unlike the other bidders, it wants to know exactly how high all of the other bids are. It then openly intends to exploit that knowledge, often by bidding one cent more than the second highest bid. Yeah, no. Screw that. It’s a silent auction, and to keep it that way, you must protect information. In many situations, the only reason why you have any negotiating power at all is because the employer doesn’t actually know what you’re thinking. They might not know how good your other offers are, or how much you were making in your last job, or how you weigh salary vs equity, or even how rational you are as a decision-maker. Bottom line, you want them to be uncertain on exactly what it would take to sign you. When you say “can you do 90K instead of 85K,” you’ve told them exactly what it will take to make you sign. The sheet’s pulled back, the secret auction is up, and they’re going to bid 90K (or more likely, 87K). And they know there’s almost no risk in doing so, because you’ll probably accept. What if you were the kind of person who wouldn’t even consider an offer below 110K? Or the kind of person who wouldn’t consider an offer below 120K? If you were, you wouldn’t ask for 90K, and if they offered it as conciliation, you’d tell them to stop wasting your time. By staying silent, they don’t actually know which of those kinds of people you are. In their mind, you could be any of the three. A corollary of this rule is that you should not reveal to companies what you’re currently making. There are some exceptions, but as a rule you should assume this. If you must divulge what you’re making, you should be liberal in noting the total value of your package (incorporate bonuses, unvested stock, nearness to promotion etc.), and always mention it in a context like “[XYZ] is what I’m currently making, and I’m definitely looking for a step up in my career for my next role.” Companies will ask about your current compensation at different stages in the process — some before they ever interview you, some after they decide to make you an offer. But be mindful of this, and protect information. So given this offer, don’t ask for more money or equity or anything of the sort. Don’t comment on any specific details of the offer except to clarify them. Give away nothing. Retain your power. Say instead: “Yeah, [COMPANY_NAME] sounds great! I really thought this was a good fit, and I’m glad that you guys agree. Right now I’m talking with a few other companies so I can’t speak to the specific details of the offer until I’m done with the process and get closer to making a decision. But I’m sure we’ll be able to find a package that we’re both happy with, because I really would love to be a part of the team.” Think like the watermelon farmer. This offer is just the first businessman who’s stopped by your watermelon patch, glanced over your crops, and announced “I’ll take all of these right now for $2 a melon.” Cool. It’s a big market, and you’re patient — you’re a farmer after all. Just smile and tell them you’ll keep their offer in mind. And this is super important: always be unequivocally positive. The importance of positivity Staying positive is rule #4 of negotiation. Even if the offer sucks, it’s extremely important to remain positive and excited about the company. This is because your excitement is one of your most valuable assets in a negotiation. A company is making you an offer because they think you’ll do hard work for them if they pay you. If you lose your excitement for the company during the interview process, then they’ll lose confidence that you’ll actually want to work hard or stay there for a long time. Each of those makes you less attractive as an investment. Remember, you are the product! If you become less excited, then the product you’re selling actually loses value. Imagine you were negotiating with someone over buying your watermelons, but the negotiation took so long that by the time you’d reached an agreement, your watermelons had gone bad. Companies are terrified of that. They don’t want their candidates to go bad during a negotiation. Hence why they hire professional recruiters to manage the process and make sure they remain amicable. You and the recruiter share the same interest in that regard. If a company feels like you’ve gone bad, suddenly they’re a lot less willing to pay for you. So despite whatever is happening in the negotiation, give the company the impression that 1) you still like the company, and that 2) you’re still excited to work there, even if the numbers or the money or the timing is not working out. Generally the most convincing thing to signal this is to reiterate you love the mission, the team, or the problem they’re working on, and really want to see things work out. Don’t be the decision-maker You can wrap up the conversation now by saying: “I’ll look over some of these details and discuss it with my [FAMILY / CLOSE_FRIENDS / SIGNIFICANT_OTHER]. I’ll reach out to you if I have any questions. Thanks so much for sharing the good news with me, and I’ll be in touch!” So not only are you ending the conversation with the power all in your hands, but note there’s another important move here: you’re roping in other decision-makers. Rule #5 of negotiation: don’t be the decision-maker. Even if you don’t particularly care what your friends/family/husband/mother thinks, by mentioning them, you’re no longer the only person the recruiter needs to win over. There’s no point in them trying to bully and intimidate you; the “true decision-maker” is beyond their reach. This is a classic technique in customer support and remediation. It’s never the person on the phone’s fault, they’re just some poor schmuck doing their job. It’s not their decision to make. This helps to defuse tension and give them more control of the situation. It’s much harder to pressure someone if they’re not the final decision-maker. So take advantage of that. Okay! We have our first offer. Send a follow-up e-mail confirming all of the details you discussed with your recruiter so you have a paper trail. Just say “just wanted to confirm I had all the details right.” Groovy. Next step is to leverage this to land other offers and find the best deal we can find in the job market. Getting other offers Turns out, it doesn’t matter that much where your first offer is from, or even how much they’re offering you. Just having an offer in hand will get the engine running. If you’re already in the pipeline with other companies (which you should be if you’re doing it right), you should proactively reach out and let them know that you’ve just received an offer. Try to build a sense of urgency. Regardless of whether you know the expiration date, all offers expire at some point, so take advantage of that. “Hello [PERSON], I just wanted to update you on my own process. I’ve just received an offer from [COMPANY] which is quite strong. That said, I’m really excited about [YOUR AMAZING COMPANY] and really want to see if we can make it work. Since my timeline is now compressed, is there anything you can do to expedite the process?” Should you specifically mention the company that gave you an offer? Depends. If it’s a well-known company or a competitor, then definitely mention it. If it’s a no-name or unsexy company, you should just say you received an offer. If it’s expiring soon, you should mention that as well. Either way, send out a letter like this to every single company you’re talking to. No matter how hopeless or pointless you think your application is, you want to send this signal to everyone who is considering you in the market. Second, if there are any other companies you are looking to apply to (whether through referral or cold application), or even companies at which you’ve already applied but haven’t heard back, I would also follow up with a similar e-mail. So why do this? Isn’t this tacky, annoying, or even desperate? None of the above. It is the oldest method in history to galvanize a marketplace — show that supplies are limited and build urgency. Demand breeds demand. Not every company will respond to this, but many will. Isn’t it stupid that companies respond to this though? Why companies care about other offers When I wrote about the story of my own job search, I mentioned how having an offer from Google made companies turn around and expedite me through their funnels. Many commentators lamented at the capriciousness of these companies. If Uber or Twitch only talked to me because of Google and until then weren’t willing to look at me, what did that say about their hiring processes? What legitimately are they evaluating, if anything at all? I think this response is totally backwards. The behavior of tech companies here is actually very rational, and you would do well to understand it. First, you must realize what a company’s goal is. A company’s goal is to hire someone who will become an effective employee and produce more value than their cost. How do you figure out who will do that? Well, you can’t know for certain without actually hiring them, but there are a few proxies. Pedigree is the strongest signal; if they did it at other companies, they can probably do it at yours. And if someone trusted within the organization can vouch for them, that’s often a strong signal as well. But turns out, almost everything else is a weak signal. Weak in the sense that it’s just not very reliable. Interviews, if you think about it, are long, sweaty, uncomfortable affairs that only glancingly resemble actual employment. They’re weird and can’t tell you that much about whether an individual will be good at their job. There’s no way around this. There are a few stronger signals, like bringing someone in for a week or two on a contract-to-hire position, but strong candidates won’t consider this. So candidates as a whole have effectively forced companies to assume almost all of the risk in hiring. The truth is, knowing that someone has passed your interview just doesn’t say that much about whether they’ll be a good employee. It’s as though you knew nothing about a student other than their SAT score. It’s just not a lot of data to go off. Nobody has solved this problem. Not Google nor anyone else. And this is precisely why it’s rational for companies to care that you’ve received other offers. They care because each company knows that their own process is noisy, and the processes of most other companies are also noisy. But a candidate having multiple offers means that they have multiple weak signals in their favor. Combined, these converge into a much stronger signal than any single interview. It’s like knowing that a student has a strong SAT score, and GPA, and won various scholarships. Sure, it’s still possible that they’re a dunce, but it’s much harder for that to be true. This is not to say that companies respond proportionally to these signals, or that they don’t overvalue credentials and brands. They do. But caring about whether you have other offers and valuing you accordingly is completely rational. So this is all to say — tell other companies that you’ve received offers. Give them more signal so that they know you’re a valued and compelling candidate. And understand why this changes their mind about whether to interview you. As you continue interviewing, remember to keep practicing your interview skills. The single strongest determinant of your final offer will be the number and strength of offers that you receive. Some advice on timing You want to be strategic about the timing of your offers. Generally, you should try to start interviewing at larger companies earlier. Their processes are slower and their offer windows are wider (meaning they allow you more time to decide). Startups are the other way around. Your goal should be to have as many offers overlapping at the same time as possible. This will maximize your window for negotiating. When you receive an offer, often the first thing you should ask for is more time to make your decision. Especially in your first offer, more time is by far the most valuable thing you can ask for. It’s time that enables you to activate other companies and end up with the strongest possible offer. So be prepared to fight for time. How to approach exploding offers Hoo boy. Exploding offers are offers that expire within 24–72 hours. You won’t see this much at big companies, but they’re becoming increasingly common among startups and mid-sized companies. Exploding offers suck, and I share most people’s disdain for this practice. But I do understand it. Exploding offers are a natural weapon for employers to combat a strong hiring market for tech workers. Companies know exactly what they’re doing with exploding offers — they play on fear and limit your ability to seek out counteroffers. In a sense, it’s unsurprising that if startups have more difficulty attracting and securing talent, they’d resort to this practice. What I don’t like is the dishonesty about it. Employers often justify this by saying: “If you need more time than this, then that’s a sign you’re not the kind of person we’re looking for.” Please don’t buy this crap or feel guilty over it. They’re simply doing this to improve their chance of closing candidates. Needing more than three days to make a life decision isn’t a sign of anything other than thoughtfulness. So what should you do if you receive an exploding offer? Exploding offers are anathema to your ability to effectively navigate the labor market. Thus, there is only one thing to do. Treat the offer as a non-offer unless the expiration window is widened. In no uncertain terms, convey that if the offer is exploding, it’s useless to you. Example conversation: “I have one big concern. You mentioned that this offer explodes in 48 hours. I’m afraid this doesn’t work at all for me. There’s no way that I can make a decision on this offer within a 48 hour window. I’m currently wrapping up my interview process at a few other companies, which is likely to take me another week or so. So I’m going to need more time to make an informed decision.” If they push back and say this is the best they can do, then politely reply: “That’s really unfortunate. I like [YOUR COMPANY] and was really excited about the team, but like I said, there’s no way I can consider this offer. 48 hours is just too unreasonable of a window. The next company I join will be a big life decision for me, and I take my commitments very seriously. I also need to consult with my [EXTERNAL_DECISION_MAKER]. There’s no way that I can make a decision I’m comfortable with in this short an amount of time.” Pretty much any company will relent at this point. If they persist, don’t be afraid to walk away over it. (They probably won’t let that happen, and will come grab you as you’re walking out the door. But if they don’t, then honestly, screw ‘em.) I was given several exploding offers during my job search. And every time, I did essentially this. Every single offer immediately widened to become more reasonable, sometimes by several weeks. I want to emphasize, lest I be misunderstood here — what I’m saying is not to just silently let an exploding offer expire, and assume that everything will be fine and they’ll still hire you. They won’t. For exploding offers to be a credible weapon, a company has to have a reputation of enforcing them. I’m saying explicitly call this out as an issue when they make the offer. Don’t let a company bully you into giving away your negotiating power. The Negotiating Mindset Before we enter into the actual back-and-forth, I want to examine the mindset you should have as a negotiator. This applies not just to how you approach the conversation, but also to how you think about the company. Do not fall into the trap of valuing companies solely along one dimension. That means don’t just value companies based on salary, equity, or even on prestige. Those are all important dimensions, but so are cultural fit, the challenge of the work, learning potential, later career options, quality of life, growth potential, and just overall happiness. None of these inherently trump any of the other. Anyone who tells you “just choose wherever you think you’ll be happiest” is being just as simplistic as someone who says “just choose the one that offers the most money.” All of these things matter, and your decision should be genuinely multi-dimensional. Be open to being surprised as you explore different companies. It’s also important to understand that companies don’t all value you along the same dimension either. That is, different companies are genuinely looking for different skills, and there are some companies at which you will be more and less valuable. Even at peer companies this is true, especially so if you have a specialized skill-set. The more companies you talk to, the more likely you are to find a company to which you are significantly more valuable than the rest. Chances are this is where you’ll be able to negotiate your strongest offer. It might surprise you which company this turns out to be; keep an open mind, and remember that a job search is a 2-sided process. One of the most valuable things you can do for yourself in this process is to really try to understand how employers think and what motivates them. Understanding your interlocutor is extremely important in negotiation, and we’ll be exploring that a lot in the next blog post. But most of all I want to emphasize: be curious about the other side. Try to understand why employers think the way they do. Be sympathetic toward them. Care about what they want and help them try to get it. Adopting this mindset will make you a much stronger negotiator, and accordingly, a much better employee and team member. Okay. That’s as far as we’re going for today. In the next blog post, I’m going to cover the last four rules of negotiation. I’ll also go over the actual back-and-forth process — how to ask for what you want, how to strengthen offers, and how to dismantle the tricks that companies will try to pull on you. Also a lot more on the theory of negotiation, which I really dig.

    starstarstarstarstar
  • 00:10:50

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

    · The freeCodeCamp Podcast

    Roger explains why everyone should learn to code, even if they don't intend to go pro. "Learning something difficult, however, is beneficial in and of itself. The process is the prize. Struggling with code, while frustrating, is medicine for the mind." Written and Read by Roger Collier: https://twitter.com/RogerAFCollier Original article: https://fcc.im/2keLLrU Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript:  It was far past midnight. My wife and kids had long gone to bed. But sleep was not an option for me. I had to figure it out. So I tweaked the code again, for the googolth time, and hit run. Hmm, looks promising. If I click here, the program should call the “compute next move” function. Yes. And if I click here, that function should call itself. Good. Now, if I click here, I should get…not that. Argh. More tweaks. More errors. More hours tick by. Learning programming is hard, I thought. My next thought? Yes, and that’s why I like it. How programming became my hobby I began to learn how to code using JavaScript four months ago, starting with freeCodeCamp’s front-end curriculum. For me, programming became a hobby. Over the past few years, I had become disappointed with my creation-to-consumption ratio. Too much of my free time was spent consuming. Netflix, podcasts, Twitter, magazines, televised sports, Facebook, blogs, Medium, newspapers, novels — the list goes on. There is nothing wrong with any of these activities, but they are all pure input. Even reading a great book is an act of consumption. Sure, I was generating plenty of output in my job as a journalist, but I could no longer accept the fact that hard work was something I did only when it would result in a paycheck. With a family and a career and other obligations, I had only so much free time. I was spending far too much of it scarfing down media. And I felt like a pig. So far, my programming hobby hasn’t result in all that much output. I made one simple app, which I wrote about in a previous article. I’ve completed all the front-end challenges and projects on freeCodeCamp. But it’s a start. My goal is not to create amazing things to impress people. It is simply to immerse myself in the act of creation, to challenge myself, to attempt something difficult — if for no other reason than to finish it. Harder is better In my home province — Ontario, Canada — there is a movement to improve physical health called Make Your Day Harder. The basic premise is that making small tweaks to daily routines to increase physical activity can add up and improve health. Take the stairs instead of the elevator. Get off the bus one stop before your destination. Take the parking spot farthest away from the entrance at work. I couldn’t agree more. Those elevator-hating far-parkers are onto something. Of course, sitting in front of a computer writing code isn’t going to improve your physical health. JavaScript is great for building apps, not abs. I don’t think it’s too much of a stretch, though, to suggest that learning how to program is healthy for your brain. Healthier, at least, than bingeing Iron Fist or thumbing through celebrity Instagram accounts. For me, even after I started coding, the default during downtime is still too often leisure. This month, for instance, I have already spent dozens of hours watching genetic outliers throw a ball at a metal ring. This is otherwise known as the NBA playoffs. Since I’m a Toronto Raptors fan, you could also call it self-induced torture. Does watching so much basketball — alone, in my basement — benefit me in any way? Well, I drink more beer when I watch sports. I eat more nachos and wings and potato chips. Mike and Ikes have made several appearances. Oh, and I often stay up late to watch the West Coast games, so I’m getting less sleep. In other words, watching sports, for me, is a vice. I enjoy it, but it’s actually bad for me. It provides me with entertainment, but nothing else. Except for love handles and the occasional mid-afternoon yawn attack. But it’s easy. It’s oh so easy. Plop on couch. Crack open Corona. Kick up your feet. Sit there for three hours. The easy path is more tempting. The difficult path is more rewarding. Embracing difficulty I was again reminded of the value of embracing difficulty while watching the movie Hidden Figures. The film featured an excerpt of John F Kennedy’s “We choose to go to the moon” speech. The United States pursued space travel not despite it being difficult, the president declared, but rather because it was difficult. “We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win, and the others, too.” — John F Kennedy The words “hard” and “difficult” are often used to describe something negative. In many cases, that’s appropriate. It is hard to watch a loved one fall ill and suffer. It is difficult when a relationship fails or a pet dies. Some situations are all pain, no profit. Learning something difficult, however, is beneficial in and of itself. The process is the prize. Struggling with code, while frustrating, is medicine for the mind. If you happen, along the way, to create something amazing and users flock to your app with open wallets, that’s great. If not, code anyway. If you master JavaScript and become a YouTube guru with more subscribers than the New York Times, that’s great. If not, code anyway. Many people learn programming to attain a specific goal. Perhaps your job is boring and you want a more challenging one. Nothing wrong with that. Maybe you want to break into tech because you need a higher income to support your family. Hey, someone has to buy the bagels and flip flops, and keep the WiFi pumping. But you don’t need an endgame in mind to start your coding journey. Just begin. And if that journey becomes difficult, don’t despair. It means you’re on the right path. The hard one.  

    starstarstarstarstar
  • 00:13:42

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

    · The freeCodeCamp Podcast

    Genius is a fickle beast. Sometimes you have the good fortune to work with a mad genius. Other times you are doomed to work with pure madness. There are also times when it is hard to tell the difference. In this episode we explore "brilliant jerks" and how to save your development team from them. Written and Read by: Jonathan Solórzano-Hamilton Follow him on Twitter: https://twitter.com/jhsolor His full article on freeCodeCamp's Medium publication: https://fcc.im/2BAhnm6 Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02   Transcript: “You will never be able to understand any of what I’ve created. I am Albert F***ing Einstein and you are all monkeys scrabbling in the dirt.” And so our resident genius, our Dr. Jekyll, explosively completed his transformation into Mr. Hyde. He declared this in front of the product design team, developers, management, and pre-launch customers. One of our project sponsors had the temerity to ask when the problem crippling our product would be fixed. Genius is a fickle beast. Sometimes you have the good fortune to work with a mad genius. Other times you are doomed to work with pure madness. There are also times when it is hard to tell the difference. This story is about the fall from grace of an extremely gifted team member with a deep understanding of our product’s architecture. He had an uncanny ability to forecast future requirements, and a ton of domain-specific knowledge. He was our top contributor. He was killing our flagship project. We’ll call this person “Rick.” Rick was universally recognized on the team as the top talent. He was the lead developer and architect of our software projects. Any time anyone had a question about code or needed help with a task, they would go to Rick. Rick had a giant whiteboard installed in his office used only for this purpose. It was always cluttered with the ghosts of past discussions that wouldn’t quite erase. Any time there was a particularly challenging problem, Rick would handle it. Rick had a server with the same specs as our production server installed at his desk. He used this to run the entire application stack independently and troubleshoot every layer at once. Rick didn’t need anybody else. Rick preferred to work alone in his private work-space. Rick didn’t need anything anybody else built. He built everything he needed from scratch because it was infinitely better than the paltry offerings of mere mortals. Soon, Rick stopped attending meetings. Rick didn’t have time for meetings any more because there was too much to code. Rick closed his door. His whiteboard lay fallow. Rick no longer had time to train anyone because he had too much to solve on his own. A backlog grew behind Rick. Bugs were popping up in old tools he’d built. They sapped his attention from meeting commitments on new product development. Of course, these bugs were happening because the users had misstated their assumptions. Of course there wasn’t any problem in his work. Of course. On our project dashboard, green flags changed to yellow. Yellow changed to red. Red lights started blinking. One by one, task statuses changed to “Impeded.” Everyone was waiting for Rick. The project manager got a six-month extension from the sponsor. At the end of the six months, production-readiness was estimated to be seven months away. At the end of a year, production-readiness was two years out. Rick was churning out code faster than ever. He was working seven-day weeks, twelve hours a day. Everyone knew only Rick could pull the team out of this mess. Everyone held their breath and waited for Rick to invent the miracle cure that would mend this crippled project. Every day, Rick grew more belligerent and isolated. The mask was coming off. Jekyll was becoming Hyde. I participated in my first meeting with the project team about two years after the original agreed release date. I’d been aware of the project for a while, because it had grown infamous in my organization, but hadn’t been assigned to it. I was sent in to see if we could save it. My first meeting on the project was the aforementioned “Albert Einstein” meeting. Hmm. I dove into the source code. Rick was right: no-one could possibly understand what Rick had created. Except for Rick. It was a reflection of the workings of his own mind. Some of it was very clever, a lot of it was copy-pasta, it was all very idiosyncratic, and it was not at all documented. I went to our CIO with the verdict. Only Rick would ever be able to maintain this product. Plus, every day that Rick worked on the project moved the delivery date back a week. Rick was destroying our product faster than he was creating it. We sat down with Rick and had a conversation about his role in the project. We reviewed our concerns. We sidestepped his self-comparison to Albert Einstein. We explained our new strategy. The team was going to collaborate on building a new product from scratch. This effort would be very limited in scope and would only provide the bare essentials to get us to production. The whole team would contribute and be able to support it. No more bottlenecks. How did Rick react to this? The only way Rick could. Rick exploded. Rick wanted no part of this farce. If we couldn’t appreciate his genius, that was our fault, not his. Rick predicted that within months we’d come crawling back to him begging him to save us. Rick screamed that we lacked the basic mental capacity to appreciate genius when it was staring us in the face. Sadly, after this, Rick rejected months of overtures by leadership. He refused to take time off or allow any work to be delegated. He rejected repeated attempts to introduce free open source frameworks to replace his hard-to-maintain bespoke tools. He reverted code changes — including tested bug fixes — by other developers. He asserted that he wouldn’t be held accountable for supporting other people’s work. He continued publicly belittling his colleagues. We fired Rick. It took about a week for the dust to settle. It took time for the shocked team to gather themselves after losing their embattled guru. Then I saw them huddled around a whiteboard. They collaborated. They designed a replacement product. It would be much simpler. It wouldn’t have all the bells and whistles. Nor would it anticipate requirements from five years down the product road map. Rick’s product supported a dynamic workflow with over fifteen thousand permutations. In reality 99% of our use cases followed one of three paths. The team hard-coded the workflow. This removed over 30% of Rick’s work. It wouldn’t have custom hand-coded components for every task. They stripped out every bespoke dependency that they could buy instead of build. This removed hundreds of hours of Rick’s contribution. But it also removed thousands of hours of technical debt. We obtained an agreement from the project sponsor to shut off some edge-case functionality. This had served only 5% of our pre-launch user group and was responsible for about a quarter of the product’s complexity. We re-released the product to this group. It consisted of 10% of Rick’s original code which was pretty stable. It also had a few thousand lines of new code to replace about 150,000 lines of incomprehensible mess. The team had replaced five years of work in about six months. Over the next few months we expanded from pilot to full customer release. Not only had we replaced what Rick had built, we sped past him and fully launched the product — all in under a year. The result was less than a fifth the size and complexity of what Rick had built. It was also hundreds of times faster and nearly bug-free despite having been assembled in a fraction of the time and serving ten times as many customers. The team went back to Rick’s other products. They threw away his old code there, too. They re-released another product of his after three years in development, with three months of concerted team effort. There were no Ricks left on the team. We didn’t have any mad geniuses building everything from scratch. But our productivity was never higher. Rick was a very talented developer. Rick could solve complex business logic problems and create sophisticated architectures to support his lofty designs. Rick could not solve the problem of how to work effectively on a team. Rick’s presence was destructive in several ways. First, he created a cult of dependence. Any problem eventually became a Rick problem, a myth he encouraged. Developers learned to stop trying and just wait for Rick. Second, he didn’t write maintainable code. He never documented or tested anything, and so failed in spite of his own intelligence. His belief in his personal infallibility trumped common sense. Third, he was personally destructive. Team members didn’t want to speak up and offer their own ideas because he always berated them for it. Rick only respected Rick and went out of his way to make everyone else feel small. Fourth, he lacked all personal accountability. No failure was his fault. He sincerely believed this, and it prevented him from learning from his own mistakes. I don’t believe Rick started out this way. I saw him at his worst. This was after years of working escalating overtime and facing increasing criticism from customers and colleagues. It’s sad that Rick descended this far. His manager shares in this responsibility. In fact, the original management team was held accountable: they were let go first. Unfortunately Rick was so far gone that he couldn’t, or wouldn’t, be brought back. No amount of coaching, feedback, time off, or assignment to other projects changed his toxic behavior. By this point the whole team knew he was destructive. But the cult of dependence was so strong that everyone believed he was the only option. There is always another option. Your team’s strength is not a function of the talent of individual members. It’s a function of their collaboration, tenacity, and mutual respect. Focus on building teams that value each other and try to bring the best out of one another. Together, they’ll be able to tackle greater challenges than Rick could ever fathom. I have published a follow-up story with our lessons learned if you are interested in reading more! You may also be interested in reading about my first job at a startup, which happened to be imploding around me. You can follow me here or on Twitter @jhsolor for more updates. Note: Some details (such as names) have been changed. I’ve never actually worked with anyone named Rick.

    starstarstarstarstar
  • 00:11:29

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

    · The freeCodeCamp Podcast

    Madison tells her story of how she went from being a fashion model with no college degree to full-time software engineer in just one year. She used free online resources including freeCodeCamp, and worked for free at a startup until they hired her. Written and read by Madison Kanna: https://twitter.com/MadisonKanna Article link: https://fcc.im/2ApFnXO Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Resources mentioned: https://discoverpraxis.com https://www.freecodecamp.org https://www.udacity.com https://frontendmasters.com/ Transcript: In 2015 I knew almost nothing about coding. Today, I’m a software engineer and a teacher at a code school for kids. When people find out I work as an engineer, they often ask, “How can I get a job as a software engineer coming from a nontraditional background?” Well, you can’t get more nontraditional than me. I was homeschooled growing up, and I’m a college dropout. When I dropped out, I signed with an agency and modeled for fashion brands. I didn’t know what I wanted to do with my life, but my sister was a software engineer and she loved it. So one day, I took Udacity’s “Intro to Computer Science” course. And I loved it. Coding became my biggest passion. I knew I would become a software engineer. I also knew it might be the hardest thing I ever did. But I resolved to see it through. I was going to make this happen. If you love to code, and keep working toward your goal of becoming a developer, you will get there — no matter where you come from. Here’s how I did it. Figured out how you learn best. After months of teaching myself to code, I knew I needed that next step, so I applied to several coding bootcamps. Yet I realized that I learn best not by studying, but when I am working. Figuring out how I learn most efficiently was a huge help. For you, maybe you need to immerse yourself fully at a bootcamp, or take a part-time online program. For me, I realized I would learn best by jumping headfirst into an engineering internship. But… how could I get one? Build your personal brand. I knew I wanted real-world experience. So I enrolled in Praxis, a program that places young people into apprenticeships at startups. But Praxis focuses on marketing and sales roles, and I was determined to become an engineer. So, I decided to find myself an engineering internship and use Praxis to help me build my personal brand to increase my chances of being hired. I worked with Simon from Praxis, who helped me prepare for interviews and create my online presence. My mom, an entrepreneur and brand expert, encouraged me to blog about coding, speak at meetups, start a YouTube channel, and continue to build my GitHub portfolio. I kept sharing whatever I was learning about. Eventually, when you Googled me you could immediately see that I was passionate about coding. Google yourself. What do you see? Work for free and love the work. While originally I had hoped to get a paying internship, I quickly realized I had a better chance of getting experience as an engineer if I did free work. I found a startup I wanted to work for and pitched myself to them: I’d work for for free as an engineering dev for a few months. Then they could either promote me or let me go depending on how I did. They agreed, and I spent the next few months working harder than I ever have. I relished every moment I spent just fixing one little bug in the app. Later on, I realized that although I didn’t have a ton of technical skills going in, my passion to learn and my excitement to be a part of the team shone through and got me the internship. Even though I was working for free, I loved the work and the team more than any paying job I’ve ever had. Make your nontraditional background a strength, not a weakness. At first, I didn’t want to highlight just how nontraditional my background was. I feared I already stuck out enough just being a female programmer, let alone someone without a CS background. Then my mom said, “Own who you are. Use your previous experiences as a strength.” For my first dev internship, I made it clear I would help out the startup in any way that I could. I talked about the variety of other skills I had picked up way back when I worked for my mom’s company, and how I could utilize those skills while I was also growing into the role of junior developer. I didn’t just try to be an engineering intern. The first week of my internship, I did anything from uploading YouTube videos to writing code to making copy changes. For many startups, they want people who are hungry to learn and get things done — not just code monkeys. What skills from your previous career can you utilize to make yourself valuable, not just as a developer but as a member of the team? A few months into my internship, the company’s CEO, Bryan, sent me a Slack message. “Madison, we want you to work for us.” I was promoted to junior developer. For the first time, I was getting paid to code. Use the haters to push you forward. Many times, when I told someone I was working towards being an engineer, they would look at me and say, “You? An engineer? Are you sure?” For awhile this frustrated me. Then I realized that I wasn’t going to let what anyone said stop me. Each time I heard those comments, I went home and started coding. I used the haters as fuel to keep pushing myself towards my goal. People will always tell you that you can’t do it. When you ignore what they say and just keep going, you develop a trust in yourself and a determination that becomes unstoppable. On the other hand, having a support system who believes you can do it is immensely helpful. I couldn’t have become an engineer without the support of my family. Just keep coding. Getting that first junior developer position was the toughest and most rewarding thing I’ve done. If you focus on your love of code and just keep pushing forward, you will get there. No matter where you’re coming from. So what are you waiting for? Let’s code!

    starstarstarstarstar
  • 00:09:48

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

    · The freeCodeCamp Podcast

    Quincy explores Felix Feng's journey from bootcamp grad to professional developer, and how he went from getting $60,000 job offers to $125,000 job offers through sheer practice and persistence. Article by Felix Feng: https://twitter.com/felix2feng Read by Quincy Larson: https://twitter.com/ossia Article link: https://fcc.im/2iX0LtS Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Resources mentioned: https://www.interviewcake.com https://www.hiredintech.com/classrooms/system-design/lesson/60 https://www.educative.io/collection/5642554087309312/5679846214598656 https://www.reddit.com/r/cscareerquestions/comments/1jov24/heres_how_to_prepare_for_tech_interviews/ https://github.com/h5bp/Front-end-Developer-Interview-Questions https://leetcode.com The email tool Felix uses: https://rapportive.com/   Transcript:  A less-talked about part of the bootcamper’s journey is what happens after you graduate — when you’re searching for that six-figure developer position. < 3% of applications became offers I completed Hack Reactor in July 2016 and took almost 3 months before accepting an offer with Radius Intelligence. I applied to 291 companies, did 32 phone screens, 16 technical screens, 13 coding challenges, 11 on-sites, and received 8 offers. The offers ranged from $60-125k in salary from companies all over the US, and for both front end and full stack roles. In total, 2.8% of applications became offers. Here are 5 things I wish I’d known before I began my job search. Insight #1: Get through to real people At first, I applied for companies using the shotgun approach. I applied through Indeed.com, AngelList, LinkedIn, StackOverflow, Hacker News, company websites, and even Craigslist. I’d submit a resume for any role that wanted React, Node, or JavaScript experience. In the first week, I applied to 15–20 companies a day. Pro-Tip: Find companies using this easy-application repo. My yield was low. Less than five percent of companies responded to me. I was throwing applications into a black hole. Everything changed when one of my cohort-mates, a former recruiter, shared a guide to the job search. He told us to send emails directly to real people with each application. It could be anybody. As long as someone read it. From then on, whenever I submitted an application, I searched for the company on LinkedIn and emailed someone on their engineering or hiring team. For most small companies or C-level executives, the email format is usually firstName@dreamCompany.com. For larger companies, it may be firstName.lastName@dreamCompany.com. To verify emails, I used Rapportive to cross-check emails with social media accounts. The results were amazing. With 150+ emails sent, my response rate was a whopping 22%. It also felt great to hear from real people. Surprisingly, CEOs and CTOs responded to me. Sometimes they even interviewed me themselves. Takeaway: If you’re applying through the front door, make sure you’re getting to human beings. Insight #2: Start small and work your way up You will face Level 1 interviews (a non-tech company that needs any dev), where interviewers ask you nothing more than JavaScript trivia. You will face Level 9 interviews (Google/Facebook level), where interviewers ask difficult data structure and algorithm questions. I strategically set up my process so that I had lower-level interviews earlier, and higher-level interviews later on. Early on, I gained experience, built confidence, and secured offers from companies that had less intensive interviews. As I got more experience, I effectively “leveled up.” I became capable of completing interviews at companies with higher hiring bars. This is illustrated below as a linear correlation between the number of weeks I was into the process and the base salary I was offered. There’s a direct correlation between time spent interviewing and offer salary. I unlocked tougher questions. I unlocked higher salaries. And eventually, I unlocked the job I took. Takeaway: Plan to tackle easier interviews early on and more difficult ones later on. Insight #3: Study like your future job depends on it (because it does) I hate to break it to you, but the most important thing you could be doing at any point is studying and preparing. Why? Because you won’t get the offer if you don’t have good answers to the questions they ask you. People won’t refer you if they don’t think you’re prepared for their interviews. Coming out of Hack Reactor, my weaknesses were data structures and algorithms. A study by Triplebyte has found that bootcamp grads are weaker in these areas than computer science grads. So I learned and practiced. Every day. I devoted entire days to learning sorting algorithms. Other days, I focused on understanding how the internet worked. If I didn’t fully understand a concept, I’d spend the day watching YouTube videos or searching StackOverflow until I did. I found the following study materials useful: InterviewCake: My favorite resource for data structures and algorithms. It breaks down solutions into step-by-step chunks — a great alternative to Cracking the Code Interview (CTCI). My only gripe is that they don’t have more problems! HiredInTech’s System Design Section: A great guide for system design interview questions. Coderust: If you’re avoiding CTCI like the plague, Coderust 2.0 may be perfect for you. For $49, you get solutions in almost any programming language, with interactive diagrams. Reddit’s How to Prepare for Tech Interviews: I constantly used this as a benchmark for how prepared I was. Front End Interview Questions: An exhaustive list of front-end questions. Leetcode: The go-to resource for algorithm and data structure questions. You can filter by company, so for example, you could get all the questions that Uber or Google typically ask. Takeaway: There’s no such thing as too much preparation. Insight #4: Put your best foot forward Breaking into the industry is hard. You have to perform well, even when you’re not fully prepared. In order to succeed, you have to be your own advocate. Sell Yourself At Hack Reactor, we’re trained to mask our inexperience. In our personal narratives, we purposely omit our bootcamp education. Why? Otherwise, companies automatically categorize us into junior developer roles or tag us as “not enough experience.” In one interview with a startup, the interview immediately went south once they realized I’d done a bootcamp. One company used it against me and made me a $60k offer, benchmarking against junior developers. Ultimately, you need to convince companies that you can do the job. At the same time, you need to convince yourself that you can do the job. You can. Focus on your love for programming. Focus on what you’ve built with React and Node. Focus on demonstrating your deep knowledge in JavaScript and any other languages you’ve learned. Only then can they justify giving you the job. It’s a Two-way Conversation Interviewing is a mutual exploration of fit between an employee and an employer. While it’s your job to convince employers to hire you, it’s also their job to win you over. Don’t be ashamed of using the interview as an opportunity to evaluate the job opportunity. I talked to any company, even if I had only the slightest interest. I did on-sites all over the country with any company that invited me out. I asked questions, and sucked up knowledge on engineering team organization, technologies and tools used, company challenges, and system architecture. Pro-Tip: During interviews, ask the following questions: What are some technical challenges you’ve recently faced? What do you enjoy about working at X company? How are teams structured and how are tasks usually divided? I treated every interaction as a learning opportunity. Each interaction helped me improve my presentation, interview, and technical skills. Each failure helped me find my blind spots. Takeaway: Don’t sell yourself short! And remember, it’s a mutual exploration. Insight #5: It’s a marathon, not a sprint The journey is by no means easy. For 3 months, I grinded 6 days a week. But I tried to take care of myself. What a typical day could look like in JavaScript Some days, I’d study with friends. Other days, I’d go find a cafe and study alone, or hang out at Hack Reactor’s alumni lounge. And every week I’d check in with our career counselor to talk about my progress. It’s easy to burn out during the process. Eat well, sleep, and exercise. It can get lonely. Spend time with friends who are going through the same experience. Takeaway: Prepare for the long game and make sure you take care of yourself. In summary, the key takeaways are: Get through to real people Start small and work your way up Study like your future job depends on it Put your best foot forward It’s a marathon, not a sprint The process may seem endless, but you’re going to make it. Keep putting in the hours. Keep sending in the applications. Keep taking caring of yourself. All of it pays off in the end.

    starstarstarstarstar
  • 00:09:59

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

    · The freeCodeCamp Podcast

    Canadian software engineer Bill Sourour recounts a tragic experience early in his developer career when writing code for a pharmaceutical company. He explores developer ethics, the responsibilities developers have, and the challenges they face in sticking to their values.   Written by and read by Bill Sourour: https://twitter.com/billsourour   Original Article: https://medium.freecodecamp.org/the-code-im-still-ashamed-of-e4c021dff55e    The Future of Programming by Bob Martin: https://youtu.be/ecIWPzGEbFc    Business Insider Story: "Programmers are having a huge discussion about the unethical and illegal things they’ve been asked to do” http://www.businessinsider.com/programmers-confess-unethical-illegal-tasks-asked-of-them-2016-11?op=1   CBC Interview http://www.cbc.ca/radio/the180/stop-subsidizing-seniors-good-judges-can-make-bad-decisions-and-which-canadian-city-is-the-most-american-1.4028473/creating-a-code-of-ethics-for-coders-1.4028677   Code Newbie Interview https://www.codenewbie.org/podcast/the-ethics-of-coding   Developer Ethics on FCC Guide https://guide.freecodecamp.org/developer-ethics   Learn to code for free at: https://www.freecodecamp.org   Music: "Sounds of Wonder" by Vangough: https://fcc.im/2yQOq0q   Transcript:  If you write code for a living, there’s a chance that at some point in your career, someone will ask you to code something a little deceitful – if not outright unethical. This happened to me back in the year 2000. And it’s something I’ll never be able to forget. I wrote my first line of code at 6 years old. I’m no prodigy though. I had a lot of help from my dad at the time. But I was hooked. I loved it. By the time I was 15, I was working part-time for my dad’s consulting firm. I built websites and coded small components for business apps on weekends and in the summer. I was woefully underpaid. But as my dad still likes to point out, I got free room and board, and some pretty valuable work experience. Later, I managed to help fund a part of my education through a few freelance coding gigs. I built a couple of early e-commerce sites for some local small businesses. By age 21, I managed to land a full-time coding job with an interactive marketing firm in Toronto, Canada. The firm had been founded by a medical doctor and many of its clients were large pharmaceutical companies. In Canada, there are strict limits on how pharmaceutical companies can advertise prescription drugs directly to consumers. As a result, these companies would create websites that present general information about whatever symptoms their drugs were meant to address. Then, if a visitor could prove they had a prescription, they were given access to a patient portal with more specific info about the drug. The home page of edfactscanada.com circa 2001, via The Internet Archive One of the projects I was assigned to involved a drug that was targeted at women. The graphics and general style of the website made it clear that the client wanted to specifically target teenage girls. One of the features of this website was a quiz that asked girls a series of questions and recommended a type of drug based on their answers. Remember, this website was posing as a general information site. It was not clearly an advertisement for any particular drug. When I received the requirements, they contained the questions for the quiz, along with multiple choice answers for each question. Missing from the requirements was any indication of what I should do with the answers at the end of the quiz. So what rules determined what treatment the quiz would recommend? I spoke to the Account Manager about this. She emailed the client and got me the requirements. With those, I proceeded to code up the quiz. Before submitting the website to the client, my project manager decided to give it a quick test. She tried the quiz, then came over to my desk: “The quiz doesn’t work,” she said. “Oh. What’s broken?” I asked. “Well, it seems that no matter what I do, the quiz recommends the client’s drug as the best possible treatment. The only exception is if I say I’m allergic. Or if I say I am already taking it.” “Yes. That’s what the requirements say to do. Everything leads to the client’s drug.” “Oh. Okay. Cool.” And she was off. I wish I could tell you that when I first saw those requirements they bothered me. I wish I could tell you that it felt wrong to code something that was basically designed to trick young girls. But the truth is, I didn’t think much of it at the time. I had a job to do, and I did it. Nothing that we were doing was illegal. As the youngest developer on my team, I was making good money for my age. And in the end, I understood that the real purpose of the site was to push a particular drug. So, I chalked this tactic up to “marketing.” The client was extremely pleased with the site. So much so that their rep invited me and the entire team out to a fancy steak dinner. The day of the dinner, shortly before leaving the office, a colleague emailed me a link to a news report online. It was about a young girl who had taken the drug I’d built the website for. She had killed herself. It turned out that among the main side effects of that drug were severe depression and suicidal thoughts. The colleague who had emailed me didn’t show up to dinner. I still went. It was difficult and awkward. I never mentioned the news report. I just ate my steak quietly and tried to force a smile when I could. The next day, I called my sister. She was 19 at the time. We had discovered while working on the project that she had actually been prescribed the very drug I was building a site for. When we first talked about it, we thought the whole thing was a neat coincidence. Now, the tone of our conversation was very different. I advised her to get off the drug ASAP. Thankfully, she listened. There are a million and one ways for me to rationalize my part in later suicides and severe depression. Even today, there is ongoing litigation with former patients. It’s easy to make an argument that I had no part in it at all. Still, I’ve never felt okay about writing that code. Not long after that dinner, I resigned. As developers, we are often one of the last lines of defense against potentially dangerous and unethical practices. We’re approaching a time where software will drive the vehicle that transports your family to soccer practice. There are already AI programs that help doctors diagnose disease. It’s not hard to imagine them recommending prescription drugs soon, too. The more software continues to take over every aspect of our lives, the more important it will be for us to take a stand and ensure that our ethics are ever-present in our code. Since that day, I always try to think twice about the effects of my code before I write it. I hope that you will too.

    starstarstarstarstar
  • 00:17:23

    Ep. 6 - Which Programming Language Should You Learn First?

    · The freeCodeCamp Podcast

    Quincy reads his popular article on how to choose your first programming language when you learn to code. He discusses Python, Java, JavaScript, Ruby, and C++ in terms of: - the job market for the language - the long term prospects for the language - how easy the language is to learn - what projects you can build while you’re learning (and share with friends so you can stay motivated) Read by Quincy Larson (https://twitter.com/ossia) Article link: https://fcc.im/2yCMatt Learn to code for free at: https://www.freecodecamp.org Music: "Sounds of Wonder" by Vangough: https://fcc.im/2yQOq0q Transcript: Most people’s journey toward learning to program starts with a single late-night Google search. Usually it’s something like “Learn ______” But how do they decide which language to search for? “They always joke about Java on Silicon Valley. I guess I should learn that.” Or: “Haskell. So hot right now. Haskell.” Or: “That Go gopher is just so gosh-darn cute.” And then there’s the rest of us. We’ll probably search for something like: “Which programming language should I learn first?” Few questions are so commonly asked that they get the full infographic treatment. But this is one of them: Deciding on your first programming language can be a fun process — kind of like one of those “Which Quentin Tarantino character are you?” personality quizzes. But before you run off to learn Ruby because you enjoyed playing with Play-Doh as a kid, let me remind you: the stakes are pretty high here. It will take you hundreds of hours of practice to become even remotely competent with your first programming language. So you should consider the following factors: - the job market for the language - the long term prospects for the language - how easy the language is to learn - what projects you can build while you’re learning (and share with friends so you can stay motivated) Every year brings new programming languages, and with them, new academic papers. And new web comics. Seriously. Check out this gem from last month: When it comes to choosing a first programming language, there’s no shortage of options. To narrow it down a bit, here are the most common Google searches related to learning programming, over the past 12 years: Java has had its ups and downs. Python has gradually risen to become the most popular choice. But tucked away below these is the Little Engine That Could, slowly choo-choo’ing up in popularity over the past few years. And that engine is JavaScript. Before I talk about these programming languages, let me clarify: I’m not arguing that any one language is objectively better than any other I agree that developers should eventually learn more than one language I’m arguing that first they should learn one language well. And — as you can probably guess from the upside down text in my headline — that language should be JavaScript. Let’s kick things off by exploring how programming is currently taught in school. Computer Science 101 Universities have traditionally taught programming under the umbrella of computer science, which itself is often seen as an extension of mathematics, or tie-in to an electrical engineering degree. Of course, as you may have heard by now: “Computer science education cannot make anybody an expert programmer any more than studying brushes and pigment can make somebody an expert painter.” — Eric S. Raymond As of 2016, many universities still treat programming like it’s computer science, and computer science like it’s math. As a result, many introductory programming courses focus on low-level-of-abstraction languages like C, or mathematically-focused languages like MATLAB. And department chairs generally stay the course, pointing to annual programming language leaderboards like the TIOBE Index, or this one from the IEEE: Most of these leaderboards look virtually identical to how they were 10 years ago. But change does happen. Even in academia. In 2014, Python overtook Java as a the most popular language of instruction at top US Computer Science programs. And yet another change is bound to… eventually… happen. Because if you look at the languages actually used by the workforce, it paints a very different picture: JavaScript is by far the most popular language used by the 49,397 developers who responded to Stack Overflow’s 2016 Survey. More than half of all developers use JavaScript. It’s vital to front-end web development and increasingly relevant for back-end development. And it’s rapidly expanding into areas like game development and the Internet of Things. Job postings also mention JavaScript more than any programming language other than Java: Data from the world’s largest job posting aggregator, Indeed.com It’s no accident that we built our open source community’s curriculum around JavaScript. Over the past two years, more than 5,000 people have used Free Code Camp to get their first developer job. I’m not advocating JavaScript because I teach it. I teach JavaScript because it’s the surest path to a first developer job. But is JavaScript right for you? Is it worthy of being your first programming language? Let’s explore those factors I mentioned earlier. Factor #1: The job market If you’re learning to program purely out of intellectual curiosity, feel free to skip this factor. But if you — like the vast majority of people learning to program — want to use this skill to get a job, this is an important consideration. As I mentioned earlier, Java is mentioned in more job postings than any other programming language. JavaScript is a close second. But here’s the thing about JavaScript: even though it’s been around for 20 years, it only recently became a serious tool that companies like Netflix, Walmart, and PayPal would build entire applications around. As a result, plenty of companies are hiring JavaScript developers, but there just aren’t that many on the job market. There are 2.7 Java developers competing for every open Java position. Competition for PHP and iOS jobs is similarly fierce. But for every open JavaScript position, there are only 0.6 JavaScript developers. It is very much a sellers’ market for developers with JavaScript skills. Factor #2: The long term prospects The average JavaScript project receives twice as many pull requests as the average Java, Python, or Ruby project. And on top of this, JavaScript is growing faster than any other popular language. Source: The GitHub’s 2016 State of the Octoverse JavaScript’s ecosystem also benefits from a heavy investment of money and engineering talent from companies like Google, Microsoft, Facebook, and Netflix. For example, TypeScript (a statically-typed superset of JavaScript) has more than 100 open source contributors, many of whom are Microsoft and Google employees being paid to work on it. This type of inter-company cooperation is harder to find with Java. Oracle — who effectively owns Java through its acquisition of Sun Microsystems — often sues companies who try to expand upon it. Factor #3: Difficulty to learn This is a parody of an XKCD comic. Most programmers would agree that high-level scripting languages are relatively easy to learn. JavaScript falls into this category, along with Python and Ruby. Even though universities still teach languages like Java and C++ as first languages, they’re considerably harder to learn. Factor #4: Projects you can build with it This is where JavaScript really shines. JavaScript runs on any device that has a browser, right there in the browser. You can build basically anything with JavaScript, and share it anywhere. Because of JavaScript’s ubiquity, Stack Overflow co-founder Jeff Atwood coined his now-famous law: “Any application that can be written in JavaScript, will eventually be written in JavaScript.” And with each passing month, Atwood’s Law holds strong. Java once promised to run everywhere, too. You may remember Java Applets. Oracle officially killed them off earlier this year. Python suffers from much the same problems: “How can I give this game I made to my friend? Even better, is there a way can I put this on my phone so I can show it to kids at school without them having to install it? Um.” — James Hague in Retiring Python as a Teaching Language By contrast, here are some apps that members of our open source community built in their browsers on CodePen. You can click through and use these right in your browser: - 1970s style Simon game - Conway’s Game of Life - Star Wars-themed Wikipedia Search - A roguelike dungeon crawler game Learn one language well. Then learn a second one. If you keep jumping from language to language, you won’t get far. In order to move beyond the basics, you need to learn your first language well. Then your second language will be much, much easier. From there, you can branch out, and become a more well-rounded developer by learning lots of languages: C is a great way to learn how computers actually work in terms of memory management, and is useful in high-performance computing C++ is great for game development. Python is awesome for science and statistics. Java is important if you want to work at large tech companies. But learn JavaScript first. OK, now I’m going to attempt the impossible — I’m going to try and anticipate objections from the comments section. Objection #1: But isn’t JavaScript slow? JavaScript is — for most practical purposes — as fast as high-performance languages. JavaScript (Node.js) is orders of magnitude faster than Python, Ruby, and PHP. It is also nearly as fast as high-performance languages like C++, Java, and Go. Here are the results of the most comprehensive recent cross-language benchmark: Objection #2: But JavaScript isn’t statically typed Like Python and Ruby, JavaScript is dynamically typed, which is convenient. But you can get into trouble. Here I intend for exampleArray to be an array. I set its values, then check its length — meaning the number of elements it contains. exampleArray = [1, 2] -> [1, 2] exampleArray.length -> 2 But then I accidentally assign it to be a string. exampleArray = “text” -> “text” exampleArray.length -> 4 These kinds of errors happen all the time in dynamically typed languages. Most developers just put checks in place to prevent them, and write tests accordingly. If you absolutely must have static typing in your first programming language, then I still recommend you learn JavaScript first. Then you can quickly pick up TypeScript. “Typescript has a learning curve, but if you already know JavaScript, it will be a smooth one.” — Alex Ewerlöf on TypeScript Objection #3: But I really want to make a mobile app I still recommend learning JavaScript first. JavaScript features several tools for making native mobile apps, such as Angular Cordova and React Native. In order for your mobile app to actually do anything interesting, it will probably need a proper back end, which you’ll want to build with a proper web development framework, like Node.js + Express.js. Also, it’s worth pointing out that the mobile app development’s best days may very well be behind it. For starters, as much as people use mobile apps, nearly half of all developer jobs are web development. Compare this with a mere 8% of jobs that involve mobile app development. The occupations of 49,525 developers, based on responses to the 2016 Stack Overflow survey. The grand vision of “there’s an app for that” has not come to pass. Instead, most smartphone owners have stopped downloading new apps. Sure — they still use apps. Mostly Facebook, Google Maps, and handful of others. As such, much of the demand for mobile app developers is concentrated in a few large employers. The outlook for those mobile development jobs is hard to forecast. Many aspects of developing, maintaining, and distributing mobile apps are easier with JavaScript. So companies like Facebook and Google are investing heavily in better tools for building these using JavaScript. As of 2016, pretty much all development is web development. Everything touches that big platform that is “the web.” And the next wave of devices that you’ll talk to around your home, and cars that pick your kids up from school — they’ll all be piped together using the web, too. And that means JavaScript. Objection #4: Isn’t JavaScript a toy language that was written in 10 days? JavaScript has a quirky history. You will undoubtedly hear people crack jokes at its expense. Well people love to hate on C++, too. And like JavaScript, C++ has succeeded despite this hate, and now it’s pretty much everywhere as well. So if anybody ever gives you a hard time for learning JavaScript instead of elite-language-of-the-week, just remember the famous words of the guy who created C++: "There are only two kinds of programming languages: those people always bitch about and those nobody uses." — Bjarne Stroustrup

    starstarstarstarstar
  • 00:15:59

    Ep. 5 - How I got a second degree and earned 5 developer certifications in just one year, while working and raising two kids

    · The freeCodeCamp Podcast

    Beau talks about his year of incredible productivity, during which he a degree and certifications, and taught himself to code - balancing his studies against an active family life. Beau's original article: https://fcc.im/2j0vxBr Read by Beau: https://twitter.com/carnesbeau Learn to code for free at: https://www.freecodecamp.org Music: "Sounds of Wonder" by Vangough: https://fcc.im/2yQOq0q Transcript: “The standard pace is for chumps. The system is designed so anyone can keep up. If you’re more driven than ‘just anyone’ — you can do so much more than anyone expects. And this applies to ALL of life — not just school.” — Derek Sivers, founder of CD Baby Learning to code can be challenging — especially when you also have a job and a family with small kids. Despite those things, I decided that the standard pace was not for me. My goal in writing all this is not to brag — though I am extremely proud of these accomplishments. My goal is to convince you that the standard pace isn’t for you, either. I’ve done a lot in the past year. I earned two Oracle Java Certifications, two CompTia Certifications, and freeCodeCamp’s Front End Certification. Each of these take most people many months of preparation, but I did them all in three weeks each. And last but not least, I completed all the coursework necessary to earn a second Bachelor’s degree in software development from an accredited university, in less than six months. I did this all while working full-time, spending time regularly with my wife and two young kids, and volunteering in my community. One of the keys to accomplishing all of this was an amazing and supportive spouse. ???? But there were also some other things that helped. What’s Your Motivation? After being a K-12 teacher for five years, I realized I did not want to teach in a school the rest of my life. I loved the teaching part of teaching, but I hated the forcing-kids-to-do-things-they-don’t-want-to-do part of teaching. Classroom management in my urban school district was very stressful for me. I was also becoming disenchanted with the whole educational system. We seem to be preparing students for jobs that will no longer exist. I had always been interested in coding and even sometimes taught my students basic coding using Scratch and Code.org. I decided it was time to learn enough to do it full-time. Wanting a new job was great motivation. Everyday I spent at my teaching job was an incentive to keep pushing myself towards my goal. Research, research, research It’s important not to rush into learning. Not all schools or learning resources are equal, and the wrong choice can make a big difference in your ability to meet your goals. I tried to determine what learning method would work best for me and my family. While I know there are many ways to break into the tech industry, I decided on a somewhat traditional route: a Bachelor’s degree. I knew I had some classes already that would transfer into a new program. I looked into many school options but I decided on Western Governors University for the following reasons: It is all online so I would not have to take time from my family for transportation. You can work at your own pace, so I knew I could finish very quickly. As soon as you finish all the assignments and exams for one class, you can go immediately to the next class. The cost is low — about $3000 per six months. It is reputable, accredited, and has been recommended by President Obama and Bill Gates. The degree included industry recognized certifications. I knew those would add to the credibility of my education. Beating ambitions goals At first, my goal was to finish my entire Bachelor’s degree in one year. One month into the program, I decided to revise my goal and finish in six months. It was at this point that I did what helped me most in my goal to finish quickly: I made a schedule of the exact day I would finish each class so I could finish within 6 months. I scheduled between 1 and 3 weeks for each class, depending on class requirements. I also made plans at that time about how I would finish each class very quickly. It was very helpful to have many subgoals throughout the learning process to make sure I stayed on track.   Section of actual spreadsheet I used to plan for classes. Ambitious goals are important. These provided me additional motivation to push myself. A study by the Journal of Consumer Research showed that ambitious goals make people happier. I ended up meeting or surpassing all my self-imposed deadlines and that definitely made me happy! Detailed schedule I created a detailed weekly schedule to help me spend a lot of time learning without neglecting my family and other responsibilities. I scheduled in family time, volunteering time, time with friends, and even a weekly date night!   The schedule I created at the beginning of my degree. I have an even more detailed schedule now. A detailed schedule helped me make sure that my life stayed balanced. However, there is one thing I did not put on my schedule: television. I watched only 3 episodes of television the entire time I worked on my degree. I had such a tight schedule to keep so I could meet my goals so I did not have time for TV. Also, any time spent watching television meant less time with my family. Since graduating, I have continued to limit television so I can focus on coding. It was important for me to give things up in order to accomplish my goals. Ignore the haters! Every student at Western Governors University is assigned a mentor. Students have weekly calls with their mentors to help keep them on track. Whenever I shared my goals with my mentor she tried to encourage me to be a little more reasonable. Well, instead of being more reasonable I decided to set more ridiculous goals. I know she had good intentions but I decided to ignore her warnings and stopped sharing my goals with her. I have found that it is sometimes helpful to not share goals with certain people if they are not going to be encouraging. Maximizing time Besides my scheduled time to learn software development, I also found ways to fit in even more studying. For instance, I used most of my lunch breaks to study. Also, I often carried notes in my pocket that I could review whenever I had a free moment. Another thing I did (and still do) was to take days off my teaching job to work on my classes or programming projects. While completing my degree, I planned my days off to line up in my schedule when I knew I had harder classes to pass. I try to be constantly reevaluating my schedule and how I spend my time so I can have greater effectiveness. I used to code a lot after my kids went to bed. However, I noticed that by the end of the day, my brain just did not work as well. I switched up my sleep schedule so I now go to bed around 9pm and wake up at 4am to code (and create training videos). This may sound a little crazy but it has greatly increased my productivity. Learn what others do I spent a lot of time on the Reddit page for my college and various forums reading about what others did that helped them with their classes. For the industry certifications, there were even more resources available to help. This allowed me to better plan the quickest way to finish. There is almost always someone out there who has gone before you, and it’s important to identify them and learn from them. Learning from others was also very helpful while going through the freeCodeCamp curriculum. Experienced people in the community are always willing to help or offer suggestions in their forums and community chat rooms. Just ship it!   Shipping means to send out a completed product. There were many times when I wondered if I needed to put in more time working on projects or studying. Then I would realize that I didn’t have time if I wanted to meet my self-imposed deadlines. My deadlines forced me to act before I felt completely ready, and this definitely paid off. I’ve found that it’s more important to get projects out there than to make them perfect. If you try to make sure everything is just right, you may never finish. When in doubt, just ship it! The 80/20 Rule   The 80/20 rule states that for many events, roughly 80% of the effects come from 20% of the causes. When learning software development, this means that about 20% of the learning content will contain about 80% of what you will actually use. You can save a lot of time if you just focus on the top 20%. For my degree, I only read between 20–30% of the required content. According to the 80/20 rule, this was enough to understand over 80% of the subject matter. The trick is determining which 20% to focus on. I would often ask myself, “If I were designing the exam, would I include this material?” Really, when learning anything, you should ask yourself if it is part of the 20% of learning content that will give you 80% of value. This relates to the idea of just-in-time information. It’s usually not beneficial to learn something that you don’t plan to use in the near future, especially when your memory is as bad as mine. ???? When working on projects I try to learn what I will need just for that project. Employers often care more about projects you’ve created than how you learned to code. Keeping this fact in mind will help you decide how to best use your time. Keeping things moving forward I didn’t take any time off from learning once my degree was finished. I realized the importance of projects, so I went straight into freeCodeCamp and started creating personal projects to build up my portfolio. I was able to continue to apply all of the strategies that I used while completing my Bachelor’s degree. I also continued to use these strategies when I decided to start creating JavaScript training videos. Now I’m posting JavaScript training videos almost every day on the freeCodeCamp YouTube channel. If you’re interested in the specific things I did for each class to finish my WGU degree quickly, you can check out this blog post. I hope some of the strategies I used can also be helpful to you, even if your life is as busy as mine. Remember: the standard pace is for chumps. You can do better!

    starstarstarstarstar
  • 00:11:02

    Ep. 4 - Things I Wish Someone Had Told Me When I was Learning How to Code

    · The freeCodeCamp Podcast

    Cecily Carver, a developer at Google, recounts her coding journey and the many lessons she learned along the way. Read by Ava. Cecily's article: https://fcc.im/2A5kphQ Read by Ava: https://twitter.com/avasond Learn to code for free at: https://www.freecodecamp.org Music: "Sounds of Wonder" by Vangough: https://fcc.im/2yQOq0q   Transcript: Before you learn to code, think about what you want to code Knowing how to code is mostly about building things, and the path is a lot clearer when you have a sense of the end goal. If your goal is “learn to code,” without a clear idea of the kinds of programs you will write and how they will make your life better, you will probably find it a frustrating exercise. I’m a little ashamed to admit that part of my motivation for studying computer science was that I wanted to prove I was smart, and I wanted to be able to get Smart Person jobs. I also liked thinking about math and theory (this bookblew my mind at an impressionable age) and the program was a good fit. It wasn’t enough to sustain me for long, though, until I found ways to connect technology to the things I really loved, like music and literature. So, what do you want to code? Websites? Games? iPhone apps? A startup that makes you rich? Interactive art? Do you want to be able to impress your boss or automate a tedious task so you can spend more time looking at otter pictures? Perhaps you simply want to be more employable, add a buzzword to your resume, or fulfill the requirements of your educational program. All of these are worthy goals. Make sure you know which one is yours, and study accordingly. There’s nothing mystical about it Coding is a skill like any other. Like language learning, there’s grammar and vocabulary to acquire. Like math, there are processes to work through specific types of problems. Like all kinds of craftsmanship and art-making, there are techniques and tools and best practices that people have developed over time, specialized to different tasks, that you’re free to use or modify or discard. This guy (a very smart guy! Whose other writings I enjoy and frequently agree with!) posits that there is a bright line between people with the True Mind of a Programmer and everyone else, who are lacking the intellectual capacity needed to succeed in the field. That bright line consists, according to him, of pointers and recursion (there are primers here and here for the curious). I learned about pointers and recursion in school, and when I understood them, it was a delightful jolt to my brain — the kind of intellectual pleasure that made me want to study computer science in the first place. But, outside of classroom exercises, the number of times I’ve had to be familiar with either concept to get things done has been relatively small. And when helping others learn, over and over again, I’ve watched people complete interesting and rewarding projects without knowing anything about either one. There’s no point in being intimidated or wondering if you’re Smart Enough. Sure, the more complex and esoteric your task, the higher the level of mastery you will need to complete it. But this is true in absolutely every other field. Unless you’re planning to make your living entirely by your code, chances are you don’t have to be a recursion-understanding genius to make the thing you want to make. It never works the first time And probably won’t the second or third time When you first start learning to code, you’ll very quickly run up against this particular experience: you think you’ve set up everything the way you’re supposed to, you’ve checked and re-checked it, and it still. doesn’t. work. You don’t have a clue where to begin trying to fix it, and the error message (if you’re lucky enough to have one at all) might as well say “fuck you.” You might be tempted to give up at this point, thinking that you’ll never figure it out, that you’re not cut out for this. I had that feeling the first time I tried to write a program in C++, ran it, and got only the words “segmentation fault” for my trouble. But this experience is so common for programmers of all skill levels that it says absolutely nothing about your intelligence, tech-savviness, or suitability for the coding life. It will happen to you as a beginner, but it will also happen to you as an experienced programmer. The main difference will be in how you respond to it. I’ve found that a big difference between new coders and experienced coders is faith: faith that things are going wrong for a logical and discoverable reason, faith that problems are fixable, faith that there is a way to accomplish the goal. The path from “not working” to “working” might not be obvious, but with patience you can usually find it. Someone will always tell you you’re doing it wrong Braces should go on the next line. Braces should go on the same line. Use tabs to indent. But tabs are evil. You should use stored procedures, but actually you shouldn’t use them. You should always comment your code. But good code doesn’t need comments. There are almost always many different approaches to a particular problem, with no single “right way.” A lot of programmers get very good at advocating for their preferred way, but that doesn’t mean it’s the One True Path. Going head-to-head with people telling me I was Wrong, and trying to figure out if they were right, was one of the more stressful aspects of my early career. If you’re coding in a team with other people, someone will almost certainly take issue with something that you’re doing. Sometimes they’ll be absolutely correct, and it’s always worth investigating to see whether you are, in fact, Doing It Wrong. But sometimes they will be full of shit, or re-enacting an ancient and meaningless dispute where it would be best to just follow a style guide and forget about it. On the other hand, if you’re the kind of person who enjoys ancient but meaningless disputes (grammar nerds, I’m looking at you), you’ve come to the right place. Someone will always tell you you’re not a real coder HTML isn’t real coding. If you don’t use vi, you’re not really serious. Real programmers know C. Real coders don’t do Windows. Some people will never be able to learn it. You shouldn’t learn to code. You’re not a computer programmer (but I am). “Coding” means a lot of different things to a lot of different people, and it looks different now from how it used to. And, funnily enough, the tools and packages and frameworks that make it faster and easier for newcomers or even trained developers to build things are most likely to be tarred with the “not for REAL coders” brush. (See: “Return of the Real Programmer”) Behind all this is the fear that if “anyone” can call themselves a programmer, the title will become meaningless. But I think that this gatekeeping is destructive. Use the tools that make it easiest to build the things you want to build. If that means your game was made in Stencyl or GameMaker rather than written from scratch, that’s fine. If your first foray into coding is HTML or Excel macros, that’s fine. Work with something you feel you can stick with. As you get more comfortable, you’ll naturally start to find those tools limiting rather than helpful and look for more powerful ones. But most of the time, few people will ever even look at your code or even ask what you used — It’s what you make with it that counts. Worrying about “geek cred” will slowly kill you See above. I used to worry a lot, especially in school, about whether I was identifying myself as “not a real geek” (and therefore less worthy of inclusion in tech communities) through my clothing, my presentation, my choice of reading material and even my software customization choices. It was a terrible waste of energy and I became a lot more functional after I made the decision to let it all go. You need to internalize this: your ability to get good at coding has nothing to do with how well you fit into the various geek subcultures. This goes double if you know deep down that you’ll never quite fit. The energy you spend proving yourself should be going into making things instead. And, if you’re an indisputable geek with cred leaking from your eye sockets, keep this in mind for when you’re evaluating someone else’s cred level. It may not mean what you think it does. Sticking with it is more important than the method There’s no shortage of articles about the “right” or “best” way to learn how to code, and there are lots of potential approaches. You can learn the concepts from a book or by completing interactive exercises or by debugging things that others have written. And, of course, there are lots of languages you might choose as your first to learn, with advocates for each. A common complaint with “teach yourself to code” programs and workshops is that you’ll breeze happily through the beginner material and then hit a steep curve where things get more difficult very quickly. You know how to print some lines of text on a page but have no idea where to start working on a “real,” useful project. You might feel like you were just following directions without really understanding, and blame the learning materials. When you get to this stage, most of the tutorials and online resources available to you are much less useful because they assume you’re already an experienced and comfortable programmer. The difficulty is further compounded by the fact that “you don’t know what you don’t know.” Even trying to figure out what to learn next is a puzzle in itself. You’ll hit this wall no matter what “learn to code” program you follow, and the only way to get past it is to persevere. This means you keep trying new things, learning more information, and figuring out, piece by piece, how to build your project. You’re a lot more likely to find success in the end if you have a clear idea of why you’re learning to code in the first place. If you keep putting bricks on top of each other, it might take a long time but eventually you’ll have a wall. This is where that faith I mentioned earlier comes in handy. If you believe that with time and patience you can figure the whole coding thing out, in time you almost certainly will.  

    starstarstarstarstar
  • 00:16:42

    Ep. 3 - How I Went From Selling Food in the Street to Working as a Developer at Companies Like Apple Part 3 - First Week on the Job

    · The freeCodeCamp Podcast

    We conclude the tale of Alvaro Videla, who learned to code, got a job as a developer, and is now facing his first week on the job in Montevideo, Uruguay. He eventually went on to get jobs at Apple and other tech companies, but this is where he got his start.   Article by Alvaro Videla: https://fcc.im/2zJX3gN Read by Quincy Larson: https://twitter.com/freecodecamp Learn to code for free at: https://www.freecodecamp.org Music: "Sounds of Wonder" by Vangough: https://fcc.im/2yQOq0q   Transcript:  The Technical Interview The programmer who was interviewing me explained how things would go, that I was going to walk right into their offices, get my own desk, and program at one of their computers, with everybody else just doing their jobs, since “that’s how it’s going to be if you join us.” I thought that was pretty cool already. And just like he said, once I got into the office, everybody said hello and continued doing their jobs. Even though I wasn’t close to getting the job, I was already starting to feel like a part of something. The test consisted of building a website to list books for an imaginary library. It seemed simple enough: connect to a database, fetch a list of books, and display them on a webpage, with the buttons for the usual actions for adding books, deleting them, and updating their information. “I can do that,” I thought. While I was focusing on the test, behind me were programmers who were splitting their time between working on their tasks and playing with tennis balls in a very particular way: they were throwing them at each other, with a lot of force, up to the point where one shot hit the reset button of one of the computers and one guy lost what he was doing on his editor. “That’s a strange way to work, but it’s kinda cool,” I thought. I had expected a more formal working environment, but was pleasantly surprised at how relaxed the environment was. Meanwhile, halfway through my implementation, I got stuck. I couldn’t get my code to print the list of books, and nothing was showing up on the screen. “How do I get out of this one?” I wondered. I tried to debug it by adding print statements here and there, but that didn’t work, and I had no idea what was going on. The clock was ticking away, and I was starting to get really desperate. “Come on,” I told myself. “I can’t miss this opportunity because of this problem. What do I do? Should I ask for help? What if this disqualifies me instantly?” I thought about it some more. “I guess they help each other during work,” I reasoned. “OK, whatever, I’m going to ask for help.” I called the interviewer over and talked him through my problem, trying to explain everything I had tried so far, so he wouldn’t think I was cheating him into giving me an answer. Lucky for me, he also had no idea what was going on, so he told me it was fine and that I could leave it as it was. Unfortunately, I had used too much time on this debugging session so I didn’t have enough time to complete the second part of the test. Later on, I would value this lesson, since I saw that asking for help earlier would have saved a lot of time later — time that in this particular case was critical for me. And in the future, it could be critical for the company I would end up working for. I didn’t want to ask for extra time to try to solve the next problem, since I thought that wasn’t fair. I wanted to play by the rules, because I felt it was the right thing to do. As we’ll see later, I think that decision paid off. In the meantime, I had the second problem in front of me and I had to do something about it. I skimmed through it and saw that it was about parsing URLs out of some log files, so I gathered some courage. I put my most convincing face and told the guy that while I understood my time was up, the solution was a matter of just “splitting these lines by these characters, and then going with the URL splitting by using this and that character.” The guy nodded, and told me that indeed that was the solution. Then he said that the interview was over, and he asked me if I had any questions about the company or if there was something I wanted to add. Later on, I would value this lesson, since I saw that asking for help earlier would have saved a lot of time later “Well, now that you ask, yes,” I began. “I’ve been building this mapping application that I want to show you…” This was my opportunity to shine. I typed the website URL on the computer in front of us and started to pray to every god out there for it to load without problems. “Please, just this one time,” I thought. And as every element from the website finished loading, my anxiety decreased and my excitement increased. The creation I was most proud of was there, right in front of my eyes, and more importantly, in front of the eyes of the person who would decide if I had a job or not. I went through every feature of the app, explaining with passion the goal of the app, which features it had, and which features it lacked but that I knew I had to implement to have a clear business case. After a demo, he seemed impressed by Aleph Maps and gave me kudos for it, which made me happy I’d had the chance to run the demo for him and gone ahead with it. This showed me that all the demos I had run for various members of my family and for my friends had been worthwhile, since when it mattered, I was able to show that I could not only build things on my own, but also that I was good at explaining things. By then it was around 6 p.m. — time for them to call it a day, and for me to get back home. As we were leaving the building together, I asked the man who conducted my tests if he was attending university, because perhaps he knew my friend who had told me about this job opportunity. “Oh yeah, I know your friend, why didn’t you mention him before?” he asked. I didn’t answer, but the fact was that I didn’t want to bring it up and use it to my advantage during the interview. But in any case, it didn’t hurt afterward. He showed me how to get public transport back to the bus terminal and then we parted ways. Once on my own, I couldn’t believe I was done with the interview. Everything I had prepared for in the last two months had passed in what felt like the blink of an eye. All the stressing out about the little details — some that mattered, some that didn’t — was gone. Now it was me and Montevideo, and the streets crowded with people going back to their homes, and the cars, and the night falling over the city. I’d done it. Once I had processed all of it, the worst part came. It was time to take the bus and head home to wait for an answer, and waiting is something I’m really bad at. But that’s what it became. Waiting while staring at the ceiling of our room, wondering with my wife how our lives would change if I got the job. Waiting while looking at my books without knowing if I should have kept reading them or not. Waiting while making sure my phone had enough battery power so there would be no missed phone calls. Waiting, until at some point the wait was over, my phone rang, and again it was that number from Montevideo. “When can you start?” asked the voice on the other end. I was in. Yes, me. They wanted me: the guy who barely knew how to program, but let’s not worry about that now. “They want me,” I told myself, letting it sink in. “I’m in.” The whole gamble had paid off. Finally, after all those years of having jobs that paid nothing, working just because that’s what people do, even if having jobs meant forgetting about our dreams — finally, life was starting to turn around and smile on us, and from one day to the next, we could see a life that was worth living. I asked for one week to move to Montevideo, so they told me February 26 would be my starting date. “You will be working in PHP and JavaScript. You’re going to earn 15,000 pesos (500 USD) a month.” FIFTEEN THOUSAND PESOS! That was three times what my wife was making! “We are going to be rich!” I thought. I was going to be able to buy as much Coca-Cola as I wanted! We could probably even manage to save $100 per month and buy a house someday. We couldn’t believe what was happening to us. Finally, life was starting to turn around and smile on us, and from one day to the next, we could see a life that was worth living I spent that week prepping in JavaScript and trying to find a place to stay in Montevideo. A friend hooked me up with his apartment, since he was going to move out after Easter. The rent was good for us, so we decided that in about a month my wife would move to Montevideo and join us. The “apartment” was just one room, plus a kitchen and a small bathroom, and you could only fit two beds and a dining table in there. For a short while, it would be three of us living in that room, but honestly, that didn’t matter to us. I would be starting a new and exciting job, and we would have a place to live. Mission accomplished. First Week at Work My first day at work began with a nice twist: the person who conducted the interview was also my new manager. He brought me to office kitchen, we sat down at the table, and he started explaining what the company was doing, what the business model was, and so on. He then proceeded to lay down on a piece of paper depicting what the backend architecture was like, how things worked, what the server was doing, where the database was located, and many other details. I have to be honest: it was hard to follow. I recall hearing the term “production” a couple of times too. “This is our production setup,” “Here’s the production database,” and so on. I had no idea what this production thing he kept talking about was! Later, I learned that production referred to all the infrastructure, including code, that was facing clients and producing income for the company. We went through a couple of questions and answers here and there, and then came to what was, for me, the most significant part of that day. He looked at me and told me, honest and straight to the point: “We know that you’re not a good programmer, that you are just starting at this, and that you have no experience, so before you’re even able to commit one line of code to our codebase, we need you to study this book,” he said as he handed me a copy of PHP Objects, Patterns, and Practice by Matt Zandstra. “You have to know it by next week.” As straightforward it was, this was some of the most solid, sincere, and helpful feedback I’ve ever received as a programmer. To this day, I thank him for being forthright with me. During my career, I’ve learned how difficult it is to come by a manager who will give you this kind of feedback — feedback that’s useful for understanding your own shortcomings, but at the same time puts you on the right track in order to overcome them. Then he told me: “We know you are inexperienced, but during the interview you showed yourself as a person with a great attitude. That’s why we hired you.” I was speechless. I wondered what I’d done to deserve such an opportunity. Even more, I knew I had to prove I was worth it, so I set myself a goal of mastering the design patterns book as quickly as possible. First, I couldn’t disappoint my new boss who had taken a chance on me, and second, I finally had an opportunity in the big leagues, at the job I’d worked so hard for. It was time to shine. “We know you are inexperienced, but during the interview you showed yourself as a person with a great attitude. That’s why we hired you.” Fired After One Week on the Job During my first week, I studied that book like my life depended on it, because in a way, it did. I tried to learn as many of those design patterns as possible, practicing every example, and I tried to absorb as much knowledge as possible. By the end of the week, I wanted my manager to come to me and tell me, “Now you’re ready to start programming with us.” But as with every tale, this story needed a twist. That Thursday, some people from the company came and called me to another room to deliver some news: the company was conducting layoffs, and I was among the people being let go. “Nothing personal,” they said. “Business isn’t going too well, and we need to downsize, so we’re letting go of people who just joined the company. We hope you understand.” That day, I was one of around 50 employees who lost their jobs. I’m not sure I can accurately describe what I felt at that moment. “Why does life has to be like this?” I wondered, feeling somewhat discouraged and helpless. “What do I do now?” I asked to use the phone and called my wife. “Please don’t worry, but I have some bad news…” I began. I tried hard not to lose my composure, but meanwhile, the whole world was coming apart below my feet. All around me were employees coming in from other rooms and bidding farewell to all the people who were just fired, which only made me feel worse. Even so, I tried to convince myself that I shouldn’t despair. I had gotten this far, so it was simply a matter of applying to another job somewhere else. While I was saying goodbye to my short-lived colleagues, one of them tipped me off about some companies I should apply for, so I took note. From an internet cafe, I sent out job applications to the companies my brand new former colleague gave me, and when I was done, I headed back home. I tried to convince myself that I shouldn’t despair. I had gotten this far, so it was simply a matter of applying to another job somewhere else. “What a depressing day,” I thought. I entered the apartment and laid down on the bed, which for the record, was just a mattress on the floor. I remember the sky was gray, a perfect match for how I was feeling. I tried to nap, but my mind was lost, staring at the ceiling of that empty apartment and thinking about this new turn of events. “What if I hadn’t been fired?” “What did I do wrong?” I knew I had done nothing wrong. It was just bad luck, but it was hard to accept it. Suddenly my phone rang. “Is this Alvaro Videla? I’m calling from Intersys. We received your application and we want to have an interview with you. Is next Monday OK for you?” “OF COURSE THAT’S FINE WITH ME,” I thought, but instead I said, “Yes, that sounds great, I’ll be there.” As I hung up and placed my phone on the floor, I was in shock, unable to believe what had just happened. Montevideo was a city full of surprises. The next day I went down the street and asked the barber if he would give me a free haircut, since I had a job interview lined up but I had no money left. I still hadn’t received my salary from the week of work, so I needed a favor in exchange for being paid back the following week. Luckily, he was really happy to help me. I still remember his warm smile; he felt proud he was helping a neighbor get a job. While I was getting the haircut, he shared his story. I learned that in the early 2000s, he and his crew were the winners of some world hairdresser championship! I had no idea there were hairdresser championships. Don’t worry, I couldn’t believe him either back then. Either way, getting a haircut with a “world champion” was cool, but also meant that the service was expensive — $10 to be exact. It doesn’t seem like much, but keep in mind that in my hometown I could get a haircut for less than $2, and $10 could buy me at least five burgers and a soda. That said, it was quite an investment for my next job interview. I couldn’t complain though: a total stranger was doing me a favor when I needed it the most, and that raised my spirits. The next week came and I had my interview, which went great. The company I was just fired from was Live Interactive, after all, which happened to be well known in Montevideo due to being one of the biggest internet companies in the country. This meant that programmers coming from there were well regarded. Needless to say, I got the job. The salary wasn’t that great, but our plan of moving to the capital was still intact. Not bad for my first 10 days in Montevideo. Conclusion All in all, my plan had worked, and all my preparation and study paid off. I got my first job interview as a programmer and then passed it. I was hired and fired in the space of one week, but I didn’t give up and went on to secure a second job interview, landing a new position in my second week in Montevideo. But in order for this to happen, the first and most important step was being honest with myself. This allowed me to assess my skills to see what I was good at doing and where I had to improve. Being self aware helped me when I embarked upon the task of creating a program from scratch, because I was realistic about what I could do, but at the same time it forced me to do something about the areas where I was lacking. Additionally, dividing the project into actionable tasks helped me make progress and follow my idea through to completion. But it wasn’t just about skills; I also had to believe in myself, and that self confidence helped me whenever I faced a challenge that seemed like an insurmountable mountain. Meanwhile, humility always kept me in check, reminding me that what I had just climbed was but a little peak from among the many I had yet to climb. Finally, my family and friends offered help and support, and whenever I felt defeated, they kept me focused and reminded me why I was on my journey and what the destination was. In the end, because I persisted, I had become hirable, and now it was time to become an actual programmer.  

    starstarstarstarstar
  • 00:08:47

    Ep. 2 - How I Went From Selling Food in the Street to Working as a Developer at Companies Like Apple Part 2 - The Interview

    · The freeCodeCamp Podcast

    We continue the story of Alvaro Videla, as travels to Montevideo, Uruguay for his first developer job interview.  In this episode, Quincy tells the story of Alvaro Videla, who was living in poverty in Uruguay when he decided he wanted to learn to code. He had limited access to books and the internet. But he eventually got a job at Apple and other tech companies.   Article by Alvaro Videla: https://fcc.im/2AMqmfM Read by Quincy Larson: https://twitter.com/ossia Learn to code for free at: https://www.freecodecamp.org Music: "Sounds of Wonder" by Vangough: https://fcc.im/2yQOq0q   Transcript: Getting the Job During December 2006 and January 2007, I worked hard to get my maps application up and running. While building it, I wanted to learn as many programming notions as possible, trying to cram all the knowledge that would get me ready for the job interview into my head. Out of all the concepts I could learn, I identified the main ones that I thought would be relevant for getting the job. This narrowing of focus is a very important step toward achieving goals, since we don’t want to be all over the place, trying to grasp a bit of every subject but then failing to reach deepness on any of them. For my situation, I understood that I had to learn about object-oriented programming, since that was one of the most important programming techniques in use. On the technological side, I had identified PHP as the key programming language that would land me a job, while learning Flash programming would be the skill that would differentiate me from other candidates. How did I know that? It was a bit of hunch informed by what I was seeing mentioned on the web, along with what the computer magazines were writing about. Even back then, before I had the job, I knew it was very important to learn to understand and analyze the market I wanted to break into, and finding the right websites and publications is a very important step toward this. This is because these resources often have information that points to the ideas, trends, and technologies that we should focus on. Once my app was done and I felt I was ready for the interview, it was time to build my resume. However, I had no idea what should go on a tech resume and what should be left out. I listed things like MS Word and MS Excel as some of my skills, together with Adobe Illustrator and some InDesign. Why not, right? Wrong. Just thinking about that first resume makes me blush. If nothing else, what was clear about it was the message it was signaling: this person is a complete noob. The problem is that as someone trying to break into a new field and start a career, it was difficult to have something to write down on my resume that made me look competent. I had no idea what to include, so I listed everything. Today, if someone presented themselves for a backend developer position listing MS Word as a skill, I’m quite sure that person would be rejected straight away. Even worse, I think I would be the one rejecting a resume like that. But of course, hindsight is 20/20. Once my resume was complete and I got a cell phone number I could be reached at, I applied for the position of PHP programmer at Live Interactive. You’d better believe I read and reread every input box on that online form as I went over a mental checklist. “Did I spell my name correctly? Did I type the right phone number? Let’s double check the email. I don’t want to miss this opportunity because I wrote the wrong address.” I was all nerves, but at some point, I had to hit that send button. Click. Done. Exhalation. “I’ve done it. I’ve applied for my first job.” Once my app was done and I felt I was ready for the interview, it was time to build my resume. However, I had no idea what should go on a tech resume and what should be left out. After I submitted my application, I lingered at the internet cafe, browsing the web for random stuff. To my surprise, about half an hour later, my cellphone started to ring. “I don’t know this number,” I thought. The area code told me it was from Montevideo, but it was so quick, it couldn’t be them. Or could it? It took me a couple of seconds to understand that, yes, in fact, they were calling me! Can you imagine that? I honestly didn’t know what to do. “Should I take the call?” I wondered. “I’m probably not ready for this!” I quickly tried to get ahold of myself and walked outside to answer. “Hi, we’re calling from Live Interactive about your job application. Is this Alvaro Videla?” said the voice on the other end. Do you see what happened right there? I couldn’t believe it! I was being contacted by the company where I had just applied for a job. “Yes, it’s me,” I replied. The caller turned out to be the HR manager getting in touch, trying to set up an interview with me. She asked me when would it be a good time for me, so I told her that I needed a week, since “I have to arrange things here.” This wasn’t necessarily the case, as I could’ve just boarded the next bus and traveled there straightaway, but I wanted to prepare — to be 100 percent ready for it and not botch my only opportunity. I hung up at the end of that phone call having secured a job interview. Now it was time to get myself together and prepare for that interview. I had no doubt this was my once-in-a-lifetime opportunity and I couldn’t waste it. But first, I had to share my excitement with my mother and my wife: I needed to talk about what had happened with someone to help process my emotions. On one hand, all my hard work was starting to pay off, which felt great. But on the other hand, life had allowed me to see a tiny glimpse of a better future. Making that future a reality now rested entirely on my shoulders, but it was too much of a responsibility for me to handle alone. I spent the entire next week preparing for the interview, from reading and rereading the books I had, to trying to guess what kind of clothes I should wear for the interview. I had never worked as a programmer, and as such, I had no idea how the programmer culture worked and what kind of behavior would be expected from me. I didn’t have anyone to ask about this either, so at some point I decided to stop worrying too much about the appearance side and tried to focus on the technical aspect of the process, hoping my skills would speak for themselves. I had no doubt this was my once-in-a-lifetime opportunity and I couldn’t waste it, but first, I had to share my excitement with my mother and my wife: I needed to talk about what had happened with someone to help process my emotions. Unexpected obstacles The time passed quickly, and before I knew it, I was sitting on a two-hour-long bus trip, heading to Montevideo. I had the PHP Bible in my backpack and enough money to buy a burger and pay for the ticket from the bus terminal to the company’s offices in downtown Montevideo. I didn’t want to arrive late, so I was around the area an hour in advance, trying my best to fight off a nervous breakdown. I had to find something to kill time and occupy my worried mind, so I walked to a nearby square, found a bench, and sat down to keep studying. I couldn’t believe that all my struggles over the previous months would be decided in about an hour. “Did I prepare the best I could? That time I didn’t want to study that part of the book so I could go outside, was it worth it?” I wondered. Then I came to my senses. “Stop it,” I told myself. “It’s time to focus on the book in front of me right now, since there’s no reason for worrying about could haves.” Soon, it was time to head up for the interview. If this was a Tarantino film, my character would probably be called Mr. Blue: dark blue jeans, blue shirt, and dark blue hoodie. I got to the reception area and was welcomed by the HR manager, who I’d spoken to on the phone the week before. She asked me to sit and wait and offered me a glass of water. I took the offer and immediately started doubting myself. “Is this the right thing to do?” I wondered. “Am I being polite or impolite?” Anxiety was taking over. Meanwhile, people were walking around, going from one office to another. “Are any of them my interviewer?” I asked myself, studying each person who walked by. One man walked up to the HR manager and started talking. “Ah, it must be him,” I thought. But it wasn’t. After more of this wondering, the HR manager called my name and took me into a big conference room. She handed me a pile of paper and told me this was the first part of the interview: a psychological test with more than 100 behavioral and situational questions. What. Is. This? Nowhere in the PHP Bible did it mention that people needed to pass psychological tests to become a programmer! But I tried the best I could, second guessing the intention of every question. Of course, I had no idea if the answers I was choosing were correct, but I hoped they would bring me one step closer to getting the job I wanted. Once I was done, I returned the papers with my answers and then was asked to take a seat again and wait for the next stage. Soon the HR manager introduced me to someone who was going to conduct the programming interview. “Now or never,” I thought. “Now or never.” At that moment, I felt that all the pressure was on me, that I couldn’t let down my wife, my mom, my family. “If I don’t get this job, let it be known that it wasn’t because I got blocked mid interview, and didn’t know what to do,” I thought. “If I don’t pass the next stage, it’d better be because they didn’t want me, and not because I lacked the knowledge or preparation.”  

    starstarstarstarstar
  • 00:16:56

    Ep. 1 - How I went from Selling Food in the Street to Working as a Developer at Companies Like Apple Part 1 - Learning to Code

    · The freeCodeCamp Podcast

    In this episode, Quincy tells the story of Alvaro Videla, who was living in poverty in Uruguay when he decided he wanted to learn to code. He had limited access to books and the internet. But he eventually got a job at Apple and other tech companies.   Article by Alvaro Videla: https://fcc.im/2fRSzwM Read by Quincy Larson: https://twitter.com/ossia Learn to code for free at: https://www.freecodecamp.org Music: "Sounds of Wonder" by Vangough: https://fcc.im/2yQOq0q Transcript: At the end of 2006, I arrived at a crossroads in my life. My hopes of becoming a secondary school linguistics teacher had vanished in an instant, as several factors had come together and made it impossible for me to continue with my studies. Back in my hometown of Durazno, Uruguay, my wife was working long hours for a meager $160 (USD) a month. Yes, that’s $1,920 a year. We had sacrificed our time together so I could become a teacher and get a better job because we were dreaming of a better future. The problem with dreams is they tend to vanish when you wake up, and life’s alarm clock had just gone off. Because my career trajectory had suddenly strayed off course, I moved back to my hometown to figure out my next steps. Needless to say, I was depressed at the way things were, and our living situation only made things worse. It was good to be back with my wife, but the reasons for it were stressful. Additionally, we were sharing a house with my wife’s aunt, so our privacy was restricted to our bedroom, and we always felt like we were overstaying our welcome. As a way to bring in extra income, we tried to sell homemade pasta on the streets. I would go door-to-door collecting orders for the weekend. “Hello, do you want to order ravioli to eat this Sunday?” I’d ask person after person. “Yes, they’re homemade. Just give us a time and we’ll deliver them.” Then, after people ordered them, we spent our entire weekends making 2,000 ravioli only to end up with 500 pesos in our pockets, which comes about $20, not counting expenses. The whole situation was disheartening, and it made us feel hopeless. My wife would work hard all week, then come home only to spend her weekends helping me prepare the ravioli. She couldn’t even have one day of the weekend for herself. She begged me to stop selling ravioli, even if that meant we would end up with less money to pay our bills. Eventually I agreed, but it meant I had to try to find a job — and finding a job wasn’t so easy in our rural hometown. Anxiety and desperation were starting to set in. One night, I was talking with a friend who was studying computer engineering at the university in Montevideo. He told me about the various job opportunities one could find in the capital city, with salaries that were the stuff of dreams for someone living in the countryside. “There’s this big company in Montevideo, Live Interactive,” he told me. “They’re always looking for programmers; maybe you could try to get a job there. They pay really well.” The salary he mentioned was around three times what we were making at the time, and I couldn’t help but imagine all the things we could do with that much money. We wouldn’t need to worry anymore about putting food on the table. We could finally pay for our own internet connection, get proper clothes and shoes, and even have our own washing machine! Not only that, but I already had experience with computers. I always liked working with them, mostly because they appealed to my knack for problem solving. Programming reminded me of having to crack a code or find the solution to a difficult puzzle — but in addition to being challenging, it was fun. What’s more is that I saw programming as a career with a lot of potential for growth. But there was one small problem: to work as a computer programmer, one usually needs to know how to program computers. Me? I could install Linux on my own, but that was probably the extent of it. How do you land a job as a computer programmer when you have almost no programming experience and you lack a university degree to prove your knowledge? How do you learn to program without internet access at home, without mentors to connect with, and without access to programming books? That was my problem back in 2006, and this is the story of how I tackled it. The Early Days I’ve been dabbling with computers since I was a teenager — most of the time when visiting a friend who had a PC. While we often used the computer to play games, I wasn’t interested in playing that much. Why? Back when I started secondary school, a friend’s father let us use his ZX Spectrum computer. He had good stack of cassettes with plenty of games for it, and of course, we could play all we wanted, but one day he showed me something that blew my mind: people could make their own games by programming the computer! He showed me some tricks in BASIC, like how you could generate random numbers using the RAND function. I was amazed. At that point, I realized computers were more than a glorified Nintendo with a keyboard: you could actually tell them to do things for you — cool things, like drawing lines using trigonometric functions and then painting them by applying random colors! You could even make music with them by passing different frequencies to BEEP. In fact, once I brought the Spectrum to my house and spent an entire afternoon playing different kinds of beep sounds on my TV — I’m sure my mom loved it. How do you land a job as a computer programmer when you have almost no programming experience and you lack a university degree to prove your knowledge? Later on, during my teenage years, I continued spending time with friends who had their own computers, and naturally we played games on them. Meanwhile, with my more tech-savvy friends, I learned a few operating system tricks — mostly MS-DOS. Every once in awhile, we would try some BASIC programming by copying, character by character, the code snippets that appeared in old computer magazines. To us, they seemed like magic spells or technological incantations. One thing we really liked was trying to edit the text messages a game would show for different situations. We thought we were such hackers! By the early 2000s, I managed to convince my grandfather to buy me a computer: a Pentium MMX with 32MB of RAM! What a machine! I installed Linux on it for the first time, using a SUSE CD that came for free with an Argentinean computer magazine. I spent quite a lot of time on that computer: trying different Linux distributions, getting familiarized with the command line, and so on, but never really doing any programming. When I look back to those days, I can’t understand why I wasn’t learning C programming — or any kind of programming for that matter. A friend even offered me the bible of C programming by Kernighan and Ritchie, so not having access to a manual wasn’t an excuse. But for some reason, after reading a few examples, it didn’t spark any interest in me, as I didn’t understand how what it covered would be useful for me. In any case, playing with Linux was the only thing I was doing with computers back then. From that point on, I had several minor jobs, played in a rock ’n’ roll band, and tried to become a linguistics teacher, all while getting married and moving all over the country together with my wife. Fast forward to November 2006 and I found myself in need of somehow becoming hirable by a software company. I had to become a credible computer programmer. Time for Some Goals If I wanted to get hired, the first thing to do was evaluate my skillset as a programmer. I had to be honest with myself so I could know where to focus my efforts. At the time, I knew a bit of ActionScript for Flash MX and the very basics of PHP programming. Earlier that year, I had started learning those technologies as a hobby. I’d also started a pet project to learn programming, thinking maybe it could become a secondary source of income. I came up with the idea of making a digital map of my hometown where you could drop pins that would point the user to the location of businesses, shops, and interesting locations. I would then charge those businesses money in exchange for appearing in my online map application. Of course I know what you’re thinking. “That’s just Google Maps,” you say. Yes, but back in 2006, the only thing Google Maps knew about my hometown was that it was crossed by a big national highway. Given that, my map seemed like a good idea. Also, I figured this project would be the perfect way to showcase my skills to a prospective employer. I had a clear goal of what I wanted to build; I just had to get down to work and make it happen. So at the end of 2006, I set myself a deadline: come February 2007, I had to have a working concept of the map application. This had to include a Flash frontend, served by a PHP backend, using MySQL for data persistence. The technologies I’ve just mentioned might not seem too relevant today, but the point here is that I had to nail down every detail of my plan so I would know which problems to tackle first, since time was ticking: every day that went by was another day where my wife was overloaded, working overtime to get food on our table. Additionally, to even have a shot at getting a programming job, I had to show potential employers that I could program in those particular technologies, because that was part of the job description. Naturally, I had nothing related to these skills on my resume, so I had to build up my knowledge from scratch, and my app would serve as the showcase of my programming expertise. The plan was to land an interview at the company my friend had mentioned before, and hopefully, with the combination of my skills and my app, I would end up getting a job there. Even then, I knew the importance of setting clear goals for yourself in order to achieve what you want. Learning project: a Map Application The map application I created was called Aleph Maps — a reference to Jorge Luis Borges’ 1949 story, “El Aleph,” about a place in the universe where everything — past, present, and future — is contained. Not ambitious at all, right? And to bring the idea into existence, I would have to learn how to program web apps. Having no internet at home is a real challenge for a future web developer. When I started, ADSL broadband adoption was almost nonexistent, limited only to businesses and maybe wealthy households. For the average family, connecting to the internet meant dialing in on a modem connection and paying high prices for a slow internet experience. I couldn’t afford that, which meant I had to go and bother friends every time I needed to access some online tutorial that explained how to program in PHP. So even though I had a computer and the will to learn, I still didn’t have easy or regular access to the information on how to do it. But I was determined to get that job, and I knew that even these setbacks wouldn’t deter me from learning PHP. When you don’t have time to waste, you don’t have time to feel desperate; instead, you have to focus on finding solutions. Meanwhile, due to the lack of internet access around town, cyber cafes started popping up in the city, charging around half a dollar for one hour of surfing. This struck me as a better solution than constantly bothering my friends. But this also meant finding an extra 50 cents and a couple of floppy disks in order to get to a cyber cafe, find the information I wanted, copy it onto one of those diskettes, and get it home onto my computer. More often than not, data got corrupted in the process of extracting it from the floppy disks. Imagine how angry and frustrated I was: I had made a trip to a cyber cafe and wasted 50 cents for nothing. Half a dollar! This might not sound like much, but at that time where we lived, you could buy a burger or a bottle of beer for a dollar. For us, it was a lot of money: it meant our daily bottle of milk or a loaf of bread. During those days, my routine consisted of trying to solve problem A to get to point B. Sometimes the tasks were rather easy and I felt like I was making quick progress. Other days, it felt like I was going nowhere. For example, say I had to implement a feature like “insert new data into the database.” This meant writing down all the obstacles I had to solve to achieve that — from how to write an SQL INSERT statement to how to execute it using PHP — and then integrating everything into the app. Each of these tasks was an item on my daily “shopping list” for when I went to the internet cafe. I would take a couple of floppy disks with me, and then I would google for blog posts, tutorials, and guides that would help me solve the items on my list. Once that was complete, it was time to save them on my diskettes and head home, all the while hoping the data had successfully saved and would be easily accessed on my computer. Because of the uncertainty involved, the bicycle trip back would be fueled by the worst anxiety ever. “What if the data isn’t there at all?” I wondered. “What if the bike shakes too much and the data gets corrupted? I really don’t have another dollar to spare until tomorrow, so this better work when I get home.” I was determined to get that job, and I knew that even these setbacks wouldn’t deter me from learning PHP. When you don’t have time to waste, you don’t have time to feel desperate; instead, you have to focus on finding solutions. Suffice to say, this wasn’t practical at all. Once I was back home, I’d use the information I’d brought back to help me accomplish the task in progress, but once it was complete, I lacked the knowledge to perform the next step. This means I was left sitting at home, thinking about a problem, and waiting until the next day, when I could squeeze another 50 cents out of our budget to go to the cafe and repeat this routine. Though at the time it seemed like my only option, eventually I had to admit to myself that it was time for a new strategy. I needed something that contained most of the information on how to write a web application with PHP and Flash MX, with guides explaining how to perform the most trivial of tasks, all in one single place. Not the internet, but books! It seems like such a no-brainer, but for someone in my situation, the kinds of books I needed weren’t necessarily in reach. The problem is that when you’re part of a marginalized sector of society, accessing books isn’t so easy. The closest thing to a programming book you could find at the public library would be some outdated manual on how to repair a computer — maybe some dusty MS-DOS guide, or perhaps a BASIC or Delphi book if you got lucky — but not much more. Well, at least one could buy books, right? Not really. In most towns in Uruguay’s countryside, technical books are usually absent from the bookstore shelves, and my town was no exception. Add to the problem the fact that most of the tech books — particularly those talking about cutting-edge technology — are written in English, and you can just forget about the local bookstore. In the end, this left me with only one option: Amazon. But it wasn’t that easy either. To buy books on Amazon, you need a little piece of plastic called a credit card, but to get access to a credit card, you need a good credit history — which for most people is not a problem. In my case, though, I was living in a completely different world: everything we bought was paid for in cash. We didn’t have the money or the economical certainty to enter into a credit plan. For us, it worked like this: if we wanted to buy something more expensive than our monthly income, we either saved month after month until we got enough money to buy what we wanted, or we asked some family member to buy the product for us and worked to pay them back later. And even if we’d had the option of buying books on Amazon, we hadn’t factored in the fact that shipping alone from the United States to Uruguay was nearly the cost of the book, not to mention it would take a month for it to arrive. In my case, though, I was living in a completely different world: everything we bought was paid for in cash. We didn’t have the money or the economical certainty to enter into a credit plan Sometimes the solution to these kinds of problems is closer to home than we think. Eventually, we ended up resorting to asking for help from family. My wife has an aunt who had been living in the US for quite a while, so we figured it was worth a shot to ask and see if she would buy me a couple of programming books. So on one of my internet excursions, I wrote an email to her explaining my situation, hit send, and basically crossed my fingers and prayed to every deity out there that she would help us. After a couple of days, I had a new email in my inbox. It was her answer, straight to the point: “Tell me which books you need and I’ll order them from Amazon.” After doing some research, I ended up asking for the Flash MX Bible and the PHP 5 and MySQL Bible. Those two books proved incredibly helpful in the weeks to come. They were both so thorough that I was able to make steady progress without needing to constantly visit the internet cafe in search of missing information. I could finally make headway on understanding what I needed to know to build my maps application. And finally, with access to the information I needed, it was time to sit down in front of my computer and get to work.   At the end of 2006, I arrived at a crossroads in my life. My hopes of becoming a secondary school linguistics teacher had vanished in an instant, as several factors had come together and made it impossible for me to continue with my studies. Back in my hometown of Durazno, Uruguay, my wife was working long hours for a meager $160 (USD) a month. Yes, that’s $1,920 a year. We had sacrificed our time together so I could become a teacher and get a better job because we were dreaming of a better future. The problem with dreams is they tend to vanish when you wake up, and life’s alarm clock had just gone off. Because my career trajectory had suddenly strayed off course, I moved back to my hometown to figure out my next steps. Needless to say, I was depressed at the way things were, and our living situation only made things worse. It was good to be back with my wife, but the reasons for it were stressful. Additionally, we were sharing a house with my wife’s aunt, so our privacy was restricted to our bedroom, and we always felt like we were overstaying our welcome. As a way to bring in extra income, we tried to sell homemade pasta on the streets. I would go door-to-door collecting orders for the weekend. “Hello, do you want to order ravioli to eat this Sunday?” I’d ask person after person. “Yes, they’re homemade. Just give us a time and we’ll deliver them.” Then, after people ordered them, we spent our entire weekends making 2,000 ravioli only to end up with 500 pesos in our pockets, which comes about $20, not counting expenses. The whole situation was disheartening, and it made us feel hopeless. My wife would work hard all week, then come home only to spend her weekends helping me prepare the ravioli. She couldn’t even have one day of the weekend for herself. She begged me to stop selling ravioli, even if that meant we would end up with less money to pay our bills. Eventually I agreed, but it meant I had to try to find a job — and finding a job wasn’t so easy in our rural hometown. Anxiety and desperation were starting to set in. One night, I was talking with a friend who was studying computer engineering at the university in Montevideo. He told me about the various job opportunities one could find in the capital city, with salaries that were the stuff of dreams for someone living in the countryside. “There’s this big company in Montevideo, Live Interactive,” he told me. “They’re always looking for programmers; maybe you could try to get a job there. They pay really well.” The salary he mentioned was around three times what we were making at the time, and I couldn’t help but imagine all the things we could do with that much money. We wouldn’t need to worry anymore about putting food on the table. We could finally pay for our own internet connection, get proper clothes and shoes, and even have our own washing machine! Not only that, but I already had experience with computers. I always liked working with them, mostly because they appealed to my knack for problem solving. Programming reminded me of having to crack a code or find the solution to a difficult puzzle — but in addition to being challenging, it was fun. What’s more is that I saw programming as a career with a lot of potential for growth. But there was one small problem: to work as a computer programmer, one usually needs to know how to program computers. Me? I could install Linux on my own, but that was probably the extent of it. How do you land a job as a computer programmer when you have almost no programming experience and you lack a university degree to prove your knowledge? How do you learn to program without internet access at home, without mentors to connect with, and without access to programming books? That was my problem back in 2006, and this is the story of how I tackled it. The Early Days I’ve been dabbling with computers since I was a teenager — most of the time when visiting a friend who had a PC. While we often used the computer to play games, I wasn’t interested in playing that much. Why? Back when I started secondary school, a friend’s father let us use his ZX Spectrum computer. He had good stack of cassettes with plenty of games for it, and of course, we could play all we wanted, but one day he showed me something that blew my mind: people could make their own games by programming the computer! He showed me some tricks in BASIC, like how you could generate random numbers using the RAND function. I was amazed. At that point, I realized computers were more than a glorified Nintendo with a keyboard: you could actually tell them to do things for you — cool things, like drawing lines using trigonometric functions and then painting them by applying random colors! You could even make music with them by passing different frequencies to BEEP. In fact, once I brought the Spectrum to my house and spent an entire afternoon playing different kinds of beep sounds on my TV — I’m sure my mom loved it. How do you land a job as a computer programmer when you have almost no programming experience and you lack a university degree to prove your knowledge? Later on, during my teenage years, I continued spending time with friends who had their own computers, and naturally we played games on them. Meanwhile, with my more tech-savvy friends, I learned a few operating system tricks — mostly MS-DOS. Every once in awhile, we would try some BASIC programming by copying, character by character, the code snippets that appeared in old computer magazines. To us, they seemed like magic spells or technological incantations. One thing we really liked was trying to edit the text messages a game would show for different situations. We thought we were such hackers! By the early 2000s, I managed to convince my grandfather to buy me a computer: a Pentium MMX with 32MB of RAM! What a machine! I installed Linux on it for the first time, using a SUSE CD that came for free with an Argentinean computer magazine. I spent quite a lot of time on that computer: trying different Linux distributions, getting familiarized with the command line, and so on, but never really doing any programming. When I look back to those days, I can’t understand why I wasn’t learning C programming — or any kind of programming for that matter. A friend even offered me the bible of C programming by Kernighan and Ritchie, so not having access to a manual wasn’t an excuse. But for some reason, after reading a few examples, it didn’t spark any interest in me, as I didn’t understand how what it covered would be useful for me. In any case, playing with Linux was the only thing I was doing with computers back then. From that point on, I had several minor jobs, played in a rock ’n’ roll band, and tried to become a linguistics teacher, all while getting married and moving all over the country together with my wife. Fast forward to November 2006 and I found myself in need of somehow becoming hirable by a software company. I had to become a credible computer programmer. Time for Some Goals If I wanted to get hired, the first thing to do was evaluate my skillset as a programmer. I had to be honest with myself so I could know where to focus my efforts. At the time, I knew a bit of ActionScript for Flash MX and the very basics of PHP programming. Earlier that year, I had started learning those technologies as a hobby. I’d also started a pet project to learn programming, thinking maybe it could become a secondary source of income. I came up with the idea of making a digital map of my hometown where you could drop pins that would point the user to the location of businesses, shops, and interesting locations. I would then charge those businesses money in exchange for appearing in my online map application. Of course I know what you’re thinking. “That’s just Google Maps,” you say. Yes, but back in 2006, the only thing Google Maps knew about my hometown was that it was crossed by a big national highway. Given that, my map seemed like a good idea. Also, I figured this project would be the perfect way to showcase my skills to a prospective employer. I had a clear goal of what I wanted to build; I just had to get down to work and make it happen. So at the end of 2006, I set myself a deadline: come February 2007, I had to have a working concept of the map application. This had to include a Flash frontend, served by a PHP backend, using MySQL for data persistence. The technologies I’ve just mentioned might not seem too relevant today, but the point here is that I had to nail down every detail of my plan so I would know which problems to tackle first, since time was ticking: every day that went by was another day where my wife was overloaded, working overtime to get food on our table. Additionally, to even have a shot at getting a programming job, I had to show potential employers that I could program in those particular technologies, because that was part of the job description. Naturally, I had nothing related to these skills on my resume, so I had to build up my knowledge from scratch, and my app would serve as the showcase of my programming expertise. The plan was to land an interview at the company my friend had mentioned before, and hopefully, with the combination of my skills and my app, I would end up getting a job there. Even then, I knew the importance of setting clear goals for yourself in order to achieve what you want. Learning project: a Map Application The map application I created was called Aleph Maps — a reference to Jorge Luis Borges’ 1949 story, “El Aleph,” about a place in the universe where everything — past, present, and future — is contained. Not ambitious at all, right? And to bring the idea into existence, I would have to learn how to program web apps. Having no internet at home is a real challenge for a future web developer. When I started, ADSL broadband adoption was almost nonexistent, limited only to businesses and maybe wealthy households. For the average family, connecting to the internet meant dialing in on a modem connection and paying high prices for a slow internet experience. I couldn’t afford that, which meant I had to go and bother friends every time I needed to access some online tutorial that explained how to program in PHP. So even though I had a computer and the will to learn, I still didn’t have easy or regular access to the information on how to do it. But I was determined to get that job, and I knew that even these setbacks wouldn’t deter me from learning PHP. When you don’t have time to waste, you don’t have time to feel desperate; instead, you have to focus on finding solutions. Meanwhile, due to the lack of internet access around town, cyber cafes started popping up in the city, charging around half a dollar for one hour of surfing. This struck me as a better solution than constantly bothering my friends. But this also meant finding an extra 50 cents and a couple of floppy disks in order to get to a cyber cafe, find the information I wanted, copy it onto one of those diskettes, and get it home onto my computer. More often than not, data got corrupted in the process of extracting it from the floppy disks. Imagine how angry and frustrated I was: I had made a trip to a cyber cafe and wasted 50 cents for nothing. Half a dollar! This might not sound like much, but at that time where we lived, you could buy a burger or a bottle of beer for a dollar. For us, it was a lot of money: it meant our daily bottle of milk or a loaf of bread. During those days, my routine consisted of trying to solve problem A to get to point B. Sometimes the tasks were rather easy and I felt like I was making quick progress. Other days, it felt like I was going nowhere. For example, say I had to implement a feature like “insert new data into the database.” This meant writing down all the obstacles I had to solve to achieve that — from how to write an SQL INSERT statement to how to execute it using PHP — and then integrating everything into the app. Each of these tasks was an item on my daily “shopping list” for when I went to the internet cafe. I would take a couple of floppy disks with me, and then I would google for blog posts, tutorials, and guides that would help me solve the items on my list. Once that was complete, it was time to save them on my diskettes and head home, all the while hoping the data had successfully saved and would be easily accessed on my computer. Because of the uncertainty involved, the bicycle trip back would be fueled by the worst anxiety ever. “What if the data isn’t there at all?” I wondered. “What if the bike shakes too much and the data gets corrupted? I really don’t have another dollar to spare until tomorrow, so this better work when I get home.” I was determined to get that job, and I knew that even these setbacks wouldn’t deter me from learning PHP. When you don’t have time to waste, you don’t have time to feel desperate; instead, you have to focus on finding solutions. Suffice to say, this wasn’t practical at all. Once I was back home, I’d use the information I’d brought back to help me accomplish the task in progress, but once it was complete, I lacked the knowledge to perform the next step. This means I was left sitting at home, thinking about a problem, and waiting until the next day, when I could squeeze another 50 cents out of our budget to go to the cafe and repeat this routine. Though at the time it seemed like my only option, eventually I had to admit to myself that it was time for a new strategy. I needed something that contained most of the information on how to write a web application with PHP and Flash MX, with guides explaining how to perform the most trivial of tasks, all in one single place. Not the internet, but books! It seems like such a no-brainer, but for someone in my situation, the kinds of books I needed weren’t necessarily in reach. The problem is that when you’re part of a marginalized sector of society, accessing books isn’t so easy. The closest thing to a programming book you could find at the public library would be some outdated manual on how to repair a computer — maybe some dusty MS-DOS guide, or perhaps a BASIC or Delphi book if you got lucky — but not much more. Well, at least one could buy books, right? Not really. In most towns in Uruguay’s countryside, technical books are usually absent from the bookstore shelves, and my town was no exception. Add to the problem the fact that most of the tech books — particularly those talking about cutting-edge technology — are written in English, and you can just forget about the local bookstore. In the end, this left me with only one option: Amazon. But it wasn’t that easy either. To buy books on Amazon, you need a little piece of plastic called a credit card, but to get access to a credit card, you need a good credit history — which for most people is not a problem. In my case, though, I was living in a completely different world: everything we bought was paid for in cash. We didn’t have the money or the economical certainty to enter into a credit plan. For us, it worked like this: if we wanted to buy something more expensive than our monthly income, we either saved month after month until we got enough money to buy what we wanted, or we asked some family member to buy the product for us and worked to pay them back later. And even if we’d had the option of buying books on Amazon, we hadn’t factored in the fact that shipping alone from the United States to Uruguay was nearly the cost of the book, not to mention it would take a month for it to arrive. In my case, though, I was living in a completely different world: everything we bought was paid for in cash. We didn’t have the money or the economical certainty to enter into a credit plan Sometimes the solution to these kinds of problems is closer to home than we think. Eventually, we ended up resorting to asking for help from family. My wife has an aunt who had been living in the US for quite a while, so we figured it was worth a shot to ask and see if she would buy me a couple of programming books. So on one of my internet excursions, I wrote an email to her explaining my situation, hit send, and basically crossed my fingers and prayed to every deity out there that she would help us. After a couple of days, I had a new email in my inbox. It was her answer, straight to the point: “Tell me which books you need and I’ll order them from Amazon.” After doing some research, I ended up asking for the Flash MX Bible and the PHP 5 and MySQL Bible. Those two books proved incredibly helpful in the weeks to come. They were both so thorough that I was able to make steady progress without needing to constantly visit the internet cafe in search of missing information. I could finally make headway on understanding what I needed to know to build my maps application. And finally, with access to the information I needed, it was time to sit down in front of my computer and get to work.

    starstarstarstarstar