When I changed careers from lawyer to software engineer at Google, I published 10 big ideas that helped me make that massive transition. Since then I’ve had a ton of questions from people asking me questions about:
- How I taught myself new skills
- How did I know that learning to code at 37 was not “too late”
- How I prepared for big tech coding interviews
- How I analyzed and minimized the risk of career change
- How I worked out that software engineering was “right” for me
- What languages I focused on
- Whether being a FANG/FAMGA software engineer is right for everybody (hint: tempting to think so but I saw plenty of evidence of it not being right for some people’s goals)
Note: I think “FAANG/FAMGA” is limiting, and prefer to refer to “big tech”since there are many highly prestigious companies other than the usual 4-5 everyone obsesses about.
Why I Wrote This Article
Each of those questions I listed above deserve their own article, even though I know our contemporary culture prefers “tweet-sized tips”. However, meaningful skills can’t be internalized from a few hundred characters.
So today I am going to share with you my answer to one of those questions – the approach I adopted when:
- I made that first jump in careers from lawyer to coder at 38, and
- How I prepared for big tech interviews at the ripe ol’ age of 39, with less than 2 years of coding behind me.
If you want me to write on any of the other questions I always get, please let me know! I’m going to put my contact details in this post somewhere, and the only way to find it will be to go through the article. 😊 That is also to encourage you to carefully read this article rather than skimming for a “quick tip”.
Uncovering the Real Goal
I hold the following opinions: getting coding interviews is harder than learning to code. Doing well at the interviews is often just as hard as getting the interviews. Behavioral interviews are hard if you don’t have solid experience – but your competition does.
When I made the switch I had zero coding background. Later, when I set my sights on Big Tech, I knew I’d be competing with PhDs, people who’d been coding since their teens (often 20+ years), and folks who'd achieved a lot more technically than I had in my one brief year’s experience as a developer.
And I had the added challenge of applying for big tech from outside the United States.
So I had to develop a plan that went well beyond just “learning to code”.
First, let me explain why I concluded that “learning to code” is the easy part, even though I’d tried and failed to learn to code 4 times, between 2012 and 2018.
This insight came to me in late 2018, when my startup was struggling. I had lost tens of thousands of dollars building my startup. I had no income for over 2 years.
And I decided to pull out over $40K from my mortgage. Why? I got into a top-rated bootcamp in San Francisco.
I left my family behind, and relocated to the US. I was meant to be there for over 14 weeks, but I withdrew from this top-rated bootcamp in week 1, and returned to Australia.
I had been super excited about the adventure (and scared from all the debt). But I developed grave doubts about the bootcamp strategy. I noticed that my instructors and the program were designed to help people "learn to code" rather than "becoming a coder".
From my experience on the hiring side in 3 other industries and 4 countries, I knew this was a mistake.
Learning to code is just a form of “literacy”. And literacy is not skill.
I was living proof: each of the 4 times I focused on “learning to code” I succeeded in a narrow sense. Whether it was HTML or Java or writing a simple Android app from a book, I always succeeded at learning how to read and write the basics. But I had no idea how to actually build anything useful. I was completely hopeless at applying my knowledge – I had no real “skill”.
In this century we don't get hired for what we know. We get hired for skill.
I quickly saw several reasons why a coding bootcamp was the wrong strategy for me.
This expensive bootcamp would likely give me some basic skills, the kind that may even get me an “entry level” job. But I could see things were going to be rushed, standardized, and focused on "getting out the other end".
I didn't want to "tick a box". I wanted skill. Competence. Confidence.
Moreover, bootcamps seemed to prepare everyone for entry level "junior developer" jobs.
I was 37 and I didn’t want to settle for an “entry-level job” mindset. Plus I don't believe anyone with 3 + years of experience is "junior" even if they're a total newbie in the field.
Then I discovered that several instructors and teaching assistants at the bootcamp were former students who hadn’t yet found jobs. They had never changed careers – many had never had a "career" as such. The job-search counselors had never even been on the interviewing side in tech.
How was I going to learn to do something from people who’d never done what I needed to do?
And then there was geography. Students based in San Francisco had advantages, whereas people coming from other parts of the US did not find work that easily and ran out of money in the long months after graduating and before getting their first job. Heck, I was based in Australia...how was this going to work for me?
I looked at my explicit goal. It was not to "learn to code" – it was to build a career that fulfilled me.
Plus, when researching bootcamps, I could see a path to learning “part time”. That seemed like a much more sustainable strategy to me because I could find a job and learn at night and on weekends. After over 2 years of no income, I needed to have cashflow in order to keep fear at bay, and focus on becoming a professional coder.
As the legendary businessman Harvey Firestone said:
“Having a surplus is the greatest aid to business judgment that I know.”
Having income while studying would give me the confidence to make better judgments. Better judgments are important for a career that is fulfilling in the long term.
I had no doubt that I would "learn to code" if I did 3-4 months in the bootcamp.
But would I learn enough for a good team to pay me money for my skills? I no longer believed bootcamps and online coding websites would help me achieve that.
Learning to code would not get me far. I had to be good enough to beat my competitors who had coding degrees, prior experience and networks. I wanted a career in code.
So I left the bootcamp, wrote off about $9,000 and returned to Australia. Sure, I had gained rudimentary coding literacy to pass the entrance test for the bootcamp. But I was very far from competent.
This analysis may be hard to understand if you’re new to the workplace. Another way to truly understand it is to notice that many of us play music, but aren’t in a band. As my mentor said:
"Michael Jordan didn’t want to learn to play basketball. He wanted to be in the NBA. Huge difference."
How to Use Your Advantages & Disadvantages
That one insight made all the difference. Within 8 months, in 2019, I got all 4 developer jobs I applied for. I simply followed the program I’d developed with the help of my (non-technical!) coach.
Don't be misled though. I had unexpected advantages. I benefited from 2 major advantages that initially appeared to be disadvantages.
This was not my first career change, and for almost a decade, I had been on the hiring side in previous careers. Today I’ve been on the hiring side in engineering too, and the patterns are very similar.
My biggest advantage was that I was no longer thinking about the job market challenge as a candidate. I was thinking about this from the perspective of the hiring manager. That had a significant impact on my plan because I had experience of how hiring managers think – their constraints, priorities, values, business needs, dislikes, red flags...
My experience (age?) helped me understand what impact I could deliver to a team and organization, and to identify the right people that I could learn from, who could help me with ideas, guidance, suggestions and referrals. What was a disadvantage was now an advantage – a career changer's advantage.
On the point of advantages, I want to call out something important.
The easiest thing in the world is to dismiss others for having “killer” advantages. It's easy to shrug and say "Of course – that’s why they succeeded". It’s easy to not notice that everyone has very compelling and serious disadvantages.
For me, my “disadvantages” were:
- Geography – I don’t live in the US or one of the other tech hubs
- No formal computer science qualifications
- Zero technical background
- A mortgage and financial responsibilities
- My “age” – learning new skills when you’re pushing 40 is harder than when you’re 25
- Cultural and social expectations, judgment, negativity
- Recruiters and bosses being younger than I was and uncertain of how to deal with me
- Compared to other candidates, people viewed my change as very, very “risky”
- I was going to earn less in engineering than I would as a lawyer
Every day I hear from people who let any one of these things stop them. While I cannot comment on whether or not they’re real reasons, I can say that if we argue for our limitations, we get to keep them.
Clinging on to our disadvantages does not help us overcome them.
With the help of my coach and a ton of mindset/psychology training, I was able to dig into my disadvantages and convert a few of them (not many!) into major advantages. And that’s when I realized that my experience with how interviewing, recruitment, and resourcing works would help me a lot in formulating a strategy.
Priority one: career change
When learning to code and intentionally setting the goal of becoming a professional coder, I found that I kept switching to short-term thinking and obsessing about my first role.
I wanted my first role to be glorious, to prove all my critics wrong, to pay me a gazillion dollars and save me from having to deal with self doubt and struggle for the rest of my life.
But I had to train myself to view things differently. My first role must be one that makes me learn and grow, and set me up for future success no matter what happened. It needed to pay fair market rates, but I was happy to take a slightly lower salary if the team was fantastic and the growth/learning was solid. It did not need to be my dream job.
I was very explicit in the tradeoffs I’d make:
- Team matters more than brand
- Team matters more than money
- Brand matters more than money (as it would set me up for future opportunities)
- Money matters more than stock (this was for my first dev role, as this would make my continued learning plan sustainable, even though stock may give me more financial upside)
- But, learning mattered more than brand or money – as learning more would save me time which is better than saving me money
- I would not trade off between team and learning. I needed both (but I was more likely to get reliable signals on the team than I would on the actual learning/growth I’d get on the job)
“Nailing it” or being comfortable was not a priority. My priority was to successfully change careers.
Accepting a rubbish coding job (and there are plenty of them…) would not be a “successful” career change for me. But equally I didn’t have to get into big tech (ever) for my career change to be “successful”. This was very personal – success to me meant loving the work I do and learning a lot doing it. Period.
How I Made a Customized Plan
After analyzing my advantages and "convertible" disadvantages, the next thing I needed to develop was a customized plan. I needed one that was tailored to me, that I could believe in.
I needed a plan that took into account my specific context, which includes my temperament, experience, beliefs, values, goals and skills.
Note that I’ve still not talked about the technical interviews, the algorithms and data structures, and so on. When developing my plan, I had to focus on all the many pieces that had nothing to do with my coding skills or technical capability.
It would also need to account for my psychological “runway” – how much time was I prepared to invest in this career change, before I’d give up, lose hope, or change my mind? I could not answer that without understanding how long it was going to take me to learn the minimum required skills.
To understand that, I needed to research and analyze what the minimum set of engineering skills that the market would value were.
And to understand that, I needed to analyze the dozens of engineering domains in the market, and which ones would suit my temperament, interest/passion and advantages. And from that analysis I’d need to pick the domains that I would focus on and exclude all others.
I'd have to find the overlap between my interests, my ability and what the market valued.
Again, my experience on the hiring side of the market gave me some (small but important) advantages. I knew that pure technical skill would not be enough – that’s just the starting point. the “invitation to the dance”.
I also knew that good teams don’t just hire for raw technical skill, they hire for essential non-technical attributes as well. What those traits are depend on the technical domain, the team culture, the current composition of the team, and so on.
Yes, you're right. A custom plan is extremely multi-dimensional, and getting things right is only moderately helpful, whereas getting things wrong can result in a giant loss of direction and waste of time.
Since I was almost halfway through my career, I was determined not to repeat past mistakes. I was going to be:
- Highly specific in my goals.
- Highly intentional in my choices and actions.
- Focused on what I wanted, paying no attention to the things I did not want.
- Willing to change myself, my habits and negative beliefs, so that I could change the world around me.
- Ready to focus on building a rewarding and fulfilling career rather than just “getting the next job”.
- Ready to focus on delivering value for my future team rather than a “what’s in it for me” mindset.
- Willing to play the long game – think in 5-10-25 year horizons rather than the next few weeks.
I must confess, doing these things consistently was much harder than I anticipated. I slipped up a lot, especially on the first three. But since I had my custom plan written down, I let that be my guide and the sole source of truth for what I needed to do.
My plan required me to focus on fundamental programming skills, and then narrow it down to the segment that I felt matched my long-term goals and skills. For me, this was web development. This meant completely and ruthlessly avoiding all the “shiny new things” and doing things like Python or Java.
And tutorials and endless videos were not going to make me beat the competition. I calculated that the minimum set of skills I’d need to develop for my city would require 900-1100 hours of focused coding, practicing the right things in the right sequence.
Preparing the plan took several weeks. I kept refining and strengthening it and didn’t rush it artificially. I am very inspired by Abraham Lincoln (another lawyer who changed careers!) and he once said “Give me six hours to chop down a tree and I will spend the first four sharpening the axe”.
I was so tempted to dive right into my plan and get “busy” but I’d learned that being busy was so not the same as being effective. Once the plan felt as complete as it could be with the information I had at my disposal, I turned to executing on that plan, with total focus.
This meant a lot of sacrifice, and many, many days of self doubt, battling the temptation to switch, and learning to manage my energy. I developed some amazing habits during this time, but they were only obvious to me in hindsight. During those 6 months of work, I was constantly assailed by uncertainty, fear and occasional loss of hope.
Later on, I adapted this planning process to create a plan for Big Tech and especially for Google. That plan took another 500-600 hours of intentional study that was completely different from my plan to become a developer. More on that later.
Early Results, and then…Google SWE
Another lesson I’d learned from 4 years of trial, error, and failure was that I was very likely to change plans midway, switch resources, courses or focus.
This is a much more serious problem than we realize because every time we switch focus or plans we throw out the hard work we’ve done, go back to square 1 and…start…all…over…again.
Imagine if you were driving from A to B and kept taking U-turns and going back and restarting. You’d never get anywhere.
But I’d made myself a promise (it’s easier to keep a single promise than to keep a bunch of them!): I was going to complete my plan and then decide whether I would keep going. This time I wasn’t going to stop until I completed my plan.
I didn’t have to like doing it. I just had to like the possibilities that lay at the end of doing it.
My plan had a specific time when I would start interviewing even if I didn’t feel ready for interviews. But to get to that stage I had to get good at generating interview opportunities.
Again, my past experience in other careers helped me. I applied all my learnings over 18 years and secured 4 interviews within a few weeks, and got all 4 offers even though there were plenty of candidates with more experience, skill, and qualifications than I had.
It wasn’t because I was better at coding. I don’t see how that could be, given that I’d only been in the game for a few months.
I believe I got all 4 offers because during the interview process I demonstrated that I was a better candidate for the hiring manager. This approach was critical in how I presented myself.
Getting the offers is great, but I had an unexpected problem. Since my plan required me to be highly intentional about the kind of work I’d pursue, all 4 roles I’d applied for were the ones I really believed would be a fantastic start to my new career. How was I going to choose?
Yes it’s a great problem to have, but that doesn’t make the decision easy!
To resolve this problem intelligently, I learned to ask myself a very important question:
Do I know this or do I simply think this?
Very often we make decisions based on assumptions and beliefs that are completely untested, and we mistake our opinions or fantasies for reality. What we actually know is way less than what we believe without truly knowing.
Being intentional required me to focus on what I know rather than what I wished, or merely thought. I had to either find evidence to back my thoughts, or disregard thoughts for what I knew.
That framework developed my analytical powers and helped me choose the right first role in early 2019. I turned 39 around that time.
Till today I continue to use this know vs think framework in my personal decision making as well as in my engineering decision making. I find it to be an excellent framework for analyzing tradeoffs in complex decisions.
Looking back, I learned a TON about sticking to my plan, revisiting my goals, self-awareness and practicing being intentional.
A few months into my new role, I noticed that a lot of lawyers were starting to reach out and ask me how I did this. Curiously, many of them were people who insisted I was making a huge mistake and that wanting to learn to code at this stage was immature and foolhardy.
Now they wanted to “learn to code”. And that made me think.
What else have others said is “not possible”? Do they know that or do they just think that?
And my goals hadn’t changed. For me learning, growth, and team were still more important than brand or money. But I was almost 40 and I also wanted to explore life in a way that I’d never had the courage to do in the first half of my career.
So I decided to set myself a stretch goal: I was going to find out what being a software engineer at Big Tech was like. I’d worked in huge companies before and I knew that it isn’t for everyone – that’s the reason I went into startup and smaller companies in the first place.
But wouldn’t I learn and grow SO much by being surrounded by some of the “best” people in their field, from engineering to product and sales? Did I know this? Or did I just think it?
I did the research and found that on average people were happy in Big Tech. But I also found that most people were not as intentional as I was. So I confined my research to people who were very intentional about their careers. And they (almost universally) said they grew a lot from Big Tech, even if they decided to leave. Leaving Big Tech was also intentional, in pursuit of their end goals.
So I decided to try for big tech (including 3 of the FAMGA companies) and several others, in Silicon Valley, New York, and Seattle. I was still based in Australia, so this was a massive challenge.
I re-designed my plan. Several of the steps were the same but the coding curriculum would have to be massively overhauled. I also needed to find out how US big tech recruitment is done, and be worthy of a referral.
About 7 months later, I started generating interviews. I worked very hard to prove myself worthy of referrals for those 7 months, and people offered to give me referrals based on my efforts and proven commitment.
I got referred to Meta (it was called Facebook then) but I didn't get the interview as my skills were not the right match. This was a massive learning for me as I thought I’d been careful to only apply for roles where my skills matched – and I was wrong.
That was when I realized that sometimes the position description is written in ways that mean one thing for the hiring company but means very different things outside that company. This is because different organizations use the same words to mean different things. Both the hiring side and the candidate side can be unaware of this!
All these learnings added up. Within 3 months I got offers from 2 big tech companies, and missed out on a third at the final interview because I just didn’t know how to write a filesystem from scratch (I didn’t understand much about the Linux world at all!).
And then I got an offer from Google.
Again, I was faced with a very difficult decision. Google is a cultural force that is very hard to be objective about. But I really wanted to stay true to my goals, my plan, and my intentions.
Trying to separate what I knew from what I thought was EXTREMELY hard when it came to Google. But I was absolutely sure about one thing: the team I’d interviewed with were amazing people.
And this is where I believe luck matters. No matter what people say about skills, brains, smarts and all that stuff, luck and "magic" have a role in life.
My interviewers from Google were friendly, kind, cheerful and highly focused engineers. They were not looking to prove I sucked. They wanted to help me prove I was good. They answered my questions with enthusiasm, and I felt like collaborators from the first minute.
Is this a Google thing? Maybe. But later, when training to be a technical interviewer at Google, I witnessed a very wide variety of interviewer/hiring manager styles and beliefs. I saw candidates with great skill losing their nerve, struggle to communicate their process, and so on. And I came to appreciate the role of chance in all this.
So yes – I was lucky that I had the kind of interviewers I did, and that on interview day I happened to know how to work through the code.
This is also where my ultra-focused preparation on type of work and relevant skills paid off. There are a very large number of engineering roles at Big Tech that I would never have been suited to (like the one at Meta). Even with my prior experience in other careers, I had no idea how HUGE the engineering world is, and how many flavors and types there are, and how hard it is to tell them apart.
By forcing myself to be highly intentional and not randomly and blindly applying for big tech engineering roles, I improved my chances in small but important ways. I dug deep into each role and researched them carefully by speaking to friends in the industry (again – my age and experience was an asset because I had built relationships over 15+ years never expecting that they’d be so useful later on!).
For each offer I got, I had researched the role deeply, and prepared for the technical interviews well. On interview day the stars were aligned, and things worked out. Though I don’t think I “nailed” my interviews, I did well enough to communicate that I was a suitable candidate for the team’s needs.
Which leads me to the question: How did I prepare for the Big Tech interviews?
How to Prepare for Big Tech Interviews
Answer: In two phases that took me over 500 hours to execute.
Phase 1: Learn the Realities and Competitive Landscape
If I wanted to tackle Big Tech, from another country, with less than a year of industry experience, and 15+ years in an unrelated career, with no Computer Science degree, I needed to have a very clear view of the realities, especially the competitive landscape.
This means there was room for informed hope, but no room for dreamy-eyed, pie-in-the-sky magical and wishful thinking.
Hard truths (see my initial YouTube Videos on this here). Hard realities. Hard work.
I had to fully internalize and appreciate the following:
- Coding is just the starting point. Not the ending point. Learning to code was the first step of many, one small piece of a much larger puzzle. In other words, it is necessary, but not sufficient to get a coding job (and especially at big tech).
- My biggest enemy would be my own mind. It would either let the negativity of others get me down, or it would turn against me and undermine my own confidence. I had to build the habits that would help me have a resilient mindset. I focused on recovering from setbacks rather than avoiding them.
- My competitors would likely not be career changers. Or if they were, they’d be from closely related fields like computer engineering, mechanical engineering, or electronics engineering. The vast majority would have technical qualifications, maybe even PhDs (this turned out to be true!), and several years of industry experience.
- As an outlier and a “wildcard”, the hardest part would be getting the interviews. Learning algorithms and data structures would be easier. And “cracking the coding interview” (whatever that means…) would be easier too. Why? Code is deterministic – identical code generally produces identical results. But life is not deterministic, and getting interviews is highly subjective. In the job market, identical actions do not produce identical results.
- I needed to shape myself into the kind of person seasoned engineers would want to work with
- I assumed most of my competitors would have at least 3 -5 years of experience. I couldn't catch up with them, let alone overtake them. Instead, I needed to outperform them on non-technical skills and compare favorably (if not outperform them) on the technical stuff.
- I had to communicate better than the others. If I didn’t know something, I’d need to say so and then communicate how I’d solve it if given the right time and opportunity. I also had to communicate to show interviewers that I understood their business needs and wasn’t just focusing on my selfish dreams.
- Which means I had to really work on understanding what the hiring team valued, was looking for, wanted, and needed.
- I could not control my competitors (their skill, their performance, how much they knew, and so on), or what my interviewer was thinking, wanting, what they valued, or whether they liked career changers or not. I could not control most things. I could only optimize my effort, my focus, my psychology, and how much learning I extract out of each experience, good or bad. I could only control my choices and actions. So focusing on anything outside that would be a waste of precious energy.
- I had to accept the role of luck. Jordan, Tendulkar, Federer – they’ve all had bad days. I would too. Or maybe I'd do great, but on the day someone else would do better. Or someone else would just be a better fit for what the team needed. No harm, no foul. I’ve made those hard decisions on the interviewing side countless times myself, so I know how these things work.
- If I was successful at more than 1 offer I would need to pre-think and pre-agree with myself about what signals and factors I would use to decide (I’d learned from my experience of choosing between my first 4 offers!).
If you’re wondering how I knew how to do all this…I didn’t. Not all at once. What you’re reading is a summary in hindsight. But I had to work most of this out in “real time” based on “first principles thinking”. And I worked with my mentor to tighten them up as I went along. It took a lot of time and I was so impatient to “start coding”. But …I knew what advice Abraham Lincoln would give me…
Phase 2: How I Chose My Learning Resources
I know everyone thinks there is a secret “magic bullet” out there. Some blog, video, resource, tutorial, podcast, PDF cheatsheet…something…that will unlock the entire “secret” and make us instantly learn things.
Nope.
I’ll bang on about this till the day I die – information is a commodity.
Learning is hard, but it’s made much harder because there is too much free information.
We all fall into the trap of thinking there is some missing piece of information. There isn’t.
Why? Because no matter where you live, what language you speak, what color your eyes, skin, or hair are, what gender you identify with – all resources are going to teach you things that “work”. They’re all “the same” at a very fundamental level.
They have to be, because that’s how computers work.
If you and I write an identical function in JavaScript or Python or Java, we are going to get identical results. That’s how computers work – they’re deterministic algorithms.
But life (and interviewing) is most decidedly not deterministic. Identical effort, grades, skill, intelligence will not produce identical results.
Again, I had to teach myself to learn. I had to teach myself to shift my attention away from resources/blogs/websites/courses and put my attention on building solid mental models, identifying relevant skills, drilling down on concepts rather than code implementations, applying what I already knew in new ways, reasoning, problem solving, and communicating my reasoning while I reasoned.
Now you’re going to be surprised by the resources I used for my Google and other Big Tech interviews.
Yes, I used Leetcode, Algoexpert, InterviewCake and Jenny’s CS Lectures and perhaps a few others. But I didn’t complete a single one of them.
This wasn’t because I switched or lost focus. I was being intentional. I realized that they all teach the same thing, but with slightly different styles and content. So I used these resources to learn concepts and mixed and matched all these resources based on my analyses of interview patterns.
My reasoning was simple. Having been on the hiring side, I know that every year the quality of candidates (at good companies) improves. I personally think that focusing on the company is a huge mistake – we should focus on the team, people and kind of work.
But the world works a certain way, and because of that, everyone rushes to the big companies. This increases competition which makes it harder for hiring managers to assess candidates.
The only way for hiring managers to deal with this is to raise the bar, making it harder for candidates. The overall number of candidates keeps increasing, but the “pool” of candidates that get invited to the interview stays within a narrow range – usually 2 -10 people. Regardless of how many hundreds apply that’s about the number that will even get a chance to interview.
Therefore, the number of candidates that don’t hear back or meet with rejection increases, especially in bull markets.
If the competition is increasing and the resources on the internet are also increasing, but the shortlisted number stays more or less constant, then “learning more” cannot be the solution. Everyone is “learning more”, so relative to the competition there is no change.
I also realized that Big Tech would have lists of interview questions (this is “efficient” as interviewing is very time consuming, and so it makes sense to save time by having a question bank that interviewers could use). Naturally, they would not use these questions if they were “leaked” – that would defeat the interview process.
So, logically, hiring managers will not ask questions that are available on Leetcode or Algoexpert or other sites. This produces a kind of “arms race” – the more questions are made publicly available, the more questions in the question bank are changed. That results in more innovation and variance in questions and hiring strategies.
This left me only one choice. I had to learn to solve problems using mental models and by classifying them. Chances are I was never going to be asked to sort a Linked List or to implement Dijkstra’s shortest path algorithm. Instead, I would need to know how to apply these sorts of algorithms to “real world”, practical problems.
Often real world problems don’t look, sound, or smell like the practice questions we study. Practice questions and competitive coding questions tend to be “neatly” packaged up with clear constraints.
But as an interviewer, I wanted to know how the candidate thinks, reasons, analyses, interprets information, and collaborates. Solving the problem is a bonus. Often they have the right solution but run out of time – but ask great questions and clearly know how to tackle the problem. These candidates can still get the offer.
Later, as an engineer at Google, I could always tell if someone knew how to solve something even if they were unable to solve it in time. Equally, it’s immediately obvious when a candidate does not know how to solve something (and that's OK – we are all learning).
By adopting my approach of understanding problem types and solutions rather than specific code implementation, I could focus on learning to reason rather than learning to write specific algorithms.
This approach meant that I completed less than 40% of Algoexpert (and back then it had half the questions it has now). I also did maybe 50-60 questions from Leetcode and most of them weren’t the “hard” ones.
I figured that “hard” questions would probably show up in 45 minute interviews about 20% of the time which means 80% of the time they’d be easy or medium questions. So it made sense to optimize for the 80% given I was still relatively new to engineering and the hard problems would get in the way of understanding easy and medium ones.
I used these resources to recognise patterns rather than just “complete” and get a certification. That’s why I didn’t complete any of them. And no, I didn’t use “Cracking the coding interview” either.
Along the way I also started a systematic process of understanding system design questions. I documented system design preparation in a long form blog on the essential concepts for system design interview questions.
I also decided to focus on one language: JavaScript. It wasn’t the best for interviewing (seasoned engineers discourage it on Quora and elsewhere) but I didn’t see how it mattered. The purpose of the interview was not to test my choice of languages – it was to test my ability to think abstractly and solve complex computer science-y problems.
The language is just a tool (another core belief I hold). In fact, using an untyped language like JS would give me opportunities to talk about its limitations or strengths, which is an opportunity to demonstrate that I understand the tradeoffs in language choices. That way, I could showcase broader knowledge and insight without actually having to implement it all in code.
But a lot of the resources I learned from used Java or C++. These languages are the dominant languages at Google. So being forced to read these languages and understand the principles forced me to not focus too much on “spitting out the code” and more on reasoning through the code so that I could write it.
That was my entire plan. Practice, Pattern Recognition, Mental Models/First Principle Thinking, System Design, doing fewer things really well, and focusing on getting interviews rather than just learning more code.
How to Stand Out During Interviews
As I mentioned, we all have advantages and disadvantages. And we all think our disadvantages are special and huge and our advantages are common, unremarkable, and probably not of much use.
This is not true. Logically, if we all think our disadvantages are severe, then we should all succumb to them. Yet some people overcome them. Only to find that others had it even worse and overcame those.
It’s way better to focus on what we can do well. For me, I truly believed that I could add a lot of value to the team. I don’t care about being the smartest or the best. But I care about being an outstanding learner, and maintaining my growth mindset at all costs.
And so I tried to use this to stand out as best I could. I learned to ask really good questions of recruiters, interviewers, and hiring managers.
But there was a deeper reason for this. Asking good questions was my way of interviewing the company. Like I said, I didn’t want to repeat the mistakes of the first half of my career. So asking really good questions was important for me to assess whether the company was a fit for me and not just the other way around.
Since I had decided that I was going to value the team and the learning over all else, I never asked about the compensation until the recruiter raised it. It was going to be lower than what I earned as a lawyer anyway!
Instead I focused very hard on learning about the team, its dynamics, its group beliefs and values, how the manager solved problems (especially people problems), what the team was interested in, what the company division was interested in, how its balance sheet was doing, what its strategy was, what its resource allocation and budgeting looked like, and so on.
All these things were things I'd learned in other industries, as an individual contributor, as a manager, executive, founder and so on.
And all of these things also showed that I was being highly intentional. I was genuinely interested in the team, and the company, its product and its future. This wasn’t just another job I was applying for. This was active and personal…not passive and opportunistic.
And I believe that helped me stand out. Maybe not for all the roles I interviewed for, but for many of the offers I got.
When I was on the hiring side, I’d always prefer candidates who were genuinely interested in the role, the people, the product and the company. Those that showed up just “to get a job” didn’t have the kind of energy and drive we wanted.
Interview Planning and Strategy
The last aspect of my roadmap required me to deeply understand the different types of coding interview processes.
This included technical and non-technical interviews, the format of interviews, the way companies organize them, run them, plan them, staff them, evaluate them, and weigh them. But it also required me to understand my strengths and weaknesses.
When going for Big Tech in the US I was aiming for 2-3 interviews per month – a huge goal given that I was not even in the US and was in a timezone that was 17 hours ahead of the west coast.
I had to plan and structure interviews at weird hours so I could accommodate my day job as a developer and also my study time. Some interviews took 6 hours, some took 10 or more. Some were “pair programming for a day” type interviews.
All this took a ton of planning, and mental training. I had to be careful to get the right sleep, the right exercise, maintain my mindset and confidence, deliver on my day job, be there for my family, study and maintain focus on my goals.
For this, I had to be honest with myself at what I was good at. For example, I am not a morning person. But I can endure late nights. So I structured interviews, work, sleep, or even exercise accordingly.
There were some interviews that were scheduled at 2am or after, and I wouldn’t sleep before (as I really am not good at waking up on time!). So I’d do a full workout at 1am to get my energy and focus up, then interview, then sleep till 10 am, then go to work and manage my schedule accordingly.
I would also be careful to plan interviews so that I wasn’t doing two of them back to back unless they were very similar and time bound. For example, doing a take-home test and doing a timed test in the same week require different planning from doing a take-home and a live-coding interview – all while managing work and family.
To schedule the interviews appropriately I’d work closely with the recruiter and be very transparent with them. This had two advantages: I gained credibility and trust with the recruiter for being collaborative and communicative, and they also got to see that I had other opportunities going, which increased the value of my candidacy. Competition is a good thing.
Concluding Thoughts
I am sure many of you were expecting this article to give “insider” tips and a specific set of languages, and DSA questions to learn. I believe I’ve given you something much better. Rather than giving you fish, I am showing you how to fish.
Apart from the ethics of it, insider tips are of limited value, especially in Big Tech. In huge companies things can be vastly different from team to team and city to city. You need to understand the principles of recruitment and career development, rather than just the specific languages and algorithms. Assuming that all interviews are the same is a big mistake.
And as for our obsession with data structures and algorithms…managing your career is the ultimate algorithm. Your mind is the ultimate data structure. Learn how to work with both and you’ll always do well, despite the occasional failures. Powerful ideas aren’t grandiose – they’re elegantly minimal.
If you have read this article you will have noticed some of the things I linked to include multiple ways to reach me. You can also get invited to my webinars, mini-courses and newsletters if you want to go beyond just “learning to code” and learn how to build a career that is right for you.
Perhaps the most important message I can leave you with is that it is a mistake to obsess about big tech. Yes, they’re great to be part of, but if we believe they’re the only thing that is right for us we will miss out on all the other amazing opportunities.
Big Tech has glamor because of cultural trends these days. Sure, it’s nice to work for a great organization, but plenty of great organizations are not well known. Plus what is “great” for one person is pain for another.
Your number one priority is to be happy, fulfilled, and live the life that you want. This is not derived from a company. This comes from the people you spend time with (especially colleagues) and the kind of work you do. Big Tech companies have their share of bad managers, teammates, and work, just like any other company.
If you build skill, stack a great plan on top of the right mindset, and train yourself to set the right goals, you can achieve much more than you dreamed of – with or without Big Tech.
Post Script
If you would like to learn more about my journey from lawyer to software engineer, check out episode 53 of the freeCodeCamp podcast and also Episode 207 of "Lessons from a Quitter". These provide the blueprint for my career change.
If you are interested in teaching yourself to code, changing careers and becoming a professional coder, or becoming your own technical co-founder, please reach out here. You can also check out my free webinar on Career Change to Code if that is what you're dreaming of.