There are a lot of things I’m grateful for, in the arc of my career thus far, but I will never be thankful enough for the breaks that have really changed things for me: and to be honest, I have to take some credit in letting those breaks happen.

When I was younger, I had a huge amount of confidence in my skills and my capabilities. I had a healthy respect for what I could do, but my own youth blinded me to the possibility that I may not be good enough, and so I had a lot of the brashness and braggadocio that slowly disappeared with my age and experience. I knew I was good, and I knew I could hack it. I came into my twenties, confident that I could write code with the best of them.

I did have my doubts, don’t get me wrong: in applying for my first job, I also knew that I didn’t have a college degree, that at that moment in time no sane employer would take a look at my resume and see capability; there was nothing there that said “this guy can hack it.”

But, one employer took a look at me and gave me a shot, and I’ll be forever grateful for that single break that got my foot in the door and gave me real world work experience. I do recall that fateful call on my cellphone, from a then-unknown number, telling me that I got the job. Here’s my chance, I told myself. I had the chance then to actually do what I was itching to do, and to prove to the world that I could do it.

Looking back at that moment, I can say that it was a very lucky break for me; but I wouldn’t have that break had I not at least tried to apply for jobs that seemed out of my reach and that I looked to be unqualified for, at least on paper. Don’t get me wrong: my first employer, and the guy who interviewed me in particular, my first boss, were definitely gambling on my skills. But if I didn’t attempt to wow them, if I didn’t try out in the first place, I wouldn’t have had that lucky break – and it is a lucky break.


If it weren’t for that one big break back in 2003 I wouldn’t have had such a rich career, and hadn’t met a lot of great folks along the way, I always tell myself. That single event was indirectly responsible for a lot of things.

But as I said earlier: if I hadn’t applied, I wouldn’t have gotten the break in the first place.

As I grew older, that lesson never really stuck – not until fairly recently. I became more timid, and less confident in my abilities, the more I learned of the world. Sure, it was heady to actual learn things: to have the feeling of being a complete beginner at things, and to grow from there.

I remember a moment, a few years back, when we were building our own company. We were doing consulting work for a couple of years, and I thought at that time that we should really switch gears and allocate a few of our engineers towards building product. Take the hit, and the risk, in these engineers being pure overhead for the next few months: the reward would be a potential steady (or steadier) stream of income, which would pay itself off soon enough.

At that moment though, I did not have the same bravado or confidence I had in 2003. I knew the risks, and the risks weighed more heavily in my mind. Maybe I was braver then because the risks were light, compared to this moment when they had more import; or maybe the risks felt heavier because I did not have the same confidence.

In any case, I did not push for the switch, and in hindsight I should have been more forceful and more aggressive and more confident. The risks could have been mitigated anyway; there were ways to structure things to limit the costs involved.

Hindsight is always 20/20, and so we must always move forward and learn.

In any case, I took that lesson more to heart the past year or so, and have decided to take chances more in my career – albeit in a way where I’m aware of the risks and can mitigate them.

Rolling The Dice

So, sometime in October last year, I was chatting with a friend of mine who worked at Google. That chat eventually turned into me sending him my resume and applying for a position in Google, an application that I didn’t pass, but led me to trying other places, and getting a job at Amazon: but I’m getting ahead of myself.

There are many reasons for my wanting to apply at Google, or at tech companies abroad for that matter, where I would likely be competing against the rest of the world. The biggest reason is I needed to prove to myself that I have what it takes to be a software engineer at these companies, that my skills were at par with the rest of the world. In a way, I felt like I was in my twenties again: the same brashness, but now tempered with the reality of a decade or so of doing the work, and having an acute sense of my own weaknesses and failings.

I also knew I was going into this with a huge handicap: I did not have a university degree, and my background in computer science is mostly self-taught. Sure, I know what a linked list is, or what heaps and trees are used for, but my knowledge of a lot of other computer science topics is pretty limited. I barely know enough of red-black trees, I vaguely understand what Djikstra’s algorithm is, and to be honest I wouldn’t be able to code A*1 (much less understand it) unless I had a cheat sheet. I would be competing against other engineers who, in some cases, had PhDs in computer science. I would be competing against the multitude of people who, in one way or another, are better than me.

A part of this I’d like to believe is impostor syndrome talking, but I have to at least try to be honest with my assessment of my skills. So, why undertake such a task that had such slim chances? Because it’s there; nothing ventured, nothing gained. The downsides are small, the rewards great.

And if I were honest: that’s the whole point of taking this particular leap. Sure the downsides were slim: but so was the chance of my getting in.


I had to prepare, of course, for the mere possibility of getting an interview, and I did it in between my freelance work, during whatever freetime I could block off.

I asked a couple of friends of mine for tips on preparing for the technical interviews, including my Google engineer friend. Admittedly, Google’s interview process is stricter, and they lean towards a higher false negative rate in their process, but there would be commonalities in a lot of places, especially in the kinds of things interviewers would be asking about.

One of the ways I prepared myself was to strengthen my knowledge in my weak areas, particularly certain data structures and algorithms – trees and graphs, sorting algorithms, those bits and pieces I never really had to deal with directly in my day-to-day as a developer locally, and which I only knew from my own study: I had never had formal training. For instance, I read up on merge sort2, and tried my hand at implementing it so I at least had a better understanding of it. I tried to cram as much information as I could, to try to give structure for what I knew at least experientially.

For the most part, though, I did problems on HackerRank, which helped a lot in exercising my problem solving skills, particularly in the application of those data structures and algorithms. I also brushed the dust off my Project Euler login and did a bunch of problems there as well.

I spent a few hours a week doing problems on both sites. I’d also do some reading on various basic data structures and algorithms, some of which I already knew (hash tables are easy once you understand why hashes work), and some I had never encountered directly before (heaps? I knew what a priority queue was, but I never had to implement one before). I relearned a bunch of sorting algorithms, implementing them in Python and sometimes in C.

Anxiety Is A Bitch

After sending out my resume to my friend, I got an email from a recruiter at Google, which got things rolling. First came a couple of phone calls to assess that I wasn’t bullshitting them in my resume, that I actually knew how to write code, at least. And then came the schedule for the first technical phone interview.

As I understand it, a lot of companies go through this step: they have one of their engineers conduct an interview over the phone (or over VoIP nowadays), with the goal being to assess base skill level, and whether or not the candidate is someone worth taking a look at more deeply. In any case, I completely flunked this particular phone interview.

To be honest, the interview problems the engineer from Google asked me to solve were not too difficult, and I did have enough time to do them in. What got me in the end was my own anxiety: here I was, talking to someone from Google, one foot in the door, and I felt scared that I would fuck it all up. I started doubting myself as I talked through my own solution; I started worrying that I was wrong, instead of focusing on solving the problem at hand. My own anxieties ate at me, and at the end of the phone interview, I knew I did not pass.

By the time I got an email from the recruiter about my results, asking for a phone call with me, my heart sank. I knew this would be the rejection call, even if there wasn’t anything to indicate it as such. And I was right this time: the recruiter told me that they had decided to go forward with other candidates.


I still felt that, at the end of it all, I had achieved something. At least, I told myself, this was some evidence (anecdotal!) that I might be good enough.

So, I decided to move forward with my other applications elsewhere, and one application in particular to Amazon AWS.

If anything, having friends at the companies you would like to apply to is a huge leg up to getting in: it helps boost your resume among other candidates, compared to a throwing your hat in through the company’s job portal. I’m thankful that I had that advantage, however miniscule; the rest would be up to me. I messaged my friend at Amazon, who promptly referred me to internal recruiters.

I applied particularly for an SDE position at AWS in Sydney, and a few days later my resume was seen by one of the internal recruiters, who emailed me. I had to pass the first gauntlet: the recruiter screen.

This wouldn’t be terribly difficult, I thought to myself. At this point, my inkling was that the bar wouldn’t be too high: just a demonstration that I actually knew how to solve a couple of problems and write actual working code.

I was wrong.

I had 90 minutes to solve two problems, through an online system similar to HackerRank: you provided the source code, and submitting your answer would run it against a set of internal test cases — you would then find out whether you passed or failed for a particular problem. The feedback loop was fairly quick, but the problems were fairly involved. Again, anxiety reared its ugly head, and although I was able to write solutions to both problems, both were slightly wrong: I spent too much time trying to fix problems in my solution to one problem, banging my head against the proverbial wall, that I did not realize I misread the problem altogether, and that I had the right solution for the wrong problem3.

Again, afterwards I felt partial defeat. I felt like I screwed it up, and I pretty much told myself that this might be the end: I did not feel like I did my best, but I still held out some hope that maybe I didn’t really mess it up.

So, when I got an email from the recruiter saying they wanted to schedule a phone interview, I was elated, and some of my confidence returned. Maybe I have a shot at this, I said to myself. So I prepared even more: I spent an hour every night doing one or two problems and reading up on more algorithms and data structures. I still didn’t quite understand what a heap was, but I now knew the shape of it: how it’s conceptually supposed to work at least.

So fast-forward to two phone interviews, and a whole-day marathon affair of interviews, I get The Call4.

As it is now obvious, I’m on the other side of the divide; I got the job. Not without some trepidation, anxiety, and preparation: but all in all, I’m glad I did take the leap. There are still moments in these past two months where I still feel like I’m in over my head, but those moments are tempered by excitement and by the fact I’m here.

  1. Yes, I know what A* is, and I have a vague recollection of reading about it in high school when I was interested in writing a game engine. No, I would have to read up on it now to understand it enough to implement a version of it. 

  2. Funnily enough, I had apparently implemented merge sort for one of my classes back in college; that code was in C, and is barely readable, so I’m not posting it. 

  3. Short version? I was solving the problem in reverse: the question asked for a solution where I would be coming from the left of a given list, but I solved it coming from the right. In other words, I misread a bit of the problem, and had I not wasted time there, I could have solved that particular problem in the 45 minutes I had for it. Always read and re-read the problem; lesson learned. 

  4. Technically, I got The Email first, scheduling for The Call – but you get the point. 

Previously: Emacs as a Java IDE