Jacob is a digital nomad and learning to code means he can work remotely from anyhwere. He doesn't have a degree though! Jacob is a self-taught web developer and in this article goes over how he learned to code. He offers lots of advice on interviews and getting your first job in tech. Enjoy!
Hey, so can you introduce yourself?
I'm a Canadian developer working at an internal startup for a mortgage brokerage called Cannect in Toronto. Cannect had built an internal CRM they used to streamline the mortgage application process, and they brought me on early in the process of building a second scalable version that could become its own product and its own company.
We have 8 developers, including myself, and my responsibilities these days include planning out the code architecture, doing code reviews, and development work everywhere on the stack.
We used to work out of an office in downtown Toronto, but after covid hit we went fully remote. Some of our team scattered out of Toronto, and I became a nomad spending a few months in the Canary Islands, half a snowboard season in Bansko, Bulgaria, and now I'm speaking to you from Dojo Coworking in Bali, Indonesia.
How did you learn coding?
When I was around 12 I got access to the internet. I found communities of people making their own games with the same tools I was, but their games were good! I could look through forums to find examples of things I didn't know how to do, and if I got stuck I could ask questions and smarter people would help me.
Discovering developer communities was the game-changer. Four years after discovering other game developers online, I released my first Flash game, Challenge Accepted. I wanted to keep pursuing game development, but the kind of games that made money were (and continue to be) pay-to-win digital casino type games, and that wasn't fun for me.
Mostly I drifted from one hobby project to the next learning whatever I needed to learn to make it work. I learned PHP building a pizzeria locating app until Yellowpages revoked my access for basically just wrapping their search function.
I learned Javascript building an anonymous social network (like Yik Yak or Secret) called Masquerade that experienced a few months of popularity at a local college before it devolved into anonymous harassment (like Yik Yak and Secret) and everyone left, so I shut it down.
I built a few drinking game apps for house parties with my friends, one dating site I couldn't convince anyone to use, and a few more attempts at games. I learned React Native building an app that let me type in words and then displayed them in big letters across the screen, so I didn't have to shout my order in loud clubs.
For everything I was self-taught, up until the time I bought Kent C Dodd's Testing Javascript course, which taught me so much in so little time that it shattered my confidence in the months and years I had spent learning things the hard way. I take some solace in knowing that by learning so slowly over years I likely picked up a ton of fundamentals that couldn't be taught so quickly, but I'm sure I wasted a ton of time not reaching out to experts beforehand. By the time I got my hands on Epic React the first few modules were a breeze, but the last half locked in so many concepts I was shaky on and the benefits have extended to my Vue code as well.
How come it took you a decade to see you could do coding for a living?
After joining the workforce I had ruled out working in tech as an option. Before joining the workforce, well, I didn't know any programmers in real life. I had some online friends from my game-dev days who were planning on coding professionally, but they all got into top universities to do it.
In high school, I planned on going to university too. And while I hadn't narrowed down exactly which field I wanted to study (high school students rarely do), a CS degree was at least on my radar as an option. By graduation I picked my top choice university and applied for admission into the Faculty of Science at the University of Alberta, as well as a few other schools I was less interested in.
Months passed, and eventually I got accepted into my second choice university. I wasn't thrilled about going there, since it wasn't particularly prestigious and didn't have much in the name of connections to tech companies – two highly important parts of a good college.
But a month before classes started I received an email from the University of Alberta. "You have received Early Admission! Welcome to the Faculty of Science," it said. Possibly the most life-changing email I ever received.
Or perhaps the second most life-changing, because the next day I got another email informing me that they accidentally sent the acceptance letters to the wrong mailing list, and it did not count as a letter of admission. It would have been only disappointing, instead of tragic, if I hadn't spent the time between those two emails politely informing the other university I'd be attending a different one and they could give away my spot.
The scholarships I had were only available for high school students entering post-secondary schools the following semester, and I didn't qualify for financial aid, so going months or a year later wasn't an option.
I wish I had known back then there were opportunities in tech for people without degrees because that seemed like a deal-breaker. If I wanted to make money coding, I had to code something cool and sell it myself because no one would hire me without a degree.
Everyone I knew in high school that wasn't off to university was headed straight for the oil industry. All the adults in my life were involved in traditional blue-collar careers: warehousing, construction, retail, bookkeeping. I had made a bit of money off my flash games, but you can only hear "grow up and get a real job" so many times until you do, so now that university was off the table for me, I did.
Why did you learn to code?
Fast forward five years of arc welding, (an apprenticeship process that I think computer science education could learn a lot from) I was working at a shop manufacturing pipes for oil facilities. I learned a tremendous amount about logistics and manufacturing processes and how systems should work together. By the time I would use Kanban for software development, I already had experience implementing it in its classical sense moving steel. One day an injury put me and my nine and a half remaining fingers in the office for a few months, where I was exposed to an entirely new set of managerial problems.
No one had any clue where anything was. Folks would show up in the morning to take a generator out to site, but they didn't know whether the ones they had were already taken out by someone else or if they'd been stolen. They'd buy a new one on the way out of town only to find out the next day that it had been stored in one of the yard's shipping containers the whole time.
So I built a new asset management system, in vanilla javascript with a MongoDB backend. I manually imported their outdated spreadsheets of inventory and let them clean up and modernize it themselves in the application. They could sign out a tool to any combination of job number, customer, truck, or employee.
When a pipefitter switches trucks, the tools signed out to them go with them and the tools signed out to the trucks stay with the truck. If anything was missing, they had an audit trail of exactly where it was last seen and who was responsible for it.
Since they didn't know what equipment was signed out to the customer, they weren't charging out for it. Now, each week they get a report of what's signed out to each customer and the billable cost of it, so they can send the 5 figure invoices they were missing out on. I maintained that software for close to three years, and it became my portfolio project and work experience for my entry into the software engineer market.
That transition was anything but smooth. It was my long-distance girlfriend at the time who convinced me to take that leap, I left my job, my friends, and my parents to be with her and look for a tech job. While the relationship didn't last very long (we soon realized that I needed to move to a bigger city to have a real shot), I'm still grateful for the push out of my comfort zone.
I took my car, my clothes, my laptop, and drove down to Vancouver where my prospects were decidedly better. One of the local universities was offering career counseling at a local university, so I had them review my online portfolio profiles and give me tips to improve it. I spent twelve hours and three caffe lattes a day (often at one of Vancouver's 24/7 Breka Cafés) applying for jobs on Indeed, Remoteok, and Angellist, for both Vancouver and Toronto.
It took a while to start getting responses, because writing a good application is an art in and of itself. I saved every cover letter I sent in my notes and pieced together new cover letters using paragraphs from the previous. Eventually I had ten template paragraphs that I could mix and match based on the role. With a little creativity I had a well tailored cover letter for virtually any opportunity I was remotely qualified for.
What was the interview process like for your entry level software engineer job?
It took 3 months, 4 offers, maybe 20 interviews, and close to 200 applications before I found an offer that paid well enough that I could afford to move to either Toronto or Vancouver: the two places I was targeting.
I spent a full 12 hours preparing for my first interview, making sure all my stories were straight. If they needed to ask about a time I had to resolve a conflict (the answer is always "get everyone in a room to talk it out") or I handled making a serious mistake at work (tell people as soon as possible because the longer you wait the more it costs to fix), I had an anecdote prepared for it. Most companies never asked those, but learning to tell those stories well made me more interesting at parties, so it wasn't all a waste.
Interviewing is a skill I got more comfortable with. For my first interview, I tried to set up a nice workspace with good lighting and took tons of prep. For my twentieth interview I pulled over to the side of the road (I was driving at the time) and took the meeting on my phone. The calls where I was the most comfortable were the most successful.
Rejection was not a skill I got more comfortable with. Being passed over for interviews, or being told I wasn't moving to the next step didn't hurt too much when I was actively working other prospects, but to go from one prospect to zero was like a stone on my chest.
Now that I've been on the other side of the table, sometimes you have to choose between several excellent candidates all of whom would be great additions to the team. In hinsight I like to think that was the reason behind at least some of my rejections, although at the time I took each one as a personal failure.
After each rejection letter, I felt I had nothing to lose by repeatedly bugging for feedback so I could improve, but even when I managed to get them, responses were entirely unhelpful.
I decided "poor culture fit" just means they didn't like me.
"Not professional enough," said some of them. "Too formal," said the others. Somehow I got both.
That sort of feedback is only helpful if it's consistent, but there's so much subjectivity in hiring that your strong traits at one company can be impediments at another. Sometimes I felt like I nailed the first half, but then the technical challenges broke me.
- Given a number between 0 and 1 000 000, write a function that will print it out in English. For example, 613 447 should output "six hundred thirteen thousand four hundred forty-seven",
This was my single least favourite challenge. It's just all edge-cases all the way down. The ones and tens need to be treated as pairs because the teens don't work like the rest of the numbers, and I realized far too late in the process that I should have gone with a recursive function instead.
For one company I had an 8 hour take-home project to build a Youtube Live video viewer with google sign-in and chat. I used S3 websockets and DynamoDB for connection pooling to create a live chat, to which they failed me because "the instructions were to use Youtube Live's existing chat, not create a new one. I didn't even know youtube live had such a chat.
One company wanted me to implement a Material Design style floating action button component in their Gatsby architecture, with an extremely detailed spec full of caveats and constraints that looked like they were assigning JIRA tickets to prospective candidates. After a few hours reading through the spec and planning my implementation I decided the other offers I had received to that point were good enough for me and this was one I could do without.
My favourite interview was from Cannect, the Toronto company whose offer I ended up accepting and still work for today. It started out with a call, which I discovered meant an actual phone call and not a zoom call or a google meet call or a facetime call or any of the other things that other folks had called calls.
The hiring manager was a developer herself, and she started by asking me a few technical questions. Since I happen to excel at memorizing things I could easily google if I forgot, as well as explaining things in tweet-length sentences, I aced that segment.
- What was the difference between an INNER JOIN and OUTER JOIN in SQL?
JOINs are used when selecting data from two tables. INNER JOINs return rows that match in both tables, while OUTER JOINs return rows that match in either.
- How would you describe a Promise in Javascript?
A Promise is a class (as much as anything in Javascript can be a class) that executes a callback, and can trigger other Promises when the callback succeeds or fails.
- How would you describe web development to someone non-technical?
Building a website is less like building a thing and more like building a thing factory. Every time someone goes to your site, a whole assembly line of processes happen to build the website in a way that you can view it, and web development is about creating that assembly line more than it is about creating the website.
We started talking about the product they were building and their goals for it and how the things I had done in the past might tie in to make me useful. They were eyeing up Amazon Cognito for their authentication system and since I had already used that to manage users for my oilfield asset management system, it was strong points in my favour.
And then my phone died mid-conversation.
Do you ever have thoughts like "this is an important call, I need to charge my phone" which are overturned by thoughts like "I'm on the phone now, I should pace around"?
I plugged in my phone, sent an apology email, and sat in misery and my chair for half an hour until she called back. She called back. All was well, and I moved onto the code interview.
It was a take-home TODO app, built in any technology I wanted, with a small set of required features. After the take-home portion, we moved into a live coding exercise where I implemented three small feature requests. I enjoyed this format so much that almost two years later I've given this same interview several times with excellent results.
Being able to see how people maintain their own code they've written is a great signal for a developer who knows what they're doing, and since TODO apps are the de-facto tutorial for everything frontend, it isn't biased for or against people with formal education.
The first live-coding exercise was to add a button that permanently deletes all completed TODO items. I was using React, so the line setTasks(tasks => tasks.filter(task => !task.completed))) solved that in under a minute.
The second exercise was to sort TODO items in descending order, so that new items are added to the top of the list instead of the bottom. I used javascript's native array sort method here. At first, it did nothing. Then I swapped my 1 and -1 and it worked.
After giving this question to dozens of candidates I've concluded that no one remembers how array sort works. Most people sort the wrong way first, like I did. A few try to return true or false instead of positive or negative. Some forget that sort mutates its original array, unlike map, reduce, and filter. To me, this question is an exercise on whether the candidate is able to look up documentation to patch their knowledge on anything they're missing, which is an incredibly valuable skill to screen for.
The third exercise was to split the TODO items into two lists, one for completed and one for incomplete, such that checking off an item moves it from one list to the other. I kept my main list of items and rendered out two filtered versions, one matching where task.completed is true and one for false. I still think this is the best approach. The most common other approach, especially from folks coming from more imperative coding backgrounds, is to maintain two lists and push items from one to the other when adding or marking as complete. That works, but it's more prone to error.
They wanted to do a final interview in-person, to meet with the CEO and team and assess culture fit a bit better, which I declined on account of having already told them I was 5000km away and looking to relocate. A few hours later, I got a verbal offer over the phone that was just high enough I could afford to live in Toronto, so I accepted the offer, drove three hours east, realized I forgot all my clothes in a laundromat in Vancouver, drove three hours west to get them, and then set off across the country for a 45 hour drive.
It took three days to cross the country. I booked my condo viewings remotely and pulled off the highway to view them over Facetime. I stopped in at a hotel to print and sign and scan paperwork because I didn't know about Docusign yet. I was unable to negotiate the keys to my apartment by the time I arrived in Toronto, so it was two more days of living in my car, walking around the city setting up Ontario bank accounts (none of my Alberta banks existed there) to get cheques to post-date for rent, and then one day in a hotel so I was showered and prepped for work.
I should note that I didn't actually receive the physical offer at any time here. I sent a tentative email the night before my start-date asking what time I should be there. Would they tell me they hadn't actually hired me?
"9am would be great", she said.
I don't endorse my own behaviour at all. Get your offers in writing before spending days driving across the country. It worked out for me, but it might not have. I went in at 9, met the team, spent a wonderful first day setting up my equipment, and got the keys to my apartment that night. Two days later I got a mattress and signed the job offer for real.
How has your life changed since learning to code?
When I worked in manufacturing, work was all there was. Everyone worked 12 hour days or longer for weeks at a time, and the money was good, but the work was inconsistent. Work could stop with no notice, and you couldn't use that time to take a vacation because when the next job started, you had to be ready to go immediately. If you weren't, someone else would get your spot and you could be out of work for weeks or months longer.
Since leaving that life I haven't once been on fire, and that's as good a barometer for success as any. This critique is less about code and more about the opportunities afforded to me by working for rational companies with modern employment practices, as well as the benefits of being able to work remotely.
There are entire years of my life where I can't remember doing anything. I would work and I would sleep and in between I would eat one of the five meals I could assemble with my standard set of groceries. Moving to Toronto opened up an entire world of food for me. Becoming a digital nomad opened up an entire world of the world.
Like sports. Sports were always something reserved for professional athletes and gym class at school. I had never heard of a non-professional non-student playing sports, but tennis is fun! The energy I feel from going surfing or snowboarding every morning lights up my whole day, so when I sit down to work all afternoon and evening I can drop right into productive flow with laser focus.
What does a typical day as a software developer look like for you?
In the mornings I go through pull requests and review anything that hasn't been reviewed yet, taking care to spot potential bugs and ensure that the solutions are idiomatic within the greater codebase so we don't take on any unnecessary technical debt. The reviews are one of the highlights of my day, because I get to see how other people approach problems, compare that to how I'd approach them, and either I learn something or I get to teach something. Both are positive outcomes.
Most of the tickets I pick up relate to either fundamental design decisions: how can we implement a thing in a way that's cross-browser, cross-device, accessible, and easy enough to refactor when the requirements inevitably change.
The other class of tickets I handle relate to the financial logic of the application. It was never intentional for those to be my responsibility, but the bus factor grew on its own. I know a tremendous amount about the mortgage sector and how the calculations tie together, and while long term it would be better to spread that work and knowledge across the team, short term I can do each individual ticket ten times faster, so short term has won out an unfortunate number of times. We're actively working on reducing this knowledge debt.
We're using Nuxt/Vue for our frontends, Node for the backends, MongoDB for the database, and a GraphQL layer to tie them all together. It's hosted on AWS with their Kubernetes implementation and we use AWS Cognito for user management.
What’s it liking teaching on Egghead?
The Egghead folks are fantastic, but disappointingly I haven't managed to do anything meaningful for Egghead since joining them. They invited me in during a crunch period at work and I started my digital nomad journey immediately after, so all the time I intended to spend on the computer learning and taking notes and writing content instead was spent on outdoor activities like hiking and snorkeling and surfing and snowboarding. I'm working toward a world where I can do both, but at the moment my responsibility to my team and the company has to come first.
What are your career goals for the future?
I want to dedicate more time to teaching. It's been eight years since I started learning Javascript and I want to get those years out of my head and into a format that's useful for other people.
My dream job is something that exposes me to tons of people working on cool projects in any category that I can learn from and help with. I don't know what that looks like yet, but possibly some sort of coworking community.
You can read my posts on my personal website and find me on Twitter @jacobmparis
Thanks for the interview!
Join a community of self-taught developers - get help with your code and ask experienced developers for career tips in our exclusive voice calls.
Top comments (1)
Do you read any articles before going to a dating site? I ask because I wonder how others do it. Personally, I always think that otherwise you can waste a lot of time on useless sites. This was the case with my friend when she was looking for a dating site.