Today roughly eight million Americans work remotely full-time. And among the most commonly held jobs include many that leverage skills honed on freeCodeCamp. These jobs include web design, software engineering, product management, and writing.

Firms are embracing the shift to hiring and empowering remote staff for many reasons. Some of the reasons frequently referenced include increased workforce productivity and access to new pools of talent.

One reason that is cited less frequently (but is seemingly as important) is that shifting to a remote labor force will significantly reduce a firm’s costs. Ultimately these cost savings will benefit shareholders.

I want to explain the cost structure that firms, and in particular technology companies, must manage. I absorbed these lessons by studying the financial documents and annual reports of companies that perhaps you aspire to work for or whose products you may use and enjoy.

I want to share these lessons with you.

First, some relevant financial context. All firms have essentially three large costs that they must manage: Property Plant and Equipment (PP&E), operating expenses, and Selling, General and Administrative (SG&A) expenses.

When a firm maintains an office (or famous large headquarters in the case of Google, Facebook, and Apple), it obviously must pay for the furniture, land, buildings, and machinery that help power its business. These fixed assets are expected to be used for at least one year and are classified as PP&E on a firm’s balance sheet.

Operating expenses are a second category of cost that firms must manage. These costs include the utilities, insurance, taxes, and payroll that a firm pays to remain open.

Lastly, a company needs to budget for SG&A expenses which are the sum of all direct or indirect selling expenses and general administrative expenses a firm accrues.

With this context in mind, we can view remote work - and the advocacy of remote work by CEOs - through a new financial light.

By placing workers in home offices (or remote co-working spaces) a firm can succeed in achieving two things in a single action: the firm can reduce its fixed and variable costs and move part of its cost structure from its balance sheet to that of its staff.

In short, companies won’t need to invest as much in buildings and equipment (i.e. lower CAPEX), which will lead directly to higher cash flow. This will lead to higher expected growth and higher stock prices over time.

Additionally, companies can decrease salaries and decrease corporate administrative costs, (i.e. lower SG&A), which will lead to higher net income to equity holders.

Facebook provides evidence of this trend.

Recently Facebook Founder and CEO Mark Zuckerberg said that as much as 50% of Facebook’s workforce could be working remotely in the next five to ten years.

What data supports this policy?

Firstly, look at the explosion of Facebook’s SG&A costs in the last three years.

• In 2019 Facebook's annual SG&A increased 80% from 2018.
• In 2018 Facebook's annual SG&A increased 56% from 2017.
• In 2017 Facebook's annual SG&A increased 32% from 2016.

Next, look at Facebook’s increase in operating expenses.

• Facebook's annual operating expenses for 2019 increased 51.05% from 2018.
• Facebook's annual operating expenses for 2018 increased 51.22% from 2017.
• Facebook's annual operating expenses for 2017 increased 34% from 2016.

Lastly, note that even as Facebook’s revenue has increased, the rate of growth is slowing.

• Facebook's annual revenue for 2019 increased by 27% from 2018.
• Facebook's annual revenue for 2018 increased 37% from 2017.
• Facebook's annual revenue for 2017 increased 47% from 2016.

Facebook’s SG&A and operating expenses are increasing faster than Facebook’s rate of revenue.

To increase profitability, Facebook will need to find ways to decrease its costs. It has a few obvious buckets to target and expanding its remote workforce can reduce PP&E, SG&A, and other operating costs in one fell swoop.

Let me explain how.

Remote workers will reduce Facebook’s dependency on furniture, land, and buildings. The decreased utilization of these fixed assets will lower Facebook's PP&E.

Secondly, remote workers will decrease Facebook’s payroll. Why? Because Facebook can pay lower wages to workers outside of dense regions where the majority of their workers are today. Hiring talent outside of metropolitan areas will enable Facebook to pay wages indexed to local costs.

A software engineer in New Hampshire or Montana will cost Facebook less to employ than that same engineer located in New York City or the Bay Area. Zuckerberg explained that Facebook “will adjust salaries to your location...that means if you live in a location where the cost of living is dramatically lower, or the cost of labor is lower, then salaries do tend to be somewhat lower in those places.”

The reduction of costs can be extrapolated to SG&A. Rent, utilities, and office supplies are three examples where Facebook can move costs from its balance sheet to that of its staff who will likely be expected, among other things, to heat and cool their home work environments, make their own coffee and food, or clean their home workspaces - at their own expense.

This shift in cost structure will likely yield disproportionate benefits to shareholders because the earnings of a firm increase when, holding all else constant, costs decrease.

What do these changes mean for you? I have a few ideas.

Remote workers would be wise to ask for and negotiate new benefits packages. Subsidized wifi or utilities seem like reasonable things to ask for if you no longer have an office to work from. Discounted home office products - a chair, desk, light, keyboard, monitor - should be included as non-taxed items when joining in a remote role. Access to virtual mentoring or mental health tools can be requested as core perks to ensure that you are growing and healthy while performing remote work.

As remote work becomes more prevalent - for full time remote workers and employees who blend their time between workplaces - new paradigms of work will arise. With this fundamental shift in the labor markets, firms will have a unique opportunity to reduce costs. How and where their expenses are cut will dictate the rate at which earnings can increase.

It seems to reason that shareholders will benefit from enhanced profitability coming from these changes. But remote engineers, designers, product managers, and sales professionals can benefit too. By asking for new and specific perks that empower remote work, these workers might see more of the upside derived from this shift in the labor market.

This is for those of you out there who are about to start your job search and who may be worried that you can’t land a top-tier tech job without a Stanford CS degree. Someone told you that you’re not good enough to get a job at Microsoft or Facebook.

But I’m here to tell you that you can get that job. Here’s how I landed my dream job at Twitter.

Read more about my courses here to learn how I prepared.

You can read about my experiences after a year at Twitter here.

What this article covers:

• My background
• How I landed interviews with top tech companies in the world: Facebook Google, Amazon, LinkedIn, Microsoft, Twitter, Pinterest, Snapchat, and others.
• How I landed multiple offers as a full-time software engineer
• Lessons from my interview experience
• Subscribe here for more article updates from me

If you prefer to watch my story instead, I made a video here:

Background

I did not graduate from an Ivy league school. I went to a community college in Idaho for two years, and then finished my CS degree at a small Catholic university.

I started learning computer science in my junior year of college, because it sounded fun to me at the time. The only thing resembling a computer I had growing up was a Chinese copycat of the Nintendo SNES. Even then, it would break every time I put a cartridge in it.

To support myself through college, I took multiple part-time jobs like cleaning floors and working stand-up concessions.

When I graduated, I didn’t have a job lined up. I applied to as many big tech companies as I could, and had the good fortune of landing a few phone interviews.

At this point, I didn’t have a single notion of what a technical screen would be like, much less how to prepare for it. I headed into these interviews thinking that the interviewer would ask me what a linked list or binary tree was.

I didn’t pass any of those interviews.

Moving forward

I didn’t delve too much into whether I was good. I knew that I could learn things fast. I just needed an opportunity.

As the saying goes, cast your net far and wide. So that’s what I did.

What I did next is something I’m particularly proud of. I wrote a simple Python script that scraped job listings on Craigslist with titles containing keywords from a list, and collected the emails in a spreadsheet. For the actual war story, you can read the article here.

It wasn’t the smartest solution, but people who post on Craigslist are surprisingly accurate with their titles.

Craigslist, however, didn’t like people scraping their website. To work around this, I ran my script through a VPN, and had a timer that would pause the script every few minutes or so. It wasn’t perfect, but it worked well enough.

In the end I collected about 500 emails from around San Francisco, Portland, Spokane, and Seattle. I filtered the results by how specific and recent they were, and kept improving it by adding more and more features.

As it turned out, there were a few bots in the market already that crawled Craigslist and sent out automated emails. These were mostly offshore companies that were looking to pitch their company to the US market.

One of my workarounds was that I crafted emails that used keywords from their listings in the title of my emails. I then added more details using the body of the postings to make it seem more personable. I did a quick A/B test, and the replies I received had increased quite a bit from around 2–3% to 10%.

Out of the 500 or so emails, I received about 50 replies, and landed phone screens with a small percentage of those. I stopped at 500 because I was short on time and needed to finalize a job as soon as possible. I was optimizing for results rather than reach at that point.

As luck would have it, I finally landed a job at a startup in Seattle as a junior software engineer. The startup was located in Kirkland at the time, so I had to take a 45-min bus ride to make it in time for the interview.

I then stayed there for the next 3.5 years, where I learned a great deal of stuff like Amazon AWS, EC2, DynamoDB, SQS, and Docker. I grew a lot during this period. I learned how to write modular, maintainable code. I learned how to reason about software design. And I learned how to handle people problems.

I was working next to a group of smart people who held jobs at Microsoft, Amazon, and LinkedIn, and I tried to be the “sponge” in the group. I absorbed anything and everything they threw at me. I believe this made a huge impact in my career.

Startup Days

During my stint at the startup, I worked almost exclusively on backend development, with some dev-ops in between. I started out writing some functions to add/modify a feature that were mostly small in scope. But it was a great opportunity to understand the codebase and get some code reviews.

A year into it, I started owning parts of the codebase, and then I was tasked with turning a set of features into a service. That was the start of the SOA phase for the startup. We started turning various components of the site into services, and that’s how I started learning more about RESTful services, authentication, AWS services, pub-sub, distributed systems and so forth.

The interesting part here is that I didn’t learn about any of these through books or formal education. Rather, I needed to get that set of features done and there were the bottlenecks.

So I thought, let’s go solve it!

There were many times where I was stuck in analysis paralysis — a state where I over-analyzed scenarios and ended up not able to make progress.

Those trying times were the greatest learning opportunities. I started to learn feature scoping, negotiations, monitoring, alerting, and documentation. Each step of the process revealed more things I needed to learn. I grew the most during these 2–3 years, both as an individual and software engineer.

How I prepared for my interviews

After suffering through my first job search, I told myself that I must be prepared in future interviews.

I started preparing for interviews by charting out an overview of what I was good at, bad at, and where I could improve. I broke it down into three categories: data structures, algorithms, and system design.

Having worked in PHP for most of my professional career, and C++ in college, I wanted to try something a little simpler and less verbose for interviewing.

For this reason, I picked Python. It is a great language to learn, easy to pick up, supports many data structures out of the box, and can be written quickly on the whiteboard. I learned Python by going through YouTube tutorials like these, and also reading their documentation. I prefer Python 2.x, but you can go for either 2.x or 3.

Also, another reason why I picked Python is that it’s highly readable and easy to write on a whiteboard. Here’s a trivial comparison between C++ and Python.

A C++ program to sort in descending order:

#include <bits/stdc++.h>
using namespace std; 
int main() {   
    int arr[] = {1,10,0,4,5};
    int n = size(arr)/sizeof(arr[0]);   
    sort(arr, arr + n, greater<int>());   
    for (int i = 0; i < n; i++) {       
        cout << arr[i] << " ";   
    }    
    return 0;
}

Compare that with Python’s version:

a = [1,2,4,5,1000]
a.sort(reverse=True)
print a

I’ve received feedback from interviewers to err on the side of brevity in an interview. In a 45-minute interview, you want to use most of your time solving the actual problem.

Pro tip: pick a language that’s less verbose so that you can write the code more quickly on the whiteboard.

Preparation mode

I spent about a week going through simple challenges on LeetCode, HackerRank, and Project Euler to familiarize myself with their interfaces, and to get used to writing code in Python.

The first week gave me insights into my competence level at certain programming languages. I spent another week going through some design challenges like “design X” and went as wide and deep as I could.

This was a lot of fun for me, because I often looked at iOS apps and tried to figure out how they did it. For example, how would you build Instagram from scratch? (I was asked this at Facebook.)

My background is in API designs and service-oriented architecture, so I took this opportunity to show how I would design my own version of Instagram. And because I have some iOS programming experience from my side-projects, I could talk a little bit about callbacks and push/long-polls here.

I started the conversation with some features I’d like to have on my own version of Instagram: likes, upload a photo, and a simple timeline. Feature scoping enabled me to build a very solid API because I know these scenarios well.

I then drew some pictures of a high-level design, of how the client would interact with the backend, and of how the backend would store the data.

I started small, and then added more components where needed and proactively sought where the bottlenecks were. I made educated guesses (read educated, not blind guesses) on what the requirements would be, and how each technology would fit in well. And also equally important, what technologies would not fit well.

For example, why would you use Cassandra over MySQL to store certain information (hint: scale, speed of development, schema reviews), why use OAuth over simple authentication, Redis vs Memcached for caching data, streaming vs batch processing, and so on.

There are many areas you can explore here, so typically a one-hour session is not enough. To do well on these questions, you have to read and learn about trade-offs. Pros and cons of technologies in the industry. For this, I recommend a site like HighScalability.

Take it like a typical brainstorming session with a coworker, so explore as widely and as deeply as you can.

It’s crucial to know that these design interviews are meant to explore how much you know and how well you know it, and it’s an opportunity for you to shine. I watched this YouTube video from an ex-Facebook engineer about how to solve design problems, and it gave me insights that helped me tremendously with my design interviews. My two main lessons from it: drive the design conversation, and show what you know.

I listed out my competency level for: data structures (linked list, hash map, binary tree, binary search tree, heap, array), algorithms (binary search, hashing, dynamic programming, sorting), and language-specific syntax and libraries (like sort, lambda for Python, appending, indexing).

I picked the area I was worst at, and started working on it: algorithms.

Algorithms have never been my forte. It’s been a while since my college days, and I didn’t spend much time doing binary search in my day-to-day career. I had an inkling of how each algorithm would perform, and in what scenarios to use them. But I wasn’t 100% comfortable with writing a binary search in under 10 mins. On a whiteboard. In front of an interviewer.

I also picked up a bunch of fine-point markers from Amazon, which work amazingly well. Perhaps it’s just me, but the fine-point markers in interviewing rooms usually don’t work at all. I’d usually scramble for 2–3 mins looking for a working pen, and that’s 2–3 mins you can’t afford to waste. Plus, fine-point markers allow you to write 5–8 more lines of code on a typical whiteboard vs. thicker ones. :)

Pro tip: Get your own set of fine-point markers.

I got a whiteboard from Costco for $50, some books from Amazon (listed in the tools I recommend section below), and started practicing. I made sure I ramped up on binary search, recursion, dynamic programming, BFS and DFS. A lot of interviewing questions revolved around recursion and binary search or some variations of it.

The best interviewing questions I’ve seen had many different solutions to them, and there’s an additional layer added on top as you progress through.

One Google question I had was related to file-system directories, and how to traverse them (hint: recursion). I solved that relatively quickly, and the interviewer asked how to identify a missing file in that directory. That was a little more difficult, but I got through it. And we then moved into how to rebuild the directory, how to serialize/deserialize it, and we spent a good chunk of time debating how file directories work underneath the hood. It was a very enjoyable session for me.

Interviewing at top-tier companies

It was a nerve-wracking experience, to say the least, and a real roller-coaster.

I allocated my time in the following manner: 20% resume, 20% research and 60% interview preparation.

I spent 20% of my time fixing up my resume, which hadn’t been updated in at least three years. I took a hard look at the stuff I’ve done in the past, and picked projects I handled end-to-end, regardless of complexity.

The reason for doing this is two-fold. Taking a project from start to completion demands discipline and leadership — two of the traits I’d like to be identified with.

Secondly, ownership of a project end-to-end means I can talk about each aspect of the project at length and in depth. This proved critical in helping me navigate my design round at Twitter, where they grilled me hard on not only the designs of my projects, but also the decisions behind them.

20% of my time was used for research. Research in this case meant doing due diligence on companies I was interested in and reaching out for referrals. Having referrals helps with return calls.

From my experience, I sent out 20 or so cold messages to startups and mid-stage companies, and only heard back from a handful. But, almost all the companies I was referred to by an existing employee sent me a message within a week. This is anecdotal, but there’s value to be had there.

I am not that sociable, and I didn’t know many people who’d be able to refer me to a company I was interested in. To solve that problem, I went on LinkedIn. They have a search functionality that I used to search for 1st and 2nd-level connections. 2nd-level connections are people who’re one hop away from your immediate circle. In other words, we have mutual friends who can vouch for my credibility.

LinkedIn search

This is incredibly important, because cold-calling someone for a job is very, very hard, especially in today’s market. People tend to err on the side of caution when it comes to cold-callers. Using LinkedIn was super helpful for my research phase.

Looking back at all the companies I interviewed at, here are my thoughts on each of them:

• Facebook/Google — very mechanical. The standard interviewing process, and I didn’t feel any personal connection to them.
• Pinterest — not the best interviewing experience, but a cool product and company.
• Microsoft — loved the team and especially the manager and her manager. Standard interviewing questions, but very personable. Close-second choice. Your mileage may vary, though — each team at Microsoft interviews differently.
• Amazon — standard interviewing process. About 50% of the people love it, the others don’t.
• Twitter — incredibly fun and personal. Loved the interviewing process, gave a lot of emphasis on the individual and what I’d done in the past.
• Snapchat — cool office in LA, great bunch of people who decided to jump on the startup bandwagon. Felt like things were shrouded under a cloud of secrecy.
• Lyft — near to where I live, nice office, standard interviewing process. No strong feelings about it.

Let’s talk about my favorite

In many ways, I’d say Twitter’s interviewing style was hard. But at the same time, it was more interesting and personable than other companies I’ve interviewed at.

Their interviewing process starts with an introductory phone call with an engineering manager. That’s followed up by one or two technical phone screens, depending on how you perform. If you do well, they’ll fly you out to the office you’re interviewing for, which was Seattle in my case. There are three 1-hour-and-15-minute rounds, each with two interviewers.

The first two technical phone screens are the standard, run-of-the-mill technical screens where you solve coding problems on a shared coding doc.

The onsite rounds, however, are much more conversational and feel much less intimidating. The interviewers will ask you in-depth questions about your past projects, and they’ll grill you on what you’ve done in the past. If you claim ownership of a project, you should expect some questions about it. You’re encouraged to use them for references and to bounce ideas off of.

I never felt any pressure to magically come up with a fully working solution, and it felt highly collaborative.

The others

In comparison, interviewing at Facebook and Google felt much more mechanical. They have one or two technical phone screens, and five to six onsite coding rounds. Each round involves some coding on a whiteboard, and you’re expected to come up with a near-perfect solution in a reasonable amount of time.

Facebook has two coding rounds, one design round, and one behavioral round.

I went through an additional shadow round at the end of the day, which didn’t count towards my overall score.

Google had five coding rounds, none of which focused on designs, and not a single interviewer asked about my previous projects. I don’t necessarily think this is bad. But I think it felt very mechanical and didn’t give much opportunity for the engineer to show what they’re capable of. Some people do well in these scenarios, much like some students do well in exams.

I did not enjoy my interview with Pinterest. I think the product itself is interesting, and their engineering team seems to be working on very cool technical problems. But I definitely had a negative experience during my interview there.

Pinterest has three coding rounds and one design round. Of those four rounds, the design round was most disappointing to me. Here’s why:

The interviewer came in late, and he spent a few minutes glancing over my resume before proceeding to draw some APIs on the board. He gave a short description of what he expected the API to do, and asked how I would solve it. We clarified the features of the API, and I started describing my solution using the whiteboard. About 5 minutes into it, I turned around and saw him taking a nap!

Not cool.

I gave the recruiter my feedback in a survey, and I didn’t hear back from them after that.

I won’t delve into specifics of the questions I was asked during all the interviews. Instead, I’ll share some of the insights and useful tips I learned from my preparation process.

What I learned:

• Be honest on your resume. Most companies will ask you questions about your resume, and they can tell if you made it up. It’s better to be able to know 100% about one project than to know 10% about 10 different projects.
• One-page resumes are recommended. This is especially true for tech companies, and it seems that the wisdom within the tech sphere is that you should reserve two pages and longer for post-doctoral work, or if you’ve done a lot of projects that you know and care deeply about. A friend of mine runs a company called Jobscan that scans resumes and makes specific, actionable improvements on them. They’re pretty awesome, so try them out :)
• Socialize and establish a network. There’s a lot of competition for software engineering jobs, and these top tech companies are filtering through thousands of resumes a day. Having a referral will help you get some eyes on your resume.
• Nail your pitch. Every company that’s interested in you wants to know why you’re interested in them. A bad answer: I just need a job right now to pay bills. A less-bad answer: I was browsing online and found you guys. Sounds like you’re working on interesting things. A good answer: I know you’re doing some interesting work in X to achieve Y. I’ve done some work in the past and here’s what I learned about A, B, C that might be related to X. I am passionate about Y because blah. (Don’t use this as a template. Instead, you should see the pattern here — do your research, use your background, and show the company why both of you would fit well together.)

Some more advice

Technical interviews are incredibly difficult, and sometimes it’s a hit-or-miss. The best opportunities, however, are reserved for those who are prepared.

• Prepare early, prepare well. Everyone knows that they should prepare for an interview, but most don’t know how to do it well. As with anything worth doing, it takes deliberate practice to do well at something. And deliberate practice means you need to have a system.
• Build a system to practice technical skills. I started by rating myself from 1–10 on how good I was, and worked on the ones I was worst at. I spent days on different types of questions until I fully mastered each concept. And I wrote notes daily on Evernote. I had a note that serves as a brain dump for all things programming. It is full of programming tips & tricks, common errors and misconceptions, frameworks for solving specific types of questions, and much more.

My notebook

• Keep a notebook of the things you’ve learned. I use both Evernote and OneNote to keep track of things. OneNote for technical stuff/code, because I like that I can easily format the note any way I like. I use Evernote for essays/thoughts. The image above shows a note I keep on architecture and system designs.

Evernote for thoughts/tips

• Jot everything down, even if you don’t think you’ll use it. I tend to forget very easily, so anything that I learn I write it down, including shell commands. I read technical blogs from time-to-time, and if I find anything interesting I jot it down on Evernote right away. I’ll revise it every week or month and reorganize accordingly. This has helped me tremendously over my career.
• Get mock interviews. This was definitely very valuable and I highly advise it. I had mock interviews with friends and tried to practice as much as I could. If you can’t find friends to practice with, then I recommend Refdash, which is an Interview-As-A-Service. They have a group of interviewers who work at big tech companies like Google, Facebook, and Microsoft. These interviewers will assess you on your coding and design skills. The best part of it is they’ll give you a score at the end of it with specific actionable items on how to improve.
• It’s OK to fail. I failed multiple interviews during this whole process. Sometimes you just have a bad day. It’s not the end of the world if you fail. Companies are biased towards saying no because it’s a lower risk for them. A false positive costs more than a false negative in the long run. The first few rejections definitely stung the most. I failed multiple phone screens when I first started interviewing, and my confidence level sunk. I had doubts in my mind about my abilities and started fearing that my skills weren’t relevant in today’s job market. However, I gave myself a tip: If you fail 10 times, then try 10 times more. All you need is one success. That reassurance gave me a lot of confidence to keep pushing through and when my first offer came through, the other offers came much more easily.

It took me about 2 months of deliberate practice and preparation for my interviews. I spent about 20 hours/week, or 80 hours/month, learning and writing notes on top of a full time job.

To build up my resume, it took 3.5 years of focused, deliberate work. I intentionally picked things that were tough and icky so that I could learn more than anyone else. Even though I don’t have a brand name university or top-tier tech company on my resume, I made up for it with a clear, thorough understanding of the projects I worked on. And this was possible because I researched and wrote down notes of everything I learned, and have a system to review them.

Remember: the strong survives, the tough thrives.

TL;DR: Don’t give up, set yourself up for opportunities, practice a lot, and stay hopeful. Focus on the process, and take a disciplined, dedicated approach to the process.

Tools I Recommend

• Designing Data-Intensive Applications: Awesome book for learning about scaling distributed systems! Highly recommended.
• Elements of Programming Interviews: Great for solving coding problems.
• Cracking The Coding Interview: Great for covering foundational CS coding problems.
• Daily Coding Problem.com: This is a free-to-try website that offers free daily coding problems. You can sign up for interesting daily coding challenges, and you can pay for solutions if you want.
• Dropbox: I keep all my files, pictures, resume here. Easy access, installed once and available everywhere. Love it ❤️ (If you sign up thru this link, both of us will get free 500MB!
• CodeRunner: I love this Mac app! I used this multiple times to run ad-hoc Python scripts/functions and it just works amazingly well. ?
• Kafka the Guide: I used this book as a reference guide, and enjoyed it for the high-level description.

(I share more resources I personally have used and recommend on zhiachong.com, if you’re interested in learning more.)

Thanks for reading my story! You can find me on Twitter and LinkedIn. I would love to connect and talk more about tech, startups, travel :D

Credits:

Brandon O’brien, my mentor and good friend, for proof-reading and providing valuable feedback on how to improve this article.

YK Sugishita, an up-and-coming Youtube star who left his job at Google to pursue his dreams, for proof-reading and giving critical feedback.

It’s helpful to use social sign-ins with Ionic for your users who would rather not create and remember another username:password combination. Instead, you can allow users to sign in with accounts they already own. You don’t need to store hashed passwords to compare, you don’t have to handle sending sign up emails, and you don’t need to reset passwords. The user’s chosen provider will handle all of this for you.

Do you want just check out the code instead of following the post? Please give the repo a star in you find it helpful!

Some of this post will be very similar to the other tutorials on my page. If you have ionic and Node installed and have a project setup, you can jump to the code here .

To follow along with this tutorial, youll need both Node.js and Ionic installed.

To install ionic and cordova, which for the moment is needed for plugins, run the following in your terminal after installing Node:

npm install -g ionic cordova

If you get EACCES: permission denied, you may need to run the command with sudo.

Create an app with ionic start . For this, use a blank template as a starting point.

The code for Facebook sign-in will be put into a provider class which will be called by whichever page needs to use that sign-in method.

ionic g provider auth

Setup app with Firebase and get credentials

In order for Firebase to work with the Facebook platform, we will need to perform three steps:

— Setup a new App in the Facebook developer’s portal

— Setup Facebook sign-in on Firebase

— Implement the sign-in flow

Facebook Developer’s Portal

The Facebook Developers Portal is an interface to all of the developer tools and APIs available. It is what we’ll use to setup the sign-in API on Facebook’s side.

Choose a name and a contact email for your app. The contact email may be shown to users, so make sure it’s professional.

After this, the app will be created in facebook and we can add the plugin to our application!

There will be two plugins needed. The cordova plugin designed to work with Facebook natively, and a wrapper for it.

$ ionic plugin add cordova-plugin-facebook4 --variable APP_ID="123456789" --variable APP_NAME="myApplication"

You’ll need to replace the values or APP_ID and APP_NAME for your real credentials. You can find both of those inside your Facebook Developer’s Dashboard.

The other plugin will allow us to work with the first one, through TypeScript.

npm install --save @ionic-native/facebook

Now we have the plugin installed and wired up to the Facebook console.

There are two final steps for this: selecting which platforms we will use on the FB Developer Portal and importing in the app.module.

Selecting Platforms in FB portal

Our app is created, however we need to specify which apps can use our sign-in API. This is done by adding platforms with a bundle ID we specify.

To begin click Add Platform, select either Android or iOS. Both platforms will need to know the generated ID of your app when it is in deployment.

The ID value found at the top of your config.xml will be used for both the Google Play store package name and the BundleID.

Don’t forget to also import the plugin in your _app.module.ts_ and specify it as a provider for the project.

Setup Facebook sign-in on Firebase

Setting up the sign-in within Firebase will be the easiest task. Once the app is created on the FB developer’s portal, it will have an APPID and an APPSECRET. These two values are needed to link Firebase to our Facebook app.

Once these values are input, click enable and that’s it!

Implement the sign-in flow

After all of the configuration, we have made it to the fun part: coding the thing and testing it!

Provided you have been following, the two Facebook Ionic plugins are now installed and the app is setup in Firebase and FB Dev Portal.

Before we can use the plugin in our code, we must import it and bring it into scope with the constructor. After this we are free to use the plugin anywhere in this provider.

import { Facebook } from '@ionic-native/facebook';

@Injectable()

export class AuthProvider {

constructor(private googlePlus: GooglePlus, private facebook:Facebook) {

}

The code for the login itself will seem very familiar if you’ve seen the other posts. What we are doing here is using the native Facebook plugin to do a sign-in flow. If it’s succesful, take the provided authresponse and sign into Firebase.

This function can be called anywhere in the app by importing the auth provider. The intended way to use this will be that some page (such as home.ts) will have AuthProvider in scope. When the user clicks a FB login button, we will delegate the login to our AuthProvider.

Now when this function is called, a native Facebook UI will pop up asking for sign-in. Or if the user is already signed in it’ll just ask for OAuth permission — and thats it! We get a token back which we can use to make a credential, and this credential is then used to sign into Firebase.

facebookLogin(): Promise<any> {
    return this.facebook.login(['email'])
      .then( response => {
        const facebookCredential = firebase.auth.FacebookAuthProvider
          .credential(response.authResponse.accessToken);

        firebase.auth().signInWithCredential(facebookCredential)
          .then( success => { 
            console.log("Firebase success: " + JSON.stringify(success)); 
          });

      }).catch((error) => { console.log(error) });
  }

Conclusion

In this article, we have setup the Facebook sign-in API and worked through a cross platform solution for signing users into our Firebase with Facebook.

Same as the Google Sign-In, there was some confirguration needed (although not as much). Now the benefit is that our users can sign into any web apps we build with their existing Facebook accounts. If you followed the first article too, then the app now has Google and Facebook sign-in!

All the code for this tutorial (and all my other tutorials) can be found here. I am aiming to implement as many of the Firebase features as I can, and YES I am looking for contributors!

If you want access to the code, here again is a link to the repo :

Ryan-Gordon/Ionic-Firestarter
Ionic-Firestarter — Ionic Firestarter is a open source project showcasing different Firebase features implemented in…
github.com

Want some similar posts on Ionic ? Here is a couple other posts I’v done:

How to dynamically theme your Ionic application and make your users happy
Designing a sleek color scheme for your mobile application can be time consuming. Why not let the user choose their own…

Alternative Sign in Methods for Firebase with Ionic
In my other posts on Firebase sign ins, a focus has been put on Social providers. The main point of this emphasis is to…

In the summer after my 3rd year of university, I decided that I wanted to work at a top tech company such as Google or Bridgewater. There was problem, though. I didn’t go to a target school, my grades were just okay, and my work experience consisted of being a janitor and IT Tech support. I knew if I wanted to get a chance at these top companies, I would have to get creative.

The original post can be found on my blog.

This article details how I was able to get interviews at companies like Google, Facebook, Bridgewater, and others. If you think you have some sort of weakness or background that precludes you from getting a shot at these companies, hopefully you’ll see that you can get a chance at companies like this as well.

Note: I’ve also included a Google Slides summary of this article.

How I got interviews at Google, Facebook, and Bridgewater (Tech Version)
_How I got interviews at Google, Facebook, and Bridgewater (Tech Version) Advice for people who need experience to get…_docs.google.com

Here’s what we’ll cover:

Rethink the Old School Method

Make Something Useful or Interesting

Tell People About It

Reasons Why You Won’t Do It

Case Study: Tomiwa’s Story

Appendix: Sample Email

Ok, let’s get started.

Rethink the Old School Method

When applying for jobs, most of us do the exact same thing: apply to the same postings as everyone else on the career center portal, send in a résumé that is virtually identical to all the other résumés, and if we’re feeling extra diligent, maybe even write a “customized” cover letter (you know, swap the company names).

Then when we ask why we aren’t getting many responses, we are told it’s because we need to use more “action words” in the cover letter or change the font size on the résumé.

However, this doesn’t address the real underlying issue. Only relying on résumés and cover letters is ineffective, because outside of name dropping, the school you went to, or an impressive company you worked for, it’s really hard to prove why you deserve a chance.

So we end up just writing a bunch of corporate jargon and buzzwords that no one actually wants to read. Which is probably why most résumés are never actually seen by humans but by computers scanning for certain “keywords” or humans scanning for certain “buzzwords” ? .

These strategies may have worked in the past, but in this modern internet age, there is definitely a better way to do this.

Provide Tangible Proof of Your Merit

The best way to prove how deserving you are is to make something interesting or useful and share it on the internet. When I say make, people often think that, since I am a software engineer, I expect everyone to learn how to code or be a visual artist.

Not necessarily. Making something can go beyond coding and artsy stuff. A blog post or slide deck is a very underrated way of quickly showing someone how smart, hardworking, and generally deserving you are.

Here are a few more examples of things I have recommended that people do in the past.

Make Something Useful or Interesting

I Strongly recommend writing a blog post on the topic/field that you are interested in. Easy topics to start with are taking something you learned in class or online and writing it in your own words. You can also look at a case study/stock pitch on something that you’re interested in.

For example, here is a blog post I wrote when I learned about machine learning and here is a blog post from when I still thought I wanted to go into private equity (I still do, but not right now). Remember you’re not sending it to your university professor who is contractually obligated to read your 7,000 word essay. If it’s not well written, entertaining, or informative, it won’t get read (yours truly is still working on getting 2/3).

I recommend sites like Medium and Atila Blogs as an easy way to get started and share your blogs with the people you want to read it.

Don’t know what to write about? See this slide for more details

Now, for all you engineers and technical people: you probably already know the importance of having a Github account. But people may not have the time and cognitive load to read your source code. You should take the extra step of writing a short blog post explaining wat you built and how you built it. At the very least, you should have a well written README.md explaining how someone should read your code: see this slide for more information.

If you don’t enjoy writing, or you are a more visual communicator, you can also pretend that you are going to give a presentation on a topic you’re interested in and turn it into a slide deck. I personally really like Google Slides, but Slideshare seems to be really popular as well.

And lastly, if you are doing anything in the creative (fashion, music, arts) or lifestyle (fitness, cooking, travel) field, I recommend you get either a YouTube or Instagram account and put your portfolio there. I usually recommend starting with Instagram, because it’s less intimidating to put a 30 second clip or a few photos on Instagram than creating a YouTube channel.

Tell People About It

Now that you’ve built something interesting or useful, you want to tell people about it.

I think everyone should have a website where you can post all your content and give people links to see it. People often feel daunted by the idea of a website. Things like like WordPress (what I use) or Squarespace make it really easy. Blogging platforms like Medium are another easy way to start.

If starting a dedicated website seems like overkill, setting up a Medium or Atila page is probably a good idea.

The mistake most people make about posting things on the internet is that they think the goal is to get traffic or “go viral.” The goal when you first start is to actually just create content specifically for the targeted people you are trying to impress and think of what brings them the most value.

Another benefit of posting on the internet is serendipity. If you write something interesting, people are likely to randomly come across it and share it with friends. Then the magic of the internet does the rest.

Another challenge I had was that I don’t have an extensive network, so it was tricky getting access to people who could provide me with an opportunity. We have the internet now, so you can just follow these steps:

1. Make a list of all the companies you are interested in applying for and use LinkedIn to find people who are in your 1st-2nd connections that work at these companies.
2. Put their names, titles, companies, and emails into a spreadsheet

Draft a brief email that’s personalized to each person. Keep in mind and provide the following things (and check out the sample email at the end of this article):

1. Who you are and what you want from them (within the first two sentences). It should be brief, direct, and polite. The question of how direct to be is very situational, and if you are unsure, write an email draft and show various people who you think have good judgement and get their opinion
2. I used to be vague, but I realized that people are busy and they generally don’t want you to ask for a 15 minute “coffee chat” if what you really just want is an interview or a referral.
3. Include their name in the subject header
4. Share what you have done and why you deserve this opportunity.
5. Attach your resume and a link to your LinkedIn, website, blog, and so on.
6. Send the emails at about 6am in the recipient’s local time so they see it when they are going through their morning mail. There are many Gmail extensions for this. You are using Gmail, right?
7. You can send me any sample emails or content you have and I’d be happy to edit them for you.
8. Most people will not reply and some will only reply if you follow up with them. I recommend that every three days you send a follow up email, up to a maximum of 2–3 follow up emails (use those Gmail extensions to make it easier). The attached email also includes some sample follow ups to get you started.

Many of you probably already use LinkedIn for networking but I think Twitter is lowkey another very underrated way of networking. I actually got an interview at Coinbase by sliding in the dms on Twitter. Note that networking on Twitter if very different from LinkedIn. See this slide for more details. My twitter: @tomiwa1a

Reasons Why You Might Not Follow This Advice

I have given this advice enough times and I have been ignored enough times to know why people won’t try the things I suggest in this article. Here are a few of them:

I’m too busy

This is the most common response I get, and personally the most frustrating. There is no such thing as being too busy, only priorities. So you don’t think allocating time to do this is a priority for you. You see the immediate benefit of getting good grades. But you don’t see the immediate benefit of learning something that you’re not getting a grade or getting paid for, and you don’t see the benefit of sharing something online.

In my opinion, this is a big mistake. In the long term, personal development and developing your network will be the best investment you can make in yourself.

Posting on the Internet is bad. What if a potential employer doesn’t like what I post?

A lot of us have been scared by anecdotal stories of someone doing something dumb on social media and the backlash they faced. The reality is that for every one horror story, there are 10 times more stories of people posting something useful on the internet that opens more opportunities for them. We just don’t talk about them as much.

Only post something positive that you think will be interesting or helpful for someone and that you are willing to stand behind. There will be a small subset of the population that will always be upset regardless. Consider that their disapproval may be a blessing in disguise, because why would you even want to work with such a person? The vast majority of people who read what you post will find it useful, and you will have built up goodwill amongst that group of people. This will be a net positive for you.

I put skin in the game and only recommended advice that I have taken myself. Let me tell you my story.

Case Study: Tomiwa’s Story

After my 3rd year of university, I had previously worked in IT support and as a janitor for my last two summer “internships.” I really wanted to get an internship more related to software engineering, so I set my sights on Google, Facebook, and the rest.

All I needed was one chance to prove that I was a capable engineer that gets things done, but how could I prove I deserved that chance? I didn’t go to an Ivy league school, my “network” wasn’t that strong, I did side projects instead of extracurriculars, and my grades were just okay.

So I knew I couldn’t rely on the same strategies everyone else was using — I had to get creative.

I took a tutorial on machine learning (and I really recommend that site for anyone looking to learn python). If you’re looking to learn coding, I also really recommend learning Python and JavaScript, but that’s another blog post. Most people who take the initiative to learn things online stop there. You started well by learning something by yourself, so you need to finish well by sharing what you learned with others.

I decided to take what I learned and gave a tech talk about it at my work. Then I created a pretty cool machine learning algorithm that outperformed the sp500 over a 7-year period and wrote about how I did it.

Finally, I did what everyone these days does when they do something noteworthy: I went on social media and told people about it. I used every single channel available to me and posted it there. I also compiled a list of recruiters and engineers in the companies I was looking for and emailed them about what I built (all like I outlined above — as I said, I only give advice that I have taken myself. Skin in the game, my friends).

Long story short, by the end of the fall I had interviewed with companies like Facebook, Google, and Bridgewater, amongst others.

Unfortunately, I only made it to the second round of both Facebook and Google, and there were visa issues with Bridgewater. I was disappointed, but overall I was happy that I at least got a chance and made it this far, considering where I started.

I also consider it a blessing in disguise, because that nudged me even more to start my own company, Atila.ca. Like I said, looking at my resume or LinkedIn, there is nothing particularly special about me. So say to yourselves “if Tomiwa can do it, so can I” and let’s get to work.

If you know anyone trying to get a job interview or just get noticed for an opportunity, share this article with them. I think there is some advice here that can really help. If you have any questions feel free to leave a comment or shoot me an email tomiwa@atila.ca.

Here’s that Sample Email and follow-ups

You can use these emails as a starting template, and feel free to leave a comment below or email me, tomiwa@atila.ca, if you want me to review your resume, emails or any thing you’ve made.

Email Subject: Sally, Software Engineering and Business Student — Feb 9 *

Hey Sally**,

My name is Tomiwa Ademidun, I am currently a 3rd-year dual degree student in Software Engineering and Business at the Ivey Business School at Western University. I noticed that you work at Stripe, which is a company I really admire and I would really like to work for.

I would like to find out more about how you were able to become a Software Engineer at Stripe, your experience at Stripe and any advice you may have on software engineering internship opportunities.

More specifically, I know that one of the best ways of getting an interview is through the referral process. Obviously, your credibility and reputation are very important and you want to make sure that you refer someone who actually deserves to be referred.

I have included links to an article about a cool coding project I did this summer, my website and my GitHub__. Hopefully, after reviewing my work and talking with me you can decide if I am deserving of a referral.

Kind Regards,

Tomiwa Ademidun

• I Probably could have come up with a better email subject tbh. Let me know if you guys have any tips for good email subjects.

**Obligatory, not their real name.

Follow Up 1

Hey I was following up on my last message to see if you have had a chance to respond.

Follow Up 2

Hey Sally,

Just following up on my last message. Looking forward to hearing back from you when convenient.

Sally ended up not replying at all, but that’s okay because Steve** replied. Most people are like Sally — but don’t give up because all you need is one Steve and then its showtime.

Originally published at atila.ca/blog/tomiwa on April 6, 2018.

I asked my wife if it is alright if her Date of Birth is known to a stranger. Only if they send me a birthday gift, she joked. What about your passport number? She lowered the book she was reading. I now had her attention.

Now imagine this, I said “You try to check-in for your flight online, and see the error message — This booking does not exist. You try again, this surely is a mistake. Nope, still the same error message. The call center person repeats the same words. This has to be a mistake! You check your email, and there it is — staring back at you — email confirmation of cancellation. But you are sure you didn’t do it.” Whodunnit?

This is not a far-fetched scenario from a Sci-fi book, this really happened.

An organisation with a primary Digital Product that lacks even the basic data security practices is living in a utopian world where people leave their safe open and never expect a burglar to walk in.

In the wake of full disclosure, sometime last year while booking travel for my family, I stumbled across a few data-security practices that, as a Data Security advocate, made me extremely worried. When I voiced my concerns to Emirates team, this conversation took place -

Conversation with Emirates support.

For a layman, when you book your flight through Emirates, Domestic or International, there are approximately 300 data points related to your booking.

The moment you click on manage preferences to select a seat or meal for your trip or to Check-in to your flight, your Booking ID and Last name is passed on to approximately 14 different third-party trackers like Crazy egg, Boxever, Coremetrics, Google, and Facebook among others.

Details

After I completed the booking on Emirates, I received an e-mail confirmation titled: Booking Confirmation — Booking Number.

Booking confirmation email.

The body of the email contained Manage booking. I proceeded to select seats and meal by clicking on the Manage Booking button and reached the Manage Preference page. This was pretty straightforward.

Manage booking link in email.

While as a user, I saw the normal behaviour of clicking a link and reaching the landing page “Manage Preferences”, in the background a redirection chain took place.

Redirection chain before reaching the landing page.

While Manage Booking link was supposed to be exclusive to me (the user and the website), this link was also shared with numerous third party trackers implemented by Emirates on their webpages.

Manage booking page.

The cherry on the cake was the HTTP link that leads to the Manage Preferences page. The insecureness of HTTP has been talked about over and over again, especially when it comes to maintaining the authenticity of the content and protection against interlopers. But in short, HTTP links are a Data Privacy nightmare. So, not only was Emirates passing on user information to the self-implemented third party trackers, but also allowing network adversaries to have access to the supposedly “Private” page.

_[http://track.emirates.email/track/click/30705682/www.emirates.com?p=eMSwicCI6IntcInVcIjozM....(REDACTED)](http://track.emirates.email/track/click/30705682/www.emirates.com?p=eMSwicCI6IntcInVcIjozM....(REACTED)" rel="noopener" target="blank" title=")

What kind of information can third-parties access?

Links mentioned in (1) and (2) are currently being sent to the third-parties.

Following fields take home the URL, which gives access to booking details.

Fields which take home the private url.

Sending url in key dr used by Google Analytics.

Anyone who has access to these links can not only read but also edit the information that I as a user can.

For example, they can now -

1. Change or Cancel flight
2. Change seat or meal preference
3. Add more products to the booking
4. Change or add Passport Information
5. Change or add Frequent Flyer Information, etc.

Modify booking.

Exhibit of editable personal information on this page:

a. Full Name:

Name.

b. Skywards number

Skywards number

c. Email ID / Telephone number:

Read / Change personal information

d. Amount Paid, fare breakup.

Amount paid, form of payment, fare break-up.

e. Passport details, Nationality, Date of birth, Gender

Passport details, DOB, Expiry, Gender, Nationality.

Note: In October 2017, fields such as Passport Number, Email Id and Telephone number were shown to be masked on the User Interface but were not obfuscated in source code. The web app has been revamped since then and these fields are now obfuscated.

Masked fields in plain text. (October 2017)

I decided to take a peek into the mobile app and see if the past catches up with the present, and lo and behold there it was in its full glory — Passport Number, Email ID and Telephone number in plain text. What was obfuscated on the web app was easy to access on the mobile app.

Passport details in plain text on mobile API.

Now, what is wrong with this?

This issue is not only limited to Emirates, a lot of airlines like Lufthansa, KLM (last checked on October 2017) suffer from the same issues.

Every website uses third party trackers for improving their product and provide better web-usage experience. Data leaks are often considered collateral-damage and sometimes not even considered at all while implementation of such trackers.

Most of these third-parties are present on a lot of other websites and use long term identifiers like cookies etc to track users across domains. Now because one of the websites, in this case Emirates, leaks private information, these companies now potentially can not only link the user’s activity across web, but also identify who the user is.

The questions that need answering by Emirates (and others) are -

1. Why was my booking information passed on to these third parties without my explicit consent.
2. Why do these third parties need to receive this information?
3. Is Emirates even aware that sensitive user information is being leaked to these third parties?
4. Who are these third parties?
5. What are they doing with user information?

Reporting it to Emirates

In the wake of responsible behaviour, on discovering these serious security flaws that violate user-data privacy, I decided to flag them to Emirates through Twitter DM in October 2017. Please note that I could not find a dedicated channel for reporting security bugs on Emirates website.

The Social Media Team immediately responded to my Twitter DM with a canned response but I was not ready to give up hope. I also wrote an email to the Product Manager highlighting the security flaws. I was met with a deafening silence.

As of today (2018–03–03) lot of these issues still persists.

This is a serious violation of privacy, there is no point during the whole booking process, where I agreed upon sharing any of this personal information with any of these websites.

The privacy policy of Emirates itself is not very clear. It does mention some of the of these services, but not all or the what data being shared with them.

Can I not opt-out?

Not an option. Unfortunately, I could not find a way to opt-out of this system provided by Emirates. I finally had to fall back on using privacy preserving browser extensions.

Can this not be fixed by Emirates?

As a Software Engineer who has worked for the some of the largest eCommerce companies, I understand the need to use third party services for optimising and enhancing not only the Digital Product but also how user interacts with the product.

It is not the usage of third party services that is of concern here in this case but the implementation of these services. Emirates has the control of their website and what the website shares with third party services. It is this control that needs to be exercised to limit the leakage of User information.

It is not a mammoth task, it is just a matter of commitment to preserving the basic right to privacy.

For example:

1. Private pages should have noindex meta tags.
2. Limit the presence of third-party services on private pages.
3. Referrer-Policy on pages with sensitive data.
4. Implement CSP and SRI. Even with a huge footprint of third-party services CSP, SRI are not enabled on Emirates.com
5. User needs to be informed when sensitive information like passport, contact details etc. is updated, edited, or deleted.
6. Domain for sending e-mails : track.emirates.email, should have a valid certificate. https://track.emirates.email/

If you are interested in reading more about the presence of trackers on your favourite websites, I highly recommend checking out WhoTracksMe.

Updates:

- March 6th, 2018:

Emirates responded with a standard statement.

Excerpt: “The depiction in Mr Modi’s article as to what data is being shared, or customer choice in ‘opting out’ is inaccurate.”

Here is my response: Privacy leaks round-trip: Emirates.com in denial

Happy Hacking!

• Konark Modi

Thanks for reading and sharing ! :)

If you liked this story, feel free to ??? a few times (Up to 50 times. Seriously).

_Credits: Special thanks to Remi ,Pallavi for reviewing the post._

I am publishing this with the permission of Facebook under the responsible disclosure policy. They have fixed this vulnerability.

This post is about a simple vulnerability I discovered on Facebook which I could have used to hack into other users’ Facebook accounts easily and without any user interaction.

This gave me full access to other users account by setting a new password. I was able to view messages, their credit/debit cards stored under their payment section, personal photos, and other private information.

Facebook acknowledged the issue promptly, fixed it, and rewarded me with a US $15,000 bounty based on the severity and impact of this vulnerability.

How the hack worked

Whenever a user Forgets their password on Facebook, they have an option to reset the password by entering their phone number and email address on https://www.facebook.com/login/identify?ctx=recover&lwv=110.

Facebook will then send a 6 digit code to this phone number or email address which the user has to enter in order to set a new password.

I tried to brute force the 6 digit code on www.facebook.com and was blocked after 10–12 invalid attempts.

Then I looked out for the same issue on beta.facebook.com and mbasic.beta.facebook.com. Interestingly, rate limiting was missing from forgot password endpoint.

I tried to take over my own account (as per Facebook’s policy, you should not do any harm any other users’ accounts) and was successful in setting a new password for my account. I could then use this same password to log into my own hacked account.

A proof of concept video of the hack

As you can see in the video, I was able to set a new password for the user by brute forcing the code which was sent to their email address and phone number.

Vulnerable request

POST /recover/as/code/ HTTP/1.1

Host: beta.facebook.com

lsd=AVoywo13&n=XXXXX

Brute forcing the “n” successfully allowed me to set new password for any Facebook user.

Disclosure Timeline

Feb 22nd, 2016 : Report sent to Facebook team.

Feb 23rd, 2016 : Verified the fix from my end.

March 2nd, 2016 : Bounty of $15,000 awarded by Facebook

Take your idea to functional bot in hours, get real user feedback, and launch before the weekend is over! ?

_[Art Chatbot](http://www.artchatbot.com" rel="noopener" target="blank" title=")- Discover, learn about, and purchase artwork through Messenger

Chatbots are not new. But they are a technology that most of us have probably read about, possibly used, and yet do not truly understand simply due to the lack of both everyday and prolonged exposure.

For months leading up to last Friday, I had bookmarked chatbot-specific publications (such as Chatbots Magazine), liked Facebook posts about chatbots, and even upvoted some on Product Hunt.

I wanted to change my understanding of chatbots and challenged myself to learn as much as I could over the weekend. I had determined it was time to really understand chatbots through mastering the fundamentals and building my own.

Like Most Projects and Companies I’ve Launched, I Began by Defining the Following:

• Timeline: Sunday was my deadline since this was a weekend project.
• Goals: Learn about the existing tools for chatbot developers that I could use to leverage technology and build on top of (I decided on Chatfuel). This would provide me with a fundamental understanding of chatbots.
• Success Outcome: Build a functional chatbot that did one thing well, iterate on real user feedback, and launch.

Unlike past projects, I didn’t have the exact idea in mind prior to making the decision to begin.

I had a window open on my laptop displaying a limited artist print I was looking at (Alec Monopoly’s “Pablo Judicial”). I simply typed “art chatbot” in Google to see if there was already a chatbot to purchase artwork.

To my surprise, there was not. I knew that my passion for art was the perfect match for my weekend desire to master chatbots.

I then removed the space in my search and had the name “Art Chatbot” in front of me. $9 and a few seconds later, and I also had the domain.

Since it was still early Saturday morning and the above had taken place in the matter of about 30 minutes, I had an hour or so to create the logo (using Squarespace logo creator).

I then worked on lean branding for social assets (Snappa), and also created the Facebook page (which is required to build and test the bot since it is a Facebook Messenger Bot).

Squarespace logo in minutes, and free!

Now that I had the logo, social cover, and also had the Facebook page live, I invited a few friends to like the page.

I got a few messages back asking what I was up to with the page and commenting on the name and logo. And so within minutes of my lean branding exercise, I already had some positive feedback!

I then told them what I was building and asked if they could test in the following hours over the course of my build.

This led to real user feedback as I was building so that I could create a more realistic conversational design and flow for my chatbot.

After getting setup on Chatfuel, I watched some YouTube tutorials and used some of the templates provided on Chatfuel to learn through modifying (thanks Persona!).

I realized that the process is fairly straightforward, and it was all about the conversational flow and user journey.

I Then Completed the Following Definition Exercise to Define What I Was Going to Build:

1. Map out the conversational flow and user journey. In this case, it was for a user to discover artists, view artwork, and purchase artwork.
2. Define the structure of the bot. In Chatfuel, this is done by “blocks,” which I created for each main state, sub states, destinations, queries, and answers.
3. Identify and also limit the amount of content that I would display. Since I was building this in hours, it was more about the experience and validation, rather then how robust I thought it should be.

Actually building the bot in Chatfuel began at the second step with the blocks. It was mid-afternoon Saturday now and I was feeling a bit overwhelmed with the ambitious complexities I initially set out to build.

To overcome this, I removed some of the artists, the artwork to show, and then the artwork available so that I could focus on a better experience rather then trying to account for quantity.

Art Chatbot being built from the Chatfuel dashboard.

Before Saturday was over, I had completed the initial version of Art Chatbot. I had friends testing the chatbot and providing real feedback, and all of the social pages and assets were prepped to launch before the end of the weekend.

With this initial version completed, I spent Sunday feeling a bit less time-constrained. I was able to focus more on prepping for a launch along with continual chatbot iteration.

I also began implementing basic AI functionality into the bot. I messaged a few art technology companies to ask what data was valuable to them (knowing I could easily collect this). This way, I could be on their radar and possibly build a chatbot that had some monetary value through data down the road.

I ended the day on Sunday by making a quick landing page using Instapage and optimizing it for a Product Hunt launch that I would do Monday.

_Created a [landing page](http://www.artchatbot.com" rel="noopener" target="blank" title=") in a few minutes using Instapage and the content I used from the chatbot blocks.

To pre-launch the chatbot, I also setup Botanalytics (to help monitor, track, and analyze messages), posted in Facebook Groups to generate initial users, and then drafted my Product Hunt intro that I would post.

I also used a Google doc to create all the verbiage I would share on my social channels. Then I could simply copy the text, add the Product Hunt URL, and share across channels on Monday.

The result is that Art Chatbot hit 100 upvotes on Product Hunt and had also sent over 1,800 messages by the end of the day.

I not only learned about chatbots, but I am more confident in my understanding of the technology through a real use case. I also refined my ability and the process I used to build and launch a product rapidly.

_From idea Saturday to [Product Hunt](https://www.producthunt.com/posts/art-chatbot" rel="noopener" target="blank" title=") Monday!

Overall, I consider the weekend project a success — and more importantly, it was refreshing and fun!

I’ve also tried to “open source” everything about Art Chatbot’s build (I documented it on my social) and the chatbot roadmap. I will continue to keep everything publicly accessible (link below) going forward for anyone that is interested in being involved or contributing.

Day 2 analytics following Product Hunt launch.

Art Chatbot Open Sourced ? bit.ly/artchatbotopensource

With an eagerness to learn and using the process above, it’s certainly possible for anyone to build their own chatbot in a weekend! ?

Be sure to tweet at me with any questions you have, feedback, and also let me know when you launch your own chatbot and I’ll check it out/retweet! You can also check out my personal chatbot I made after this weekend project here.

*A special thanks to Avery Andon and Art Life for the inspiration during the creation of Art Chatbot. Art Life is the official online gallery for both artists and artwork that are linked as URL’s in Art Chatbot.

Rather see a video format of this with more details? Watch this 12 minute video where I share more:

Streaming on Facebook Live can be a powerful marketing strategy for startups and businesses. They can share knowledge, provide value, get exposure and collect high-quality leads.

Prepare your Facebook Live session upfront. Researching about your target audience and build a detailed agenda. The session can boost your business dramatically.

I was Chief of Product and Technology of my previous startup dealing with fraud detection. I decided to try Facebook Live as a new marketing strategy.

It was still fairly new at the time. Once a Facebook Live session was up, relevant people got Facebook notifications to join the session. This increased the exposure even more.

There are many posts talking about how to better build your Facebook live session. They discuss which topics to cover, building an agenda, camera angles, session duration, and more.

But there is one piece of the puzzle that business owners and marketers often tend to forget or do not pay attention to: When is the best time to stream your Facebook Live session?

You can answer this question using an educated guess based on your familiarity with the target audience.

For example:

• Pregnant moms are ready to consume your Live session on Monday afternoon.
• Teenagers at the ages of 18–22 are in the right mindset on Saturday morning.

But there is so much data around us that we can use with a few clicks of a button. You actually stay behind if you don’t make a proper usage of some of the data available.

Almost every marketing platform or social network opens API services. You, as a technological entrepreneur, can easily consume these. This data can provide valuable conclusions that can drive your business objectives beyond your competitors.

This approach is often called Data-driven decisions.

Once you start justifying any or at least most of your business decisions using data you own or data you can collect from different resources, you can stop guessing and start making data-driven decisions.

I like to think of data-driven decisions as crowd-sourcing. Lior Zoref was on this TED talk . He invited an ox to the stage and asked the audience to guess its’ weight. If you watched this, you were probably overwhelmed by how accurate the crowd’s average was compared to the real weight of the ox: 1,792 pounds or 1795 pounds!

When you’re making guesses about your business objectives as individuals, you’re not different than any individual sitting in the crowd and trying to evaluate the ox’s weight. You can even be the one who guessed 300 pounds or 8000 pounds, which may cost your business a lot of unnecessary expenses.

But, if you’re using the wisdom of the crowd to make data-driven decisions, you’ll most likely be ahead of every other individual. In business terms, you’ll be ahead of your competitors.

I’m not a pure marketer. But with basic data analysis skills I can push my business forward in all aspects, including marketing.

I’m going to walk you through a practical step-by-step guide about how to access Facebook data. Then how to analyze it based on our needs about the optimized time to broadcast on Facebook Live.

To follow this guide you need:

• A Facebook account
• A Facebook group you would like to analyze
  If it’s a private group then you need to be a group member
• Python 2.7 installed
• Jupyter notebook installed
• Facebook graph API Python library installed

A Jupyter notebook is a recommended tool for data analysis in Python. It has a lot of highlights. It enables you to run snippets of code and save the results in memory. So you won’t run all your scripts over and over again every time you implement a minor change. This is crucial when doing data analysis because some tasks can take a lot of execution time.

Although it’s not essential, I recommend working inside a Python virtual environment. Here is a post I wrote about the advantages of a virtual environment when using Python.

I recommend working in an Ubuntu environment when doing data-analysis using Jupyter notebooks.

Step 1 — Getting the Facebook group ID

To get data from Facebook API, we need to specify the ID of the entity we want to get data from, in our case, a Facebook group.

Lookup-id.com is a nice tool you can use to find the ID of a group based on its URL. Copy the URL of your group and paste it in the search bar.

In this article, we will use the group: Web Design and Development.

ID: 319479604815804

Step 2 — Getting to know the Graph API Explorer

To get the most out of Facebook API besides documentation, Facebook has developed a playground for developers called the Graph API Explorer.

The Graph API Explorer enables us to get a temporary access token and start examining the capabilities that Facebook API has to offer.

Click on Get Token. Don’t select any permission. Click Get Access Token .

Facebook API has many endpoints you can use. In this guide, we are going to use two main endpoints:

• The group endpoint
• The reactions endpoint

To figure out the structure of the response you’re expecting to get, specify the endpoint URL and click Submit.

Let’s examine the URL endpoint for grabbing the last posts from the group’s feed. Type this URL in the Graph API Explorer:

319479604815804/feed

and hit Submit.

You should now see the last posts from the group’s feed in a JSON structure. It contains the post’s content, its id and the updated time. By clicking on one of the id’s and adding to the end of the URL:

319479604815804_1468216989942054/reactions?summary=total_count

You should see a list of the reactions for the specific post, and a summary of the total count of reactions.

This way you can play around with all the features the Facebook API has to offer.

Another tool for examining API endpoints of APIs which don’t offer a playground is Postman. You can read more about this tool and essential tools for web developers.

Step 3 — Our plan and assumptions

Our goal is to find the best time to have a Facebook Live session in the group that contains our target audience. To do that, we assume that the more activity there is in the group at a specific time, the most likely our Facebook Live session will gain more traction.

So our goal now is to figure out when there is a peak in the group’s activity over time. And by when I mean a specific weekday and time.

To do that, we are going to grab the last 5,000 posts from the group’s feed. Then we’ll plot the distribution of the times they were updated.

We assume that longer posts indicate more activity in the group because members spend more time in the group writing them. So, our next step will be to take into consideration the length of each post in the distribution.

Reaction on Facebook is probably a great indication of people engaging with a specific post. Thus, our last step will be to collect the total number of reactions for each post. Then take that into account in the distribution of activity over weekdays and hours.

Because reactions may come after the post, we should be cautious using this data analysis approach.

Step 4 — Let’s analyze some data!

To start a Jupyter notebook, you should execute:

ipython notebook

and then choose New → Python 2.

To analyze and plot the data, we are going to use the numpy and matplotlib libraries. These are very popular Python libraries you should use to better analyze your data.

Let’s import all the libraries we need:

import matplotlib.pyplot as pltimport numpy as npimport facebookimport urlparseimport datetimeimport requests

and specify our access token and group id:

ACCESS_TOKEN = 'INSERT_ACCESS_TOKEN_HERE'GROUP_ID = '319479604815804' # Web Design and Development group

Then, let’s initialize the API object with our access token:

graph = facebook.GraphAPI(ACCESS_TOKEN)

Now we want to grab the posts from the group’s feed. To avoid errors during the API calls, we will limit each API call to 50 posts and iterate over 100 API calls:

posts = []url = "{}/feed?limit=50".format(GROUP_ID)until = Nonefor i in xrange(100):    if until is not None:        url += "&until={}".format(until)    response = graph.request(url)    data = response.get('data')    if not data:        break    posts = posts + data    next_url = response.get("paging").get("next")    parsed_url = urlparse.urlparse(next_url)    until = urlparse.parse_qs(parsed_url.query)["until"][0]

In each API call, we specify the until parameter to get older posts.

Now, let’s organize the posts into weekdays and hours of the day:

weekdays = {i: 0 for i in xrange(7)}

hours_of_day = {i: 0 for i in xrange(24)}

hours_of_week = np.zeros((7,24), dtype=np.int)for post in posts:    updated = datetime.datetime.strptime(post.get("updated_time"), "%Y-%m-%dT%H:%M:%S+0000")    weekday = updated.weekday()    hour_of_day = updated.hour    weekdays[weekday] += 1    hours_of_day[hour_of_day] += 1    hours_of_week[weekday][hour_of_day] += 1

and then, plot the results using matplotlib bar charts:

plt.bar(weekdays.keys(), weekdays.values(), color='g')plt.show()

0 represents Monday

plt.bar(hours_of_day.keys(), hours_of_day.values(), color='r')plt.show()

All times specified in IST

With only this basic analysis, we can already learn a lot about better or worse time slots for broadcasting to this group. But it does not seem informative enough. Maybe because the data is divided into 2 graphs and missing some critical information.

Let’s try to present a heat map of the data, that enables us to see 3D information:

plt.imshow(hours_of_week, cmap='hot')plt.show()

Well, this is much better! We can see that the group is very active on Monday to Friday between 6:00 am and 10:00 am.

Now let’s take into consideration to post length and see how it affects the results:

weekdays_content = {i: 0 for i in xrange(7)}hours_of_day_content = {i: 0 for i in xrange(24)}hours_of_week_content = np.zeros((7,24), dtype=np.int)for post in posts:    updated = datetime.datetime.strptime(post.get("updated_time"), "%Y-%m-%dT%H:%M:%S+0000")    weekday = updated.weekday()    hour_of_day = updated.hour    content_length = len(post["message"]) if "message" in post else 1    weekdays_content[weekday] += content_length    hours_of_day_content[hour_of_day] += content_length    hours_of_week_content[weekday][hour_of_day] += content_length

The heatmap we get:

This is nice but should be treated with caution. On one hand, we can see a very specific time that is the optimized time slot to have our Facebook Live session. But, it might be an outlier of a super long post.

I’ll leave it to you to figure it out in your next data analysis project. Take a larger amount of posts or grab an older batch of 5000 posts from the group’s feed.

To take reactions into account when analyzing the data, we need to make another API call for each post.

This is because it’s a different API endpoint:

weekdays_reactions = {i: 0 for i in xrange(7)}hours_of_day_reactions = {i: 0 for i in xrange(24)}hours_of_week_reactions = np.zeros((7,24), dtype=np.int)for i, post in enumerate(posts):    url = "https://graph.facebook.com/v2.10/{id}/reactions?access_token={token}&summary=total_count".format(    id=post["id"],        token=ACCESS_TOKEN    )

headers = {        "Host": "graph.facebook.com"    }

response = requests.get(url, headers=headers)

try:        total_reactions = 1 + response.json().get("summary").get("total_count")    except:        total_reactions = 1

updated = datetime.datetime.strptime(post.get("updated_time"), "%Y-%m-%dT%H:%M:%S+0000")    weekday = updated.weekday()    hour_of_day = updated.hour    weekdays_reactions[weekday] += total_reactions    hours_of_day_reactions[hour_of_day] += total_reactions    hours_of_week_reactions[weekday][hour_of_day] += total_reactions

We used a low-level approach by specifying the exact HTTP request and did not use the Facebook Python library. This is because that library doesn’t support the last version of the Facebook API required when querying the reactions endpoint.

The heat map generated from this data:

We can conclude that the three approaches we used agree on Monday and Wednesday, 6:00 am to 7:00 am.

Conclusions

Data analysis can be challenging and often requires creativity. But it also exciting and very rewarding.

After choosing our time to broadcast on Facebook Live based on the analysis presented here, we had a huge success and a lot of traction during our Live session.

I encourage you to try and use data analysis to make data-driven decisions in your next business move. And start thinking in terms of data-driven decisions.

You can find the Github repository here.

I originally published this on CodingStartups.

Before that, Facebook was using their own custom “BSD+Patents” license. This was similar to the widely-used BSD license, but also included a clause that basically said: “you can’t sue Facebook for infringing on your patents.”

This license came under fire this summer. Here’s what happened.

July 15: The Apache Foundation Bans React

The Apache Foundation sent out a notice banning the use of any BSD+Patents licensed tools in their open source projects. (Apache has a history of banning licenses that they consider too restrictive, such as the GNU GPL.)

August 18: Facebook says the BSD+Patents license is to protect them from “meritless patent litigation”

Facebook blogged that they needed the BSD+Patents license so they could develop React faster, without needing lawyers to sign off on their changes.

This spurred communities like Reddit, Hacker News, and freeCodeCamp to discuss React alternatives.

September 14: WordPress says it isn’t comfortable with Facebook’s BSD+Patents license

WordPress — which powers about 25% of all websites — said they wouldn’t use React in future projects unless the license changed.

September 22: Facebook announces it’s ditching the BSD+Patents license and switching to the MIT license

September 24: WordPress says it’s OK with React now

The founder of WordPress says he’s happy with the change, and WordPress may use React in future projects.

September 25: Facebook officially switches to the MIT license

Sophie Alpert made the commit that changed the license over to MIT.

September 26: Facebook releases React 16

_React is the “most loved” developer tool, according to [64,000 developers surveyed in April 2017 by Stack Overflow](https://medium.freecodecamp.org/73-of-programmers-are-web-developers-and-other-insights-from-stack-overflows-massive-2017-survey-89a13b11e370" rel="noopener" target="blank" title=").

_React is now [the most commonly requested skill](https://medium.freecodecamp.org/trending-developer-skills-based-on-my-analysis-of-ask-hn-whos-hiring-26c02a3ca1fd" rel="noopener" target="blank" title=") in Hacker News “Who’s Hiring?” posts.

Now that the uncertainty around React’s license is settled, React will most likely remain one of the most popular tools for web development.

Facebook is also switching to more permissive licenses for its other open source projects, too.

I hope you found this explanation helpful. If you want to explore open source licenses, GitHub created this tool to help you choose the right one for you.

I only write about programming and technology. If you follow me on Twitter I won’t waste your time.

According to data collected by BuiltWith.com, 6% of the top 10,000 most high-traffic sites load content from Facebook’s servers. For the vast majority of them, that content is likely Facebook’s Javascript SDK, a huge block of code that is needed to display such features as the Like button (as seen on many media sites) and Facebook comments widgets (also used on many big media sites, Buzzfeed among them).

This SDK code is so big that it represents about 16% of the total size of all JavaScript on the average web page.

One of the culprits behind modern websites taking so long to download

As a sizable and widely-used software library, the Facebook SDK is a nice way of illustrating some of the answers to the questions: just why is the average site today so big? And how much does size actually matter?

Why so big?

The Facebook SDK is very full-featured, duplicating many of the tools the average site is likely to already include for its own developers’ use: methods for retrieving data from other sites, for determining which browser and device the user is using so as to target specific features to them, and for displaying UI elements (like confirmation dialogs and buttons). If we categorize all of the pieces of the SDK, the breakdown looks like this:

_The amount that each set of features in the SDK contributes to total filesize. (Note that this is the size of the file before it has been compressed; the final package will be smaller.) [[Source data, methodology, and more screen-reader-compatible data table](https://docs.google.com/spreadsheets/d/1vdRzi-wlYNQOoAt4bGOseDMt7vgmpv9BoSfy4yM1SYY/edit#gid=873242422" rel="noopener" target="blank" title=")]

Of the sets of features, three stand out the most:

_The three sets of features in the SDK that are completely irrelevant to the vast majority of users on most sites. Eliminating them — if it were possible to do so — would shave off roughly 20% of the SDK filesize. [[Source data, methodology, and more screen-reader-compatible data table](https://docs.google.com/spreadsheets/d/1vdRzi-wlYNQOoAt4bGOseDMt7vgmpv9BoSfy4yM1SYY/edit#gid=873242422" rel="noopener" target="blank" title=")]

“Canvas” is Facebook’s system for apps that are intended to be loaded within Facebook (Facebook made a major push in the past to encourage developers to build apps that lived within Facebook; I’m not entirely sure how widely such apps are used today, but either way, a regular website does not use any of the Canvas-related features.) The cost of including them in the SDK is pretty marginal: only 1.5% of total size.

After that, we have legacy feature support. This reflects the fact that an API will accumulate multiple interfaces for handling the same features over time. For example, developers can write code that calls either FB.getLoginStatus() (the legacy approach to requesting the user’s current Facebook login status) or Auth.getLoginStatus() (the new, encouraged approach). The way to get around needing to include both sets of methods is releasing them in separate versions of the SDK, but Facebook opted not to do this, likely to simplify the experience for developers and to maximize the number of sites using the exact same file (to increase the likelihood that the average user already has it downloaded). This decision comes at a small cost: roughly 3.5% of the SDK code is for handling features that are explicitly marked as “legacy” (and it’s quite possible that there are many more “legacy” features that just aren’t explicitly marked as such).

Most significantly, the SDK includes a number of polyfills and polyfill-like utilities, which make up over 15% of its code. Polyfills are used to supply features that are found in newer browsers to older browsers, and sometimes also to supply newer features that are upcoming but haven’t been added to any browsers yet. Most of the polyfills included by the Facebook SDK are for features that are already included in browsers used by the vast majority of internet users. They serve only to make the SDK work for the < 1% of global internet users who are using old browsers like Internet Explorer 8, which many (if not the vast majority of) major sites have given up on supporting.

Of the remaining ~80% of the SDK, it’s a bit more difficult to untangle which features are needed for which purpose. This is because it is written such that, to use a simple feature like the Like button, one must also include code that is used only for comments, video embeds, login buttons, and other unrelated features. Facebook could have opted to distribute much smaller files for including only single features such as Like buttons, but has a business goal of encouraging sites to use as many FB-provided features as possible.

Does size matter?

Due to the widespread use of Facebook’s SDK, and the fact that it changes relatively infrequently, many users are likely to have already downloaded it before they load a site. In fact, this is a big part of the rationale for why Facebook would distribute such a huge file, rather than smaller ones for specific features such as Like buttons. And on most users’ network connections — at least those in developed countries — the time it takes to download the file is marginal.

But regardless of whether the user’s browser already has the SDK downloaded, there is still overhead involved in running a large block of Javascript, especially on mobile devices. On the relatively new MacBook Pro I’m writing this on, Facebook’s SDK takes around 50ms (1/20th of a second), to run on a site like Buzzfeed. Not bad — especially when taken in context with the rest of the JS code, including ad-related code that takes far longer to execute — but still a non-trivial cost for something that is only used to display comments on the very bottom of the page.

Script evaluation in Chrome on a recent MacBook Pro

On a very new smartphone (Google Pixel), the JS execution time is doubled, now taking over 1/10th of a second:

Script evaluation on a Google Pixel smartphone

When looked at in context, this is a tiny fraction of the total code execution time on the page. But it adds to the amount of time during which scrolling or otherwise interacting with the page can be a choppy and unpleasant experience. And this gets at an important point: this particular SDK has a marginal cost, but modern websites — especially media sites — often include similar code from a large number of third parties (this example I captured from Gawker before it was killed by a billionaire vampire shows just how many such requests there can be).

Even setting aside the privacy impact of sending some user information to each of these third parties, the cost of all these features adds up quickly. Each third-party script that a site adds comes at a cost, both in terms of performance and in helping to rationalize the addition of the next “relatively harmless” chunk of third-party code later on. Besides the immediate performance impact of the additive cost of all of this code, this impacts developer morale: imagine working for days to shave off 10% of your own code’s load time, only to see a giant block of third-party code added that dwarfs the impact of that painstaking effort. And then (if you work for a media site), seeing this same pattern repeat itself over and over again every few months.

Should you include it?

If you need to use a feature like Facebook Comments, there’s no getting around the need to load the Facebook SDK. But depending on how your site is structured, you may be able to limit the SDK’s performance impact by only loading it when needed (e.g. once the user has scrolled down to the point where comments should become visible).

If you want to use the Like button, stop and reconsider. Facebook no longer displays Likes of a page prominently (or, in most cases, at all) on user timelines. It’s better to use a simple custom Share button or link, and as a side benefit, doing so will prevent Facebook from tracking all visits to your page and interfering with the privacy of your users. Sites that have eliminated the Like button have failed to identify any negative impact of doing so when it comes to Facebook traffic referrals.

CORRECTION to title: Originally I titled this “Why 16% of the code on the average site belongs to Facebook, and what that means”. As some rightly pointed out, this implies that a full 16% of the Javascript on all sites on the Internet (or at least of all the top sites), consists of the Facebook Javascript SDK. This was not my intent and I can see how it came across as overly sensationalist.

Hopefully the new title makes clearer that the Facebook SDK measures up at 16% of the size of the average site’s Javascript, and no longer implies that it represents 16% of total site Javascript across the internet. As David Gilbertson notes here, the actual global number would be much smaller — 0.96%. He also raises a good point re: caching: the Facebook Javascript SDK is not cached optimally at all, it only gets cached in the most ideal fashion for up to 20 minutes, after which the user’s browser checks back with Facebook’s servers to verify that it already has the latest version.

A friend of mine asked me to help convert articles that were previously posted to their site into Facebook Instant Articles. Afterwards, I decided to compile a guide to help nontechnical people convert their old articles, blog posts, or online content.

Even if you don’t know what Facebook Instant Articles are, you may already be using them. According to Facebook IA’s FAQ page:

“Instant Articles is a mobile publishing format that enables news publishers to distribute articles to Facebook’s app that load and display as much as 10 times faster than the standard mobile web.”

IA’s dictate a content publishing standard that results in both a pleasing design, and optimized performance for articles opened from within the Facebook mobile app. You can read more about the benefits of IA’s.

Facebook offers a plethora of ways to fast-track IA production and conversion. Yet it seems the current guides are for developers or larger enterprises that have a more complex publishing ecosystem.

It is hard to find guides for converting previously posted articles that don’t involve using the Facebook IA API, PHP SDK, or the WordPress plugin. For non-developers, most of these tools require too much technical experience. Even when one tries to find the WordPress plugin tutorial, one has to dig into the documentation in Facebook’s developer portal . This is not ideal for non-developers who become dissuaded before they can ever find this page.

Let’s work together to convert any article already published on the web into a Facebook Instant Article! For our tutorial, we’ll be using the article about a celebrity dog from the movie ‘Anchorman’.

Let’s Groove!

Step 0: Prep

We won’t need to install any plugins or integrations, but we will need a text editor to work with the HTML source code. There are a lot of different code-oriented text editors, but for the sake of this example, I recommend Sublime. It has all the features we’ll need, and is easy to use out of the box with a fresh install.

Once you install Sublime, we’re going to want to download the code template that we’ll be using from GitHubGist.

On the right side of the screen: 1. Right click the "Raw" button2. Click "Save link as..." By default, it should save as an HTML file with the name "template".

Now we’ve got the code editor and the template code that we’ll be editing!

For the last step of setup:1. Boot up Sublime2. Open the template file we downloaded

Step 1: Getting the Banner Image

Hop back over to your internet browser and find the article you wish to convert on its’ live site. We’re going to first grab the banner image, which we’ll use at the top of the Facebook Instant Article.

To do this, right click the image, and select _“Copy image address”._

Switch back to the template that we have open in Sublime. Search for the

Highlight the original URL located between quotes on line 36, and replace it by pasting the image address that we copied from the banner image. Make sure there are double quotes on each side of the URL to preserve the format. And make sure to not delete the “ />” at the end of the line.

Edit the text inside of <figcaption> </figcaption> with the caption that you will want to appear below the image. This is often where the image attribution goes.

Chrome: CTRL + U, or Right Click → View Page SourceFirefox: Right Click → View Page SourceSafari: Safari menu → Preferences → Advanced, Enable "Show Develop menu in menu bar", then Develop menu → Show Page Source

<h1>Article Title</h1>

becomes

<h1>15 Minutes in the Life of Celebrity Dog Baxter from 'Anchorman'</h1>

<link rel="canonical" href="http://example.com/article.html">

becomes...

<link rel="canonical" href="https://www.theatlantic.com/entertainment/archive/2013/12/15-minutes-life-celebrity-dog-baxter-anchorman/356235/">

For example, <time class="op-published" datetime="2014-11-11T04:44:16Z">November 11th, 4:44 PM</time>

Displays as: November 11th, 4:44 PMLet's change it to: July 24th, 2017. 6:30 PM

<time class="op-published" datetime="2017-7-24T06:30:16Z">July 24th, 2017. 6:30 PM</time>

Last Update Time: Same plan as above, but on line 21 of the template.

<p> Article content </p>

Insert this script right before the closing </body> tag:

CHANGES (to the right of the "=").uid - The unique ID for your ChartBeat account.domain - The full domain of the original article.sections - The name of the 'section/genre/tags' your article belongs to.authors - The name of the author to associate with this piece