Apple: My Post Mortem

In various posts in the past I have mentioned my fascination with Apple as a company. Starting in the early 90’s when I was given a Macintosh, and then the various books and movies I have read, all giving Apple a bit of a mysterious aura around it. I remember flying to Apple HQ for my interview back in 2015, on the plane I was watching Pirates of Silicon Valley. A oldish movie about Apple and Microsoft in the 80’s and 90’s. I still love that movie, just really entertaining for someone like me. Around the same time I was watching Halt and Catch Fire, which has a similar if completely fictional feel to the tv series. I loved the idea of joining a company that started the computer revolution. It is why I loved startup’s so much, you were building something new, something that could become the next big thing. After not hitting it big in startups for around 15 years I thought it might be a good move to make to a large established company like Apple. Apple wasn’t the plucky little startup of the 80’s, the struggling established company in the 90’s or the company of the 2000’s that redefined itself and the world. No, I was joining the largest company in the world, that knew exactly who it was and wasn’t interested in trying to fit into someone’s predefined box about who Apple should be. Ultimately I was joining Tim Cook’s Apple.

Apple Infinite Loop Campus

I knew what I was getting into when I joined Apple, but walking through the doors at Infinite Loop for the first time, seeing that tree in the foyer with it’s Emmy’s proudly shown in a glass box. Then walking the campus and eating at Cafe Macs was almost nostalgic, as if I could imagine myself being part of the original team that built Apple. In reality although I always found Jobs interesting, I think he would have been awful to work for, and seemed like quite a jerk. But there I was feeling as if I had made it.

The early years

For the first 3 years I worked as a manager in the Seattle office. I had a truly amazing team, smart hard working bunch of guys. I would travel to the Silicon Valley area almost once a month and visit the larger team down there. Whenever I was down there I started a habit of having breakfast at Infinite Loop. I would order some French Toast, take a seat outside under the trees and just watch the early morning traffic inside the campus. In the beginning I was always amazed that I was somehow in this position. In later years it ended up more of a tradition than anything else. Somehow I even got involved in open source, although admittedly most of it was a struggle. During that period I was the originator of two open source projects, https://github.com/osmlabs/maproulette and https://github.com/osmlabs/atlaschecks. I even went to Japan to present our open source projects to the openstreetmap community. I was working hard and enjoying it. The stress took a bit of a toll on me, but ultimately it was a good time. My life was drifting a bit, part of it was me and part of it was my job. But ultimately in 2018 I decided to step down from management and return to a developer role. I also told Apple that I was leaving Seattle and would not be close enough to any Apple offices. This was a really scary conversation as I really didn’t know whether I would have a job at the end of it. Somehow though Apple decided that having me as a remote employee would be the better option. And so I packed my bags and headed to the central coast of California. And my time as a remote employee began.

The Remote years

Working remotely at Apple was, and still is, not easy. Apple is not a remote friendly company. If you want to truly advance in the company you need to be in Cupertino. They are very much an in person networking kind of place. Generally being promoted to the higher levels requires people way above you to not only know who you are but that you are someone who should be at those higher levels. Doing that while in a remote office like Seattle was difficult, doing it while remote was even more so. I got pretty lucky. The funny thing about working at Apple, is that for an IC role in software it is actually really easy. Apple is a hardware company and as such are just not great with their software practices, and don’t get me wrong, there are a lot of brilliant people working there but the company can’t seem to get out of its own way. Needless to say I found doing my job to be really easy, if not incredibly frustrating. Things just took so much longer than were necessary and I often found myself working on something that could ordinarily take me a couple days taking double or triple the time. And again not because developing or even coming up with a solution was difficult but rather getting through various inefficiencies in development tools and computing had too much red tape and often times just slow. I remember sometimes waiting weeks to get approval to access some servers I needed. It all sometimes seemed like it was purposefully trying to slow you down. It was frustrating, and at the same time the central coast of California was becoming a bit of a frustrating place for me to live. So my wife and I decided to pack up things again and move back to the place where we started, San Diego.

Beautiful San Diego, my home now.

And then the world went crazy

In early 2020, we decided to move to San Diego, and the week after we put our house up for sale the whole world starting shutting down. The pandemic raged through and we found ourselves in situations that were unheard of. I remember driving down to San Diego for just the day to look at a house, and I had driven through LA multiple times in my life, but I had honestly never seen it like this. The 5 freeway was just empty, the skies were super clear and I drove through it faster than I ever had. Coming back around rush hour I figured it might be a little busier, but it was the same experience and sometimes there were just no cars, which for anyone who has driven on the LA freeways you would definitely think that the Zombie Apocalypse had just taken place. The pandemic was interesting for my time at Apple, I actually felt like it was more efficient in ways. People seemed to be just a lot easier to connect with. Maybe this was my perspective being remote and then all of a sudden everyone else being remote. At this point my traveling to Apple HQ obviously stop and little did I realize this would be the last time I went to Apple HQ. I enjoyed having everyone remote though. The time flew by a bit, and everyone was trying to figure out how to live in the new world they found themselves in. The uncertainty I would imagine caused people to not think about making any drastic changes. People started to focus more on what is important and in general there was a bit of a reset. I sometimes wonder if I might have left earlier if there had been no pandemic. But at the time it wasn’t something I even nearly considered, just too many things outside of work to focus on.

And then I left

Starting in 2022 my frustration hit a level where in January of that year, the pandemic and turned into an endemic, so I took a call from a recruiter and started some conversations. I wasn’t quite ready at the time, but my frustration had risen such that I was willing too. In May of that year I had a meeting that broke the camels back and sent out my resume to about 10 different companies. Truth be told if the market wasn’t so good I might have just taken the weekend and come back and said sorry to all the responses, but I got responses that day when I was still in a bit of frustrated mood. Truth be told this was long in the making and Steve Jobs is quoted as saying the following:

“Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven’t found it yet, keep looking.”

Steve Jobs

Part of this quote is printed on the wall at Infinite Loop and remember looking at it on my very first day. He is also quoted as saying this:

“For the past 33 years, I have looked in the mirror every morning and asked myself: ‘If today were the last day of my life, would I want to do what I am about to do today?’ And whenever the answer has been ‘No’ for too many days in a row, I know I need to change something.”

Steve Jobs

So in a way Steve Jobs inspired me to leave Apple. I was not happy, I was frustrated and I knew I had been frustrated for too many days in a row. If I was honest with my self I probably had been frustrated for a couple of years. But I am generally a loyal individual, and there were still quite a few things that Apple did that I really did love. I really did love working for Apple, I thought that as far as trillion dollar companies go, I was proud to say I worked for them. I love their products, and I was super proud of being part of the Maps team and what we had done in the past 7 years. But my growth had been slower than I would have liked through the years. There were many things I did learn, and many ways in which I grew but I felt that I had gotten to the point where I wasn’t going to grow any more. But ultimately I was not used to not absolutely loving going to work on Monday. It wasn’t like in the last 20 years I had woken up every Monday morning and been super excited but generally speaking I can say that I was excited about the work I was doing and wanted to go to work more than not. My last couple years at Apple had changed that, and so I needed to make a change.

Onwards and Upwards

Netflix HQ

And so I quit. Before I quit though I got a job at Netflix. In my career I had worked in radio, security, marketing, maps and now was shifting to video games within the movie world. If Apple was my foray into a company that I had followed and admired for decades, Netflix is my shift into an two industries that I have loved since as long as I have memories. I played my first video game when I was 3 years old, and honestly that memory is my earliest memory I have, even as a 3 year old I knew this was what I wanted. And through my life until college I decided that video games was the industry I wanted to work in. In college I found a love for graphics programming and my dream was to work for ILM or Pixar, both because of my love of movies and graphics. Neither of those dreams really became a reality and I basically shifted in a career that eventually moved me into data. And I love data, I find it fascinating. And in my new role I will be working with games data within a movie/tv company. So merging all 3 loves, data, movies and video games. Nothing is perfect, but I am definitely looking forward to seeing how this one goes.

Gaming in the 90’s

In the early 90’s I felt like gaming on the PC was starting to pick up steam. The internet was also starting to grow, it was still small but something was about to happen that would change my gaming life forever. Before I dive into that moment I have to give a little background. The internet was not what it is today, Amazon didn’t exist yet, honestly nothing did. I started on bulletin board systems and IRC. Weird chat room systems were popping up everywhere before chat roulette was even a thing. But most importantly we were getting a taste of all the worlds information at our fingertips. My boys may never understand the concept of not being able to ask some smart device the answer to just about any question they can think of. At the time I was playing games like Lemmings, The Incredible Machine, Space Quest IV and Civilization. I was also playing a couple platformers, namely one called Duke Nukem. I was also playing Dune, an RTS based on a book I read. I was addicted to that game for a little while, it was one of the first games of that genre that I had really played before. And then in 1994 Warcraft was released and I was hooked. It is interesting I see the same tendencies in my oldest son when he is around video games, complete consummation of attention. I was always addicted to anything related to computers, but this was the first time I felt addicted to a single game, before it was play whatever. Now it was always play Warcraft. I love just the strategy of war, I should probably introduce my son to a good RTS. At the periphery of my attention I started noticing games like Wolfenstein3D and Doom, truly revolutionary games, but for me they wouldn’t hold a candle to the game they was my next addiction…

Space Quest IV: Roger Wilco and the Time Rippers

The 80’s were over, arcades were still going fairly strong but home entertainment was picking up steam. Sega and Nintendo had started to invade the living room and now their consoles were more than just passing fancies. I however missed the console generation completely. The only time I got to play console games was when I was at friends houses. Games like Mario, Island Boy, Tiny Toons, Lion King and various sports themed games were all games that I played a little here or there. I also headed to the Arcade to play various games like Off Road Racing, 1942 or Double Dragon, but mainly Street Fighter II. But no I was a PC gamer and p roud of it. Console and Arcade games were for little children, I played games on a real machine.

I’m all outta gum

Duke Nukem 3D

If Space Quest was the first game I loved, and Warcraft was the first game that really drew me in, Duke Nukem 3D was the first game I was addicted to. I can’t really remember how I found out about the game but I knew I could download the demo of the game. It was a whole 15Mb, it would take me all night and I would have to make sure someone didn’t accidentally dial out on the phone downstairs, so I would need to start it late. It is strange to think that 15Mb of data would cause any sort of challenge, today we can’t really even imagine a game worth playing that isn’t at least around 1Gb, and downloading it really isn’t a problem either. I finally got the demo though, and loved it. From the voice of Duke and his no care attitude, to the amazing graphics and sound. I got so many miles out of the game. We also started getting computer classes at school and there were about 15 PC’s networked together. And this was my first introduction to LAN parties. We got Duke Nukem installed on all the pc’s and somewhat bribed the PC teacher to turn a blind eye and computer class turned into an all out Duke Nukem battle. Our Duke Nukem battles would last through high school which ended in ‘98 and with the close of high school came the last couple battles of Duke Nukem. The LAN parties of the 90’s would change in the early 2000’s and finally disappear entirely and give way to online battles, but carrying your entire PC and huge CRT monitor to a friends house has become a very unique experience to us kids growing up in the 90’s.

Unreal

Unreal Tournament

At the very end of the 90’s a game was released that would help me move on from Duke Nukem, and that was Unreal Tournament. LAN parties continued and the same feeling I got from battling it out with my friends continued but now with a slightly different gameplay and feel. Gone was the single player campaign. Unreal Tournament was unabashedly a multiplayer experience. There was an online component that was picking up steam, but my experience online was just associated with too much lag. It started to work in the mid 2000’s where those issues became non existent. I really honed my FPS skills during this time and felt like I could beat anyone. Truth be told I really didn’t challenge anyone outside a certain skill range, all good but not like some of the kids today.

End of an era

The end of the nineties was the end of a lot of things for me. High school had ended and college would soon be ending as well. I was moving away from my teenage years and into my twenties. Gaming was changing, FPS games where started to dominate the landscape, the internet was changing how we consumed and played video games, and Arcades were dying. Graphics was improving in leaps and bounds and we had come a long way from the days of pong. If you had told me what some of the games would look like in twenty years, I would be shocked. But this was also an end for me, not for gaming completely but from a very serious perspective. My life would start to take on more responsibilities, career, marriage, kids and various other things would take my focus. Gaming in my life would change, I am not upset in the change, but it is something that would hold a different part of myself. I will explore this in later blog posts, but for now gaming was ending the 90’s on a high.

It’s been awhile.

I haven’t blogged since 2015, and although I didn’t really have an audience I enjoyed the cathartic experience of writing out my thoughts on things related to technology and gaming. So why haven’t I blogged at all. Well it all started in August 2015 when I landed my dream job at Apple. And I will first start by stating that I loved my time at Apple, but as of July 8th 2022 I decided to move on to my next adventure. The thing about Apple is that they are very secretive, incredibly so. Both within the company and out. Often times I would only learn about things when the general public did as well. I worked in maps and knew some things related to maps in advance, but in terms of the hardware I just never knew anything. So with this whole culture of secrecy two things happened, contributing to open source was challenging and talking about anything related to work was next to impossible. So instead of trying to navigate the challenges around writing a tech blog I just decided to not do it at all. I missed it. And like I said I don’t have an audience so it really is something just for me. Honestly I don’t even really have interest in building an audience for this.

Before my next adventure however I am planning on taking a two month break, 2 months off basically being unemployed. It is going to be amazing. So I thought I would try to write blogs on the following topics:

• Working at Apple
  • This will not be a blog that really talks about the work I did or any secrets, but just my experience working there. It should be quite cathartic to write this one. I just recently posted an article talking about right before starting at Apple that you can read here: https://techandgamingblog.wordpress.com/2015/07/23/onwards-to-apple/
• Remote Work
  • I switched to remote work in 2018, and the pandemic pushed us to embrace it more. So would be interesting to talk about my experiences.
• Gaming in the 90’s
• Gaming in the 2000’s
• Gaming in the 2010’s
• Next in gaming
  • These 4 blog posts are related to a blog post I made a long time ago where I spoke about my history in gaming in which I focused on my history in gaming in the 80’s. You can read that post here: https://techandgamingblog.wordpress.com/2014/07/25/my-history-in-gaming/
• Why I left Apple
• My time off
  • A blog post about why I am taking off 2 months between jobs.
• My next adventure
  • A blog post I would like to write towards the end of my 2 month time off about my next adventure.

These are the blog posts I would like to write by the end of my time here. I may include random other posts, most of it would be related to gaming, career or technology however most likely won’t include technical posts primarily because I am not really coding during my time off, don’t even really have a machine I can develop in at the moment.

Again though I don’t think anyone reads this, so really just for myself. 😉

Programmer Interviews

In my 20+ year career I have not interviewed a whole lot. I have spent 16 years at just 2 companies, 9 years at Webtrends from 2006 to 2015 (technically two companies, but the first, Widemile, was acquired by Webtrends in 2009, so I didn’t interview) and 7 years being at Apple. I also didn’t interview with too many companies when I transitioned Webtrends to Apple. I have interviewed people more than I have been interviewed, but those have not been consistent as companies go on hiring sprees and then nothing for a while. This blog post will focus on being interviewed and I will write another on interviewing at a later date.

Like I said I am not super experienced when it comes to interviewing but I did recently transition from Apple to Netflix, and I looked at a lot of companies during my interview season. I am not going to talk about specific problems but just give an general idea about all the companies I interviewed at. So first here is the list, in no particular order

• Amazon
• Apple
• Netflix
• Google
• Meta
• Rivian
• Hubspot
• Airbnb
• Stripe
• Github
• Disney
• Zillow
• Uber
• LinkedIn
• Intuit

That definitely seems like a lot of companies, however I didn’t pursue some too far, and I was rejected at various stages from others. Every single one I interviewed with there was some level of interest, and I found that my interest changed as I moved along in the process. A company that was my top choice could change as I learnt something new about some other company.

Let me first say to anyone reading this, interviewing often times contains a bit of luck. Failing an interview does not mean that you are not good enough or qualified for the position, and likewise getting an offer doesn’t mean that you are actually a good fit for it. There are so many factors based on the questions asked, the personalities that interview you, your state of being on that particular day, your desire for the position and also whether you and the team hiring feel like it would fit. My biggest suggestion is to learn from the failure and move on. I know that can be difficult especially if you really wanted that particular job, but remember it isn’t necessarily a reflection on your skill or your ability to succeed in other interviews. I always remember back in 2015 I really so badly wanted to get a job at Google. Felt I had done pretty well in the full round of interviews, and thought I would get an offer. I heard from them while I was on vacation, even the voice mail they left to call back sounded like I was going to get an offer. I got rejected, and on the same day just a couple of hours later I had a phone call from a hiring manager at Apple looking for a software developer. I spent 7 great years at Apple and still consider that hiring manager a good friend.

One thing that has changed that is different to the other times I have interviewed is that everything is done remotely now. I was a little nervous about it, even though I have worked remote since 2018. However it seems that everyone had it pretty well nailed down and I didn’t ever feel that that was a problem.

Everybody’s experience will differ, so take everything with a grain of salt, also I was interviewing for Staff and Snr. Staff software positions. Also a couple of management positions, but mostly engineer positions. So different levels will most likely have different kinds of experiences.

The Recruiter Call

This is always the easiest and most relaxing call you take. And pretty much every company is similar in this call. Sometimes the recruiter has a specific job in mind, sometimes it is in reference to a specific job application. Most of the time it is an exploratory call as the first part of the investigation into 3 things:

• Whether your skills match the skills you are looking for.
• Whether your interests and desires match what the position is offering.
• And a little bit of background on the position for you as well as a little bit of your background.

Ultimately the recruiter is looking to see if they can get you hired. The fact that you have been called based on your resume (not always the case), should give you extreme confidence to move on to the next round. During this time investigation on the job and company is crucial especially if you are really interested in the position as it is one of the best times to get as much information about the position before the real fun starts. This will help you define your prep work. Remember everyone wants you to succeed, and on your side putting in the research work will help. I won’t go into too much detail on each individual company as this call is incredibly similar across the board. Get used to answering the same questions over and over again. Do not discuss compensation at this point, some may ask at this point about ranges, I tended to answer with a generic, “I am looking for the right offer for the right position”. Super vague and generic. I didn’t get asked a lot about this though at this point and they generally didn’t push me.

The Hiring Manager Call

So not all companies have you call the hiring manager first. Google for instance have you go straight to the phone screen. Amazon had me bypassing the phone screen and going straight to the full round. With them I ended up having a hiring manager call only because I was hedging a lot on whether I wanted to move forward at all. Meta doesn’t hire to a specific team so I believe this may come later. They stopped me before I even got to this stage as I was applying right when they went into their hiring freeze. This is also now generally over zoom or hangouts. This again for the most part is an easy and relaxed call with the hiring manager. Generally speaking they are not assessing skills, and not asking behavioral questions. This is almost purely them looking too see if you fit what they are looking for. This is a great time to get a feel for your potential new boss and for the team and organization that you will be fitting into. Always remember you are interviewing them as well, ask questions that are important too you, things like:

• What is the work life balance like on your team?
• When did you or your team last take vacation?
• How large is the team?
• How long have you been in this role and who is the longest tenured employee on your team?
• What does your ideal candidate look like?

All these questions are driving towards understanding what the culture of the team is and whether you can see yourself not only fitting within that culture but enjoying it. Reading between the lines is important. For instance the question about work life balance is not simply about vacation or a standard 9-5. It is about trying to gauge whether the team is in a constant panic mode, or whether they are so relaxed that they are just not doing much and maybe not expected to do much, it is combination of value and how well the team is managed. It is important for you to understand clearly what you are looking for, so that you can get the questions that are going to be most suited to drive what you are looking for in a job. Before I interviewed anywhere I wrote out 3 non negotiables, and then a couple more things I would like to see in my next job. This help me prioritize what kind of questions I needed to ask, as I was driving towards understanding whether the company I was talking to was right for me.

In saying that you are obviously also being interviewed. They want you to succeed though, so best bet is to be relaxed as possible. Confidence always goes a long way here, not to the point where you seem egotistical, but rather a confidence in how your answer questions and talk. At Staff level there will be an expectation that you are able to carry yourself confidently into any room and hold your own.

The Phone Screen

This is your first test, and every company seems to handle this differently. It is where you start the technical testing which generally speaking is done poorly but we haven’t seemed to be able to figure out a better way of doing it. Stripe had me do a systems design question, LinkedIn was an easy style leetcode, Google actually had me skip this step, Airbnb was interesting as they had the hiring manager do this one and it was more like a technical discussion, Hubspot was similar. Generally speaking this stage tends to be more technical, whether it is part of an overall discussion, leetcode or systems designs. I was actually pleasantly surprised by how few companies were using leetcode questions which I have always thought was kind of dumb way to assess peoples skills, both in the phone screen as well as the full round. LinkedIn was actually the only phone screen I failed. I thought I did fine, but I didn’t really ask the recruiter why as I was in the late stages with other companies that I was much more interested in. In general though I would say it is always good to ask, sometimes the recruiter will not say why, sometimes what they say seems wrong and other times the reason was due to something just outside your control. Failure is always hard, but important to learn from them.

The Full Round

I found that in general it wasn’t too difficult getting to this stage if I wanted to. The phone screen is really there to weed out candidates that are really not qualified. If you find you are failing out of too many phone screens then you may be looking at positions that you aren’t quite ready for. You also may just need some help from a friend who will give you some mock phone screens.

The full round is exhausting, almost always this is true. Most companies give you options to break it up into multiple days. This is because it is all done remotely these days, so they don’t have to fly candidates in and put them in a hotel, it really is just a matter of getting everyone’s calendars aligned. Ones of the biggest issues here is time, some people take time off and try to schedule all the interviews close together. I will say this is very challenging timing everything right. Things went incredibly well for me and I still couldn’t get it all scheduled perfectly. I did get a bunch at the end going back to back over five days, but I will say that at the end of the fifth day I was completely exhausted.

The full rounds are hugely varied, and I found this to be very different from company to company in some ways and incredibly similar in others. The interviews are almost always split into 4 categories:

• Behavioral
• Technical
• Systems Design
• Culture Fit

Some companies don’t have interviews dedicated to culture fit, but they assume that all the interviewers will be taking that into account. Netflix was one that was very particular about it’s culture fit and had multiple interviews focused purely on this. In general I would say Netflix’s interview process was the best and maybe that is part of the reason why I accepted their offer. Maybe in a subsequent blog post I will go over that in a little more detail, without speaking specifically about the questions asked.

Behavioral questions are all incredibly similar, you will be asked about various situations and how you would deal with it. Questions like:

• Describe a situation where you had to deal with a colleague that you disagreed with.
• Describe a situation where you failed or made a big mistake.

There are multiple variations of these questions but similar in many ways. The best thing is to have some of these kinds of situations written down so that you can refer to them and you don’t spend too much time thinking about one and then trying to remember the situation in a somewhat stressful environment.

Technical questions are split into a further 3 categories:

• Coding
• Discussion
• Review

Most of these are done through something like Coderpad. Which was interesting for me in the beginning, because you are now often expected to have your code compile, which in the past you could hand wave certain things on the whiteboard. Like you are not 100% certain on a function in a common class and just make up the function name explaining what it does. Generally speaking they are fine with you looking up things on the internet, however I struggled when I did that as I like to keep talking about what I am doing and when you are looking things up there is just a terrible silence. Also don’t expect to look up the answers (not good form anyway) but if you need to remember a function of a class that is generally easy to do. In saying that I would make sure you brush up on the standard data structures that you are most likely to use in whatever is your language of preference. Leetcode was not common, I had practiced a fair bit of leetcode, so I was brushed up on my various algorithms and common patterns for solving those kinds of questions, but it came up a lot less than I first expected. Hubspot had a great technical question, which was not leetcode but rather basically a small application, Netflix has something similar. For Google I did a code review which I quite enjoyed as well. There are also technical discussions, these usually revolve around projects you have worked on. So generally speaking it is good to brush up on some recent past projects and not just a good understanding of your current project. For the Staff level they really are looking to see what kind of scope you had in the project. Were you a contributor or a lead, did you coordinate with other groups, was your role much more than designing single systems, but multiple systems across an organization. These are important values for this level.

Systems design questions are similar to technical discussions but they revolve around a starting requirement. Something like design a video streaming service, a service like TikTok, or something like that. The best question I got was about updating satellites orbiting Europa, just something completely unexpected and totally outside my comfort zone. I loved it, I still think about that discussion and how much I enjoyed it. It certainly helped that the interviewer was very easy to talk through the problem with. Ultimately the question at face value is ridiculous, most of the time these systems have been designed by large teams over multiple years and you are being asked to do it in just 30-45 minutes. Ultimately I think they are looking for the following things:

• Does the candidate understand the problem space, considering things like size of data, scalability, partitioning, distribution, etc.
• Does the candidate know how to model data
• Can the candidate derive requirements
• Is this somebody who I could collaborate with in future projects
• How well can they piece together the whole system
• Do they consider different kinds of solutions

Although I tend to enjoy these a lot as I love designing large systems, I also find these the easiest to fail. The reason for this is that it is difficult to know what the interviewer is truly looking for, and not in regards to the requirements of the problem, but maybe they are looking primarily at how you collaborate, maybe they have a specific solution in mind that they want you to answer, maybe they are focusing on how the system scales and you instead are focusing on how the data is modeled. Not to mention that you honestly simply may not really connect well with the interviewer and you may get it right but that doesn’t matter. It is unfortunately sometimes a complete crapshoot. In saying that it is still my favorite one, and I do often think it is the best evaluation of your technical skills at this level.

The Offer

So you did it, they like you and they want to make you an offer. There are many blogs written about salary negotiation, this is not one of them. Firstly I am terrible at salary negotiation, truth be told I don’t believe I have ever negotiated my salary, and secondly it is a blog post all by itself. The offer is more than just compensation though. For my part I had three numbers in my mind, the number I wouldn’t go below, the number I thought would be fair and the number that I think would be awesome. Depending on how much I liked the job would depend where on that scale the number needed to be for me to consider accepting it. It is always important to remember though that the offer is more than compensation, although that is how it ends up. You will be spending a lot of time with this team and at this company so make sure you like it. Also remember in tech there are three numbers you need to take into account:

• Base
• Bonus
• RSU

Most companies have some variation of this, but generally speaking it holds true. Private companies will often give out stock options. Again I am not going into these but remember they are worth less than the paper it is written on until that company goes public. Profit sharing may come into play as well, often times in form of bonuses. Just ask the recruiter to explain the details of it. RSU’s usually vest over 4 years, but that isn’t always the case, so it is important that you are clear on that. $100k RSU over 4 years is very different to that same amount vesting over 2. A sign on bonus can often be negotiated higher, however important to note that they are often higher than annual bonuses, so important to understand what is the general percentage for calculating annual bonuses for your level. Base is often the most difficult to negotiate, but if you do plan on negotiating, unless you can get really high RSU’s in a company whose stock has performed well, get your base as high as possible. It gives you much more control over your own destiny and your finances. Where as bonus and RSU’s can sometimes tie you to a company and give you golden handcuffs, honestly not the worst thing in the world but something to be aware of. I love Netflix’s approach which is all cash, making things just a lot simpler, giving you much greater control of your finances.

So how did I do?

Well as I mentioned above I looked into 15 companies. Of those 15 companies I stopped the process prior to the full round of 6 of those companies. 1 company rejected me before the phone screen, 1 company rejected me at the phone screen, 4 companies rejected me after the full round and 3 companies extended offers to me. Nobody likes being rejected, but I learnt from each. One company said my systems design skills were great but lacked in technical the very next one said the exact opposite. I mention this because it is important to realize that the failure doesn’t necessarily mean that you are not good enough, it could simply mean that 1 interviewer just got a bad impression of you in the short 45-60 minute window. It is possible you messed up but it is also possible they did. Learn and move on.

Interviewing sucks, it is hard and the outcome sometimes is completely out of your control, but it isn’t as bad as you think especially after you get that first rejection. Be patient, don’t accept the first thing that comes your way and wait for the right job. Your next employer and your future self will thank you for it.

Onwards to Apple

A while ago I wrote a post about switching to developing on Mac’s, you can read it here. Since then I have continued to love developing on my Mac, and have now been developing pretty much exclusively on my Macbook Pro for about 2 years. I have owned my iPhone since the 3g and have always loved it. For a short while I used a Nokia Lumia with Windows on it, but as soon as my contract was up I switched back to the iPhone. I do really love my Apple devices, although I am by no means a fanboy or anything, I don’t have a apple TV (instead use Xbox) and I don’t have an Apple airport (I have a great ASUS router for all my Wifi needs) and the only tablet I have in the home is the original Surface, although that may change. But I am interested in the Apple Watch and am thinking about getting one. Anyway maybe I should back up a little bit.

I was about 13, maybe 14, when I really got introduced into the world of Apple. I was too young to even think about news in 1984, so the concept of a revolutionary device like the Macintosh was completely lost on me. But around 1994 I was introduced to a Macintosh, someone was throwing it away and I said I would take it off there hands. We had a standard windows PC at home which I coded and played games on, I believe it was a 386dx or something like that. But this was definitely a time when you really only had a single device in the home, unless you where rich, and we were not. It was an expensive underpowered machine in 1984, ten years later in 1994 it was practically worthless and only really useful for nostalgia, of which I had none. This was not a world I was familiar with. But I had my own computer and so I did very basic work on it. I thought it was interesting but didn’t put too much thought into it. I didn’t even nearly understand the amount of work and energy that was put into this single machine. I also did not realize that this was really the first mass produced successful computer that used a GUI instead of a command line style interface that was DOS. All of this was completely lost on me, I was 14, and what 14 year old isn’t completely self absorbed. Anyway about a year later I started reading a book by John Sculley called Odyssey: Pepsi to Apple. I have a tendency to listen to music when I am doing anything and I remember specifically during the time I was reading this book I was also listening to Oasis’ (What’s the Story) Morning Glory?. So every time I hear Wonderwall or any track on that album I remember lying on bed reading that book. I was captured by the mere concept of Apple and what Jobs and Woz did. The problem though was that this was the 90’s, the 90’s where not good to Apple and by 1997 Apple was on the verge of bankruptcy. Microsoft was ruling the technology game and there were no competitors anywhere. Apple then did two things that saved them, they got Steve Jobs back and they got Microsoft to buy part of Apple. 

Through the 2000’s I was working in the internet software industry. I saw companies like Google, Facebook and Twitter being born and become the power houses that they are today. And I witnessed as did the rest of the world one of the most amazing comebacks in business history. Steve Jobs took Apple from near bankruptcy to being the second most profitable company in the world, now with 115,000 employees and profits around $70 billion. They are now the most powerful tech company in the world. During this time I was working for little startups and the biggest company that I worked for was Webtrends which acquired the startup I was working for in 2009 called Widemile. Webtrends is only about 300+ employees, so still a small sized company.

About a year ago I started reading Steve Jobs biography, and it was a fascinating read although I knew a lot about the history already, as I had read a lot about Jobs and Woz. And with the coming of the internet age it was fairly easy to keep up to date with what Apple was doing, at least after they had done it. Also around this time Apple contacted me and wondered if I wanted to work for them. I declined at the time because they wanted me to work in Cupertino, and I really love Seattle. Although it got me thinking a lot about the possibility of working for them. Part of me has always wanted to experience that big company job, but it was only recently that my experience gave me that opportunity. I wasn’t particularly looking for a new job, but various circumstances made me think about it, and during one particular week I got contacted by Facebook and Google. And so I thought, why not lets see what is available to me out there in the world of big tech companies. Just before I was going to go for my all day interview at Google, Apple contacted me as well and it got me quite excited. I may blog about my interviewing experience separately as I feel that there would be some value to that. But ultimately I ended up interviewing at Facebook, Google and Apple. Apple flew me down to Cupertino to interview at one of their campuses in Sunnyvale even though the job was for a position in Seattle. I expected things to go slow as I had heard people only hearing back after weeks or months, but I got an offer the following week. I was pretty stoked and soon I will be having my first day as an Apple employee. Having grown up using Microsoft PC’s, moving to Linux development machines in College and through the majority of my career, I am a little surprised that my career ended up at Apple. But I really happy that it has, and although I am not really going to speak much about my job or what I am doing, I will say that I am super excited about it.

I like to think that Apple is the dream job I never dreamt of getting. I remember in college I wanted to work for ILM or Pixar, when I first got to America I just wanted a job, in the middle of my career I would have thought that Google would be a great place to work. Now I found myself about to start working for Apple, and am more excited about the opportunity than I thought I would be. If nothing else it is going to be quite the adventure.

Onwards to Apple…

[Update] This post was originally written in 2015 right before I started my job at Apple I thought I would post it as written that was left as a draft since that time.

Wookiee Components

As I mentioned in my previous post, an Open Source project that I affectionately called Wookiee. You can check out the open source code at http://github.com/Webtrends/wookie, if the link fails it is most likely because we renamed the repo to wookiee with the extra e, so that it is the correct spelling. This blog post will be all about components and why I think they are awesome. I might create a series of blog posts about this, and after this post create a tutorial on creating a component for your service.

Wookiee without components

So firstly what does Wookiee look like without components. Well if you had to clone the repo, build it and run it, which is a little tricky because we don’t really tell you how to do that, it would start up all nice and say it is ready. However it really would only be able to do a couple of very limited things, one of them is respond to ping but that is as exciting as it gets. Without components this is a very sad existence. Nothing to do and nowhere to go. Now of course you could write a service on top of that, and run the service. And this would work even if you don’t add a single component, but you would have to build a lot of boiler plate code and at the end of it you might question what was the point of starting with Wookiee to begin with. And this is where components fit in, and why I think they are awesome. Wookiee is lightweight and purposefully so, which is why starting it up without any components doesn’t really do anything. The core of Wookiee really only contains the infrastructure code to support primarily three things, Commands, Services and Components. In a blog post I wrote for Webtrends you can see a introduction to these ideas.

Really though what is a component

Components are primarily libraries that plug into the Wookiee’s communication bus for easy access from any Service that sits on top of Wookiee. The key to a component is that it is resusable. So lets say I want to write a component that adds Spray to my Service, which we actually did write one. This way instead of having to write any Spray code over and over again I simple add that dependency into my project. The more components there are too choose from the more options have to use for my particular service. Wookiee has 10 components that were build with the release of the framework:

• wookiee-cache-memcache
• wookiee-cache
• wookiee-cluster
• wookiee-etcd
• wookiee-kafka
• wookiee-metrics
• wookiee-netty
• wookiee-socko
• wookiee-spray
• wookiee-zookeeper

So by default you can pick and choose what you want to start with and go from there. So as an example you can plug in one of three http based technologies (Spray, Socko, Netty) that will immediately give your service http ability. Of course there are many pluggable frameworks that you can choose from. The difference I find is that a lot of those frameworks are firstly primarily web based frameworks and often over time get pretty heavy at it’s base. Wookiee should never get heavy at the base simply because the base is designed to be incredibly lightweight and the added components will only make it as heavy as you want it to be.

I don’t get it

Ok so maybe this isn’t the best explanation. I have tried to describe it to people, and I think the difficulty often is that a lot of these concepts are not new. And so often when I speak about it they shift to the examples they know about. However sometimes showing someone how easy it is to do it is worth much more. So in the next couple of blog posts I will be creating a mini tutorial that will build an mini service that uses the Spotify API. I will use the Spray component and build a new component called the wookiee-spotify. Hopefully it will be helpful to anyone who is interested in building new components for Wookiee.

Webtrends Wookiee 1.0 Released

For the last half of 2014 and  the beginning of 2015 I was working on an open source project called Wookiee.  I am quite proud of the results of this project, and even prouder that we were able to open source it. This being my personal blog, I am not expounding to greatly on it here particularly as I wrote a Webtrends Blog post regarding the release of Wookiee, and so instead will link you directly there.

I will say that I am super happy that we were able to open source this project and hope that there are other people who will get use out of it. I am really proud of the results of this project and really feel that it is a beneficial tool. If anyone is interested in it, let me know and I could possible give a series of blog posts in a tutorial style fashion to explain it more in depth. Although I would encourage you to look at the docs in Github as they are fairly helpful.

Mob Programming

I want to first off state that my experience in Mob programming is extremely limited. I joined a group of guys (4 other guys) who had been doing it for a couple of months, and sat in for a little over an hour trying to be part of their process. So I am basing a lot on a very limited experience, and understand very clearly that I bring my own bias into this post. I had only recently heard of Mob programming which is basically taking pair programming to the extreme. The concept is to take everyone in the team (or at least part of the team) and have them basically code together. There is one guy designated as the driver (the driver can change during the course of the session, but only one at any given time) and the team as a whole discuss what needs to be accomplished while the driver writes the code and anything else required.

What I liked about it.

• Collaboration
  The collaboration amongst the team is incredibly high. Everyone is part of the process, so you don’t generally have a developer that “owns” this part of the code. Part of this may have been due to the level of experience in the room that I was a part of, however I believe that this would carry over to groups of any or varied experience. From this perspective it was an incredibly beneficial exercise.
• Group Knowledge
  This works in two ways. Firstly every developer has their own knowledge set that does exactly overlap with any other developer, and so bringing all those skill set’s together allows solutions to be more robust and almost certainly less prone to bugs and especially large destructive bugs. Secondly it helps developers not only understand all the pieces that are being built, because they are being built together, but it also helps increase the knowledge sets of all of the individual developers knowledge.

What I didn’t like about it.

• Efficiency
  I find this method of development incredibly inefficient. In my short session there was a group of senior developers, all very talented, but it took an hour to do a very very basic thing. Something a single developer could have done in probably 15 minutes. And I even say that conservatively as I was not part of the team, just seeing what it was all about, and I felt I could have done the work without any previous knowledge fairly quickly. However in saying that I gained a lot of knowledge about the system in a very short period of time.
• Design by Commitee and Groupthink
  These two concepts were not especially prevalent in the particular meeting I was a part of, however I saw some trappings of it and I can easily see how this could push itself to the surface without too much trouble. For more information basic on these you can go here and here.

In general I can’t say that I would be a complete advocate for Mob programming. My biggest issue with Mob programming, pair programming or even meetings in general is that all these concepts are basically forced collaboration. If a team is not collaborating well together we try to force it, which I believe can end in disaster. I don’t think it is not possible for a team to use mob programming or pair programming effectively and have it help foster collaboration, but I believe a team that is collaborating well outside of these “forced” interactions is a much more agile and efficient team. Of course the world is not perfect and sometimes these things will help and sometimes they will make things worse. It is up to the team to figure out what is the best way to move forward. If it means that they require mob programming because they are continually producing poor quality code with large bugs then mob programming may be helpful to stabilize the code base and foster great communication within the team. In the end it is something that can be good or bad, depending on the users of it.

Personalities can also have a strong impact on mob programming making it better or worse. If there is one very strong individual, they can dominate the conversation and cause serious groupthink to set in, especially if the other developers are non-confrontational. If you have a bunch of ego’s in the room you risk the design by committee problem and everything built becomes a difficult and fragile compromise.

Anyway I understand that I can come across as negative towards it, however I did have a positive experience with it. I just see pitfalls that may not work in each and every situation, and I struggle to see it working well in more than just few situations. Take my words with a grain of salt however, research it and if interested enough try it out at least and see if it is right for you.

15 Years of Programming

I thought the other day that I have spent a good portion of my life programming, or at times at least trying to program. Professionally I have done it for 15 years, but I still remember the first time I started attempting to code. I was around 6-7 years old and my father had bought a 286 pc. This came preinstalled with the latest MS-DOS, which had two things that really got me, Space Invaders and BASIC. Of course Dijkstra once said,

It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.

So BASIC was my first entry into programming, fortunately I guess it was short and so hopefully I was not scarred for life from this experience. But I remember building programs that did odd things, like lines being drawn all around the screen and then bouncing here or there, also more straight forward things like simple calculators. My new hobby progressed through Pascal, C, C++, Java and various other random languages along the way. However in my professional career I have spent most of my time coding in Java and more recently Scala. Either way I believe a great programmer is more about how you think rather than any one specific language you may know. But over the years here are a couple things I have learnt. These things are more related to professional development and not as a hobby, however it could applied either way. It also is quite random, these are obviously not all the things I have learnt, just a couple that sprung up in my mind.

• Mistakes are not bad

We live in a society that pushes us to always be right, to always do the right thing and to never make mistakes. Mistakes are considered bad. Mistakes however usually get you to your destination quicker, help you learn invaluable lessons. Best practices are built off years of mistakes that help us understand how something should not be used. I remember early in my career I never wanted to make a mistake, and so I hesitated, I didn’t make changes to code I felt was badly developed, and especially if it was developed by more senior developers. Now as someone more senior than most others in my current role, I understand how much of a poor mindset that was. Firstly senior developers are not gods, although as a junior developer sometimes it does seem like they are able to understand things quicker, figure out issues quicker. The reason for this is simply that we have made more mistakes, and so we see an issues and are able to reference a much large larger set of mistakes to decipher what is going on. Which also brings me to the next point.

• No one is nearly as smart as you think they are

As a junior developer, senior developers often seem a lot smarter and just generally very confident of our abilities. This at times can make it seem like we are really smart. The thing is yes most people in our field are pretty smart individuals, but I guarantee you that it is very rare that the person you think is so smart is really even nearly as smart as you think they are. Experience is mostly the key here, now sometimes there are individuals who are really really smart, genius level, however it will be very rare that you ever work with these individuals. Not saying you wont, but just based on numbers it is unlikely. So try not to be intimidated by these individuals, especially the individuals who are overly confident or cocky.

• Few are as smart as they think they are

The other side of the spectrum is people who think they are really really smart. Generally the rule of thumb is if they think they are geniuses, they are not. I have met only a couple certifiable geniuses. The kind that are so smart that their brain has overcompensated in one area and often social skills is the first thing to decrease, which maybe they could explain to me. Anyway most people think they are above average, however again just by numbers most likely that person is simply average. Not that they are not able to be great developers, but they most likely are not that much smarter than you. The difference between a junior and senior level developer has less to do with how smart they are and more simply how much experience they have and how willing they have been to fail, and even more importantly how willing they are to learn.

• Debugging is your greatest learning tool

Debugging is super fun, honestly if you don’t like debugging then most likely you are in the wrong career. Writing code is actually probably what you will do the least. Well I would say hopefully it is the least and hopefully most of your time is not spent in meetings or dealing with bureaucracy. Ideally a developer will spend most of their time either thinking or visualizing the problem set, or debugging to get an understanding of the problem set. Cases where this may not be the case, may be in fields that I have less experience in, however even then I am guessing that the figuring out the solution (not actually writing code) is more complex. Granted figuring out the solution may involve prototyping, but I think you get the point. Anyway, back to debugging, this is where you can get into the nuts and bolts of how the software works. And if you didn’t write it, documentation, API’s and the code can give you a lot of insight. But seeing it work in action and tweaking things as you go to see the effects is honestly fun. The rise of open source has opened this up so much, and I have personally enjoyed debugging open source projects to see how it works.

• Always be Learning

I initially had this heading as “Always be reading”, however felt that this encompassed the idea more. You should be constantly learning in your job. Often times this means that you must be reading a lot. But this career is constantly changing. Also understand that you will never ever be able to understand it all. But even basic understanding of different fields, even fields unrelated to computer science can be helpful. It develops a mind that is always in pursuit of knowledge and always trying to figure out solutions to puzzles. Never stop wanting to learn, when that starts happening maybe it is time to retire this profession. There will always be new things to learn and don’t let your seniority get in the way of your learning. Sometimes people will stick to things they know because that is how it is always done. Listen to people with less experience as often their insight is invaluable as they don’t realize that their suggestion is “not correct”.

These are just my random musings, there have been various other things that I have learnt over the years. I think the last one is my favorite. It is a great career to have because it is constantly changing, there are constantly new challenges, new boundaries to be broken and new ways to develop things. Don’t forget to continue to be having fun, if you aren’t, find a new job, start up your own software company, contribute to an open source project. But don’t let yourself get stuck in something you hate. As Steve Jobs once said:

“You’ve got to find what you love. And that is as true for your work as it is for your lovers. Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven’t found it yet, keep looking. Don’t settle. As with all matters of the heart, you’ll know when you find it. And, like any great relationship, it just gets better and better as the years roll on. So keep looking until you find it. Don’t settle…

Your time is limited, so don’t waste it living someone else’s life. Don’t be trapped by dogma — which is living with the results of other people’s thinking. Don’t let the noise of others’ opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary.”

Choosing the right technology.

This has come up for me multiple times in my career, and recently I was messing with building a web application and was trying to figure out what Web Framework I should use to build it. This can be a very divisive topic, everybody has their favorite something. The technology they think is really top notch and should be used all the time. I have my favorite technologies, and they have changed over the years. But I also love learning new things, which sometimes can be a problem when making decisions like this. I would say that no matter whether developing is just a hobby to you and you are messing around, or you are a Software Architect at a Fortune 500 company choosing technology that could have billion dollar impact, the decision to make is a similar one, just with different implications. Obviously if you are doing it for fun, the implications are simply at worst a waste of time. If you are an Architect at really any sized company the worst case can be really bad. So how do you choose a technology?

Throw out preconceived ideas

This is the most important first step. Leave your ego, or your preferences by the wayside. If you had a bad experience with Postgresql years ago, don’t let this get in the way of evaluating the software critically and fairly. Node.js is having a huge impact on the web world, and Javascript is still as massive as it ever was, much to the chagrin of backend developers. Sometimes something like Node.js is a useful tool. We love to tout our favorite technology, but rather listen to communities. Some are very vocal, others are smaller, but if you filter out the passion you will get a great understanding from them.

Everything is a tool in the toolbox

Every bit of technology built has a use, and it is simply a tool that a developer can use to achieve their end goal. No one has ever complained that people don’t use wrenches enough and should rather use screwdrivers. It is a stupid argument because people understand the uses of each tool and use them accordingly. Of course software is infinitely more complex in it’s usage and defining which is the best can take a lot longer, but if you look at them simply as tool’s you can focus on getting to that answer instead of just choosing the tool you want.

Developer resources is a factor

This is an interesting one, because it can go both first. Firstly if all your developers have spent their career in .NET and you are thinking of switching to Java then you have to evaluated the pro’s and con’s of that. Let’s for arguments sake say that Java fits perfectly in what you are trying to do. Is the man hours that will be inevitably be used in learning a new language be worth the payoff? Sometimes that answer is yes, other times it is no, and sometimes it is in between. But it definitely should be taken into account.

Understand your requirements

Often times we make decisions based on the technology without actually understanding the requirements. This will cause us to focus on what we want, rather than what we need. Kind of like the concept that if you have a hammer everything looks like a nail. And sometimes you can get that to work, but as developers I think we have all hated those guys when we find ourselves in control of code that was built because the original developer loved technology X.

Understand your restrictions

I think this is just as important as the requirements. It is important to understand what is needed. I recently watched a great talk on the comparison between Play and Node.js as a web application framework to use. I thought it was a well balanced talk and one of the points was related to time. Basically Scala is not an easy language to learn, and the idea was to build out a working something in 2 weeks then Node.js probably would be a better choice. Some backend developers may balk at the suggestion of using javascript as a backend web server, but he had a point. Scala is a difficult language to figure out sometimes, whereas Node.js seems like it is dead simple to get things going. This may have implications down the line but if you have a hard requirement like 2 weeks, then it probably would be better to use Node.js.

Stay away from Flame wars

Linux vs Windows (vs Mac), Java vs .Net, C++ vs Java, MySQL vs Postgresql vs SQL Server, etc. etc. etc. Everyone gets burnt in a flame war and rarely does it produce anything productive. They are all tools, if someone is developing on Windows with .Net and you are “true” C developer on linux then that is fine. Just be awesomely thankful that both of you have the intelligence and joy or developing software.

Mac’s vs PC

I will comment slightly on this war because for most of my career I coded on a Linux PC (spent a little time in Visual Studio, but not a lot) and started to code on a Mac. You can read a little about it in this post. I switched reluctantly as I had always been extremely negative about Macs, so much so that now both my younger brothers have a certain hatred to all things Apple. I know can’t imagine not developing on my Mac, and I went through a time when I was trying to convince everyone that Mac’s where the greatest thing since sliced bread for developers….all those other people using Macs were posers though and didn’t even realize that they had the power of a shell at their fingertips. Anyway I have realized the stupidity of that minor stage, because in the end it is simply a tool. And if I had to start my own company I would not buy Macs, not because I don’t think they are amazing machines, but because I would imagine one of my restrictions would be money and a Linux PC is still damn good. Anyway all that to say, don’t think you are better because you chose technology A. Remember it would pretty much be like laughing at someone because they were using a hammer when you had this awesome screwdriver.