Andrew Tso, Founder + CTO: Deep Development – Exploring Business Multiplicities

Andrew Tso, Founder + CTO: Deep Development – Exploring Business Multiplicities

Owning greater responsibility as a developer is the root of strong business acumen.

Andrew Tso is a hands-on technology executive, co-founder of RocketReach, senior engineer and product development leader. He’s empowered (and built!) multiple companies, teams and revenue growth strategies with high-impact results.

In this Codecast, Andrew swiftly shares his own path to software development, why it's great to work with others smarter than yourself, having passion for what you build and pithy business prep takeaways wrapped in software development done well.

Key Theme » Build Possibilities

"The one advantage I think engineers have is if you have built something, you can kind of easily figure out what’s possible. That may seem obvious to an engineer, but to businesspeople, they aren’t able to do that. You can create a plan that’s actionable, just by knowing it can be built, based on your experience. To the extent possible, having any sort of technical skills, even if you don’t decide to do it for the rest of your career, knowing what’s possible – it’s hugely valuable. It will help you understand other businesses, other products just because you will have a sense of how something works." – Andrew Tso


"Then if you’re entrepreneurial, that’s another route you could take. But if you’re going to take a job coming out of school of this nature – you don't have to pick an already established company – but you should definitely evaluate the business. Learn to evaluate the business that you’re joining, in terms of: is it a good investment and what are the people like, what are their hiring standards?"

"It’s not just about you getting stuff done – it’s about creating a framework for other engineers to be productive."

The Codecast

Watch on YouTube

Full Episode » Transcribed


Alright, hello everyone. Welcome to the Viking Codecast.

This week we’re joined by Andrew Tso who is a very accomplished developer who we are very lucky to have. I say developer when really I think it’s much more multi-talented than that. He’s the Founder of RocketReach, a much bigger than a one person company. He’s done coding, he’s been CTO, he’s been a cofounder, he’s done all sorts of interesting stuff which I really want to hear Andrew in your own words, but today really curious to hear more about your evolution and journey from the coding side up into the different levels of organizations that you have both founded and been a part of, and then some of the tips from those different levels along the way that you could potentially offer some people who are much lower down on that journey and looking upwards and wondering how do you start taking those steps.

Let me first say welcome and I would love to hear just a quick little bit about how you found your way here to this particular point in your life.


Thanks for having me. So, I guess to answer your question, I guess I first started getting into computers, I was fairly young. It’s kind of interesting; the answer to why I got into this field was – video games! (Laughter)

As a youngster, I got my first computer probably when I was around ten-ish, it was the Mac Plus which at the time was a three thousand dollar computer, it has a megabyte of memory. It had floppy disks which I had to change out because the operating system did not fit on one floppy disk.

It’s kind of funny and I probably shouldn’t be saying this, but what really got me into it was video games and the interesting thing I figured out when I was young, my friends and I actually figured out how to copy Super Nintendo cartridges. It’s kind of funny, we figured out how to both copy them and also trade them – yeah, it just got me into hardware, it got me into building computers, it got me into just learning the ins and outs of how a computer works.

I attended UC Berkeley for Computer Science that brought me to Silicon Valley which is probably, looking in retrospect, one of the better moves I made in my life. All the innovation is really happening here, you’re surrounded by great talent. There’s great talent, great ideas and the capital to produce great companies. It’s an awesome place.


What else can I answer for you?


I think we actually have a number of people listening here right now. You got into this from video gaming; I don’t think there’s anything new about that. I guess hackers have been around ever since – it’s been a very long time. I remember hearing stories from my dad in his MIT days, they would hack the long distance phone services and things like that, so a lot of reasons to get in.


I’m curious just to maybe hear a little bit more about the journey that you took moving from an interest in computers through computer science to then entering the professional world, and what was the era like when you got onto the workforce and then what was that transition like going from school to working?


OK, definitely – this will probably date me a bit, but I have been in the workforce for roughly two decades now. It was actually a very interesting time. I got to see the transition by pre-internet to post-internet; it just is a stark difference both in the productivity for the average software engineer. You just start to see the beginnings of hardware – people can say it doubles every two years and memory is doubling and whatnot – but when I first started, the computer science division essentially had several computers which were probably altogether less powerful than your phone. Actually, less memory than your phone. You would have two hundred people "sharing time" on a system to program.

What that would mean, in sort of an anecdote, we would program in C and you would write your code, submit it to compile and then you would probably wait a good 30 to 45 minutes – if you were lucky – before the program finished compiling correctly.

To kind of illustrate some of the pain points in that – if you had a syntax error, say you forgot a semicolon, you may find out like, 15 minutes later and you’re like "oh—I forgot a semicolon!" You would have to go back and fix it and start all over again.

It was a very, very different time. It was like a "workstation" era back before – most people didn’t have their own computer until probably like my senior year, around 1995/96 timeframe. It was very, very different, and what that translated to, going to the working world – the cost structure to start a company was magnitudes different than what it is now.

The legacy of expense in software creation.

If you think about, there have been a lot of things we take for granted that work different from back then. One thing was it probably costs; if you wanted to professionally program, it would probably cost you around $60,000 or $70,000 a year just to do that. What I mean by this is you had this workstation you had to buy and the last one to go out of business was probably Sun. But then there was HP, IBM and they sold you an expensive piece of hardware which was the price of a good midsize car.

You would buy this workstation, there is a software maintenance, you had to pay for an operating system, you had to pay for the compiler. The data structures that you use right now, you either write them yourself or you could license the equivalent of STL or one of these standard libraries, you would have to license it for like $7K a year. It’s just different, now you could buy a $300 laptop, your compiler is free, you’re using these great frameworks which allow you to quickly get something up and running, whereas back then...

My first job after school I joined Oracle and the division I was in was called Service and Technology. There were over a thousand engineers in this group. The reason why you needed that much manpower was because – the product was the Oracle Database. I guess the interesting thing about that is I have actually have code that might still be running, maybe 20 years ago – its own production which is kind of like the testament of good engineering if you have something that’s been running that long.


Or, no one can figure out how to change it. (Laughter)


Yeah. It took a thousand engineers to build out this part and sell it across all the different workstation platforms. It’s just very, very different. You needed teams that large just because all the things you take granted to get you to the point where you could actually be productive and write code that could potentially face a user, you had to write yourselves.

For example, Java, I’m not sure if you guys learned, but it’s infamous for being cross-platform compatible these days because Intel sort of won the hardware wars. You’re basically just targeting an Intel processor, back then we had to write a basic virtual OS to be able to cover the ten different flavors of Unix.

What that kind of means, for every operating system command you might think of, like opening a file, you had to actually extract that, you had to write an extractor so that you could write code once and actually compile it to the five flavors of hardware and the different processors and the ten different types of operating systems.

Every time you released software it was a feat!


So, how different is it / how do you think it feels from when you stepped on – I guess you were kind of cutting your teeth right up leading into the Internet Bubble 1.0 and the kind of roles that a programmer would step into. You were saying you were part of a thousand person team building, presumably a very small slice of a very monolithic code base. As opposed to someone who can now call themselves a product developer and can step in and start firing out UI widgets and backend services day two! How do you characterize that difference and how does that feel?


From an engineering standpoint, I think most engineers know there’s a much higher degree of satisfaction simply because a single person – like you’re pointing out – can basically build something consumer facing and potentially even money making by themselves, and that was probably impossible. Not impossible, but very, very unlikely to happen twenty years ago.

To give you an example of my type of role, I started off as a front-end guy, but I was a compiler front-end guy meaning: that I worked on the parser and then basically the types of syntax and the types of errors that would be emitted from the compiler to the user.

Now I was, maybe one of three or four people working on just that one piece which was a tool that was used by other developers to develop the Oracle Database. So very, very different. Between 1996 and 2000, salaries probably doubled to tripled – the internet just brought out, it was like an open field. Every time a new platform or release...there was this wave of innovation that built upon it.

I was fortunately able to join several very interesting startups very early in my career; at the time, I thought they were pretty revolutionary. So I left Oracle, after about two years I joined an internet advertising company called AdForce and it was one of the top two display advertisers at the time, after DoubleClick, which is still around. But essentially the idea behind it was we would crawl websites and figure out what the most distinguishing keywords were on a page and then target ads against it. It essentially was AdSense – the technology was display advertising versus search advertising – but it was a phenomenally interesting idea at the time and we kind of rode the wave.

We got to the point where we were serving close to a billion ads a day – which probably isn’t as much now, but back then Yahoo! and (0:13:14 inaudible) were two of our bigger customers. We were serving most of the internet, most of the ads on the internet – which is kind of a phenomenal thing to think about, at least back then.

I am probably rambling a little bit, but, as I have gone on in my career the trend has been that the teams have gotten smaller. The cost of creating companies has gone cheaper so you can do – it’s just a phenomenal amount, essentially like two people. Two people – if you think about Instagram – I know those guys from my last company because we were in similar space, but they essentially created a service that serves hundreds of millions of people and I think they only had four people – up until the point they were acquired by Facebook.

Long story short, if you have the right idea, it’s possible for you and a buddy to kind of make a big difference in the world.


Yeah! (Laughter) I think it’s very interesting for people these days. If you have only been learning software development for a year or two, you don’t necessarily have a lot of context as far as where did it come from and I think it’s really interesting to get a sense of perspective around what it was like to work in a team fifteen years ago, or twenty years ago, and then ten years ago and five years ago. It hopefully gives us a good sense of perspective as far as what could be possible in the future. But actually in the realm of kind of walking things backwards, I am quite curious to hear, especially from folks who have lived through Internet Bubble 1.0, how did the downturn affect you and where you were and the teams that you were on and things like that?


I guess the one piece that I learned that is probably somewhat relevant to the audience: you’re going to go out there at some point and get a job and it’s sort of important understanding – especially if you’re at a non-profitable company – just what you’re sort of getting into.

Track your company's financial state.

Capital was like free-flowing back then, maybe somewhat akin to how it’s been sort of thrown around recently in that companies raise $40,000 and then blow through it. I’ve heard crazy things about companies blowing through ten million just for a launch party. You have to – for me personally, I was part of a company that was actually making money – we successfully went public. We were actually bought by one of the big tech companies at the time, CMGI which was basically built on top of a house of cards. So when their stock valuation basically went down maybe 95%, they had bought somewhere around 50 to 80 companies and they didn’t know what they had so they actually should have – it’s kind of interesting. They started moving our business and they had one that was, the first one engaged, they basically tried to move all our customers to engage and they attempted to shut us down.

It was actually quite shocking to have a company that was kind of on its own power, was publicly listed and then immediately because of finances, cost-cutting, it just disappeared. I actually left AdForce before it was shut down and joined another company that was doing the equivalent of, Google Analytics. We were doing analytics as a SaaS service, but it was paid.

Also sort of interesting, so when the bubble actually did burst; the investors clawed back money which is also possible when you raise money, if you don’t have control of your board. They decided to cut their losses, and that was the one time in my career that I actually got laid off!


(Laughter) Gotta happen once!

Evaluate career options with a long investment view.

I guess long story short, whenever you’re evaluating your job potentials, there are multiple things you have to look at. When you’re first getting in there I think the primary thing that you want, at least for me from my perspective, I think there’s probably a year or two where I think it helps to be part of a good team where you can actually cut your teeth a bit, essentially. But you want to be on this path where you’re constantly learning and as part of that, smart people usually gather around the best opportunities so you kind of have to both be able to notice a good business opportunity so you have a chance to kind of grow and also if a company is doing that, they will probably acquire the best talent and so you want to put yourself into the best position possible. At least, that’s the way I would look at it, a job sort of in my career.

Then if you’re entrepreneurial, that’s another route you could take. But if you’re going to take a job coming out of school of this nature – you don't have to pick an already established company – but you should definitely evaluate the business. Learn to evaluate the business that you’re joining, in terms of: is it a good investment and what are the people like, what are their hiring standards?

Your team determines company value & outcomes.

One false positive could be: you could join a company and it could be really, really into you but if their hiring practices are poor, they will probably attract poor talent, overall. So it may not be the best situation for you. The harder the interview ... it’s sort of an indicator of potentially a company that might be able to have a good outcome, just because you need to attract the best talent and being part of a team with talented people will increase the velocity that you learn. So you definitely want to try to take advantage of that.


How do you find those teams, especially if you don’t have a preexisting network?


That’s sort of a great question, it’s interesting. The way things happen now versus before... In the past getting a degree for computer science from college was sort of like your ticket into these places. But more and more transitions are in a skills-based economy. The way they evaluate you isn’t just like: "did you go to some top tier school for computer science?" You have the ability to put your work out there and for the most part, most recruiters now and hiring managers, they will look at you. Not just to get a sense for who you are but if you have code out there. That’s the best way to figure out whether you’re capable, and what you’re capable of.

To the extent that you can work on projects that are on GitHub or whatnot, definitely do that and definitely list them on your LinkedIn or your resume. I think if you get somebody who’s really trying to find a gem – because it’s really hard to find people these days – people will get through your code. And if you have worked on an interesting project or shown some aptitude – it will increase your chances that they will reach out to you and ask you to interview.

But in terms of finding good companies: you want to put yourself in a position to where you talk to as many companies as possible. A couple ways you do that, now, are a little different. There’s a service out there called Hired, but essentially it’s like a reverse auction for hiring where instead of you applying for a job, companies are applying for your services. Definitely check that site out. To the extent that when you’re looking, just try to get in front of as many opportunities as you can. Engage with recruiters, reach out to hiring managers directly if there’s something you’re interested in, ask friends. You want to put yourself in a position to where if there is – at any given time you want to give yourself options.

You want to look at a company and have multiple situations you could potentially get into and just pick the best one. Don’t get lazy when you’re looking for a job, and you don’t have to take the first job that’s offered to you!


It’s all about the hustle!

Just to continue forward with you Andrew, one thing I was kind of wondering was, and I guess this comes kind of chronologically speaking, after you kind of survived that layoff situation and moved on to the next role, the next role you had was much more the managerial side. I’m curious, how was that transition and what did that teach you? How did that perspective change the way that you might have viewed your path up as a developer?


Steps toward becoming an engineering lead.

One of the things, engineering unlike maybe other professions tends to be slightly more merit based. Meaning, in order to be an effective engineering leader, you have to be technically strong. To the extent it’s hard not to have like strong aptitude. There’s a progression, when you’re starting off as a more junior engineer – just focus on trying to get functionality working. Then as you are moving up the chain, then you get more responsibility, maybe you start to design more. It may be you’re even taking customer requirements and figuring out how to build something, but you want to get to the point where you can interact with a project manager or a CEO or whoever is giving you project features and be relied upon to basically build the important pieces of functionality of any service.

At some point when a company gets big enough where all of a sudden, when the engineering gets to around three or four (people) there’s a little bit of overhead that needs to happen in terms of coordinating and making sure that the part you’re building is equitably split up, so you have a division of labor and you’re able to move as a team versus relying on individuals.

For me, I was fortunately given that opportunity somewhat early in my career. The transition was not difficult, just your perspective in terms of what your focus is sort of changes a bit. It’s not just about you getting stuff done – it’s about creating a framework for other engineers to be productive. I think if you’re coding, this will sort of come naturally for people at around maybe, the five to seven year mark growth for a lot of engineers. Where they have accomplished enough that they’re not worried about the mechanics but they can also take on the additional responsibility of making sure a project completes with resources they are responsible for.


So from your perspective having gone through the process of building teams and trying to identify developers, can you just put us inside your head a little bit in terms of when it becomes clear that there’s a need in your organization to bring someone new onto the team – how do you then walk that forward in you need to specify the role and identify somebody to fill that role – and then interview them.

What’s going on inside your head so that we can, as potential interviewees, get a sense of why you’re on the other side of the table and what you’re actually looking for?

How to build a quality team.


It really depends on the size of the organization that you’re building. In general, my preference personally is to hire, I guess what they call "generalists" or full stack engineers. Think of yourself as if you were implementing a product by yourself and you have to understand all aspects of like how the product works. I feel like, devoting both that mentality of being able to take ownership, "these are the features and this is how we’re going to do it, these are the technologies we’re going to use, this is how we’re going to structure our code."" That mindset you can’t get enough of – people that are just able to build without additional help from anybody else.

Once you’re able to do that, it allows you to be able to transition to public, where if the big team gets big enough and you need to set up some kind of reporting structure – you can be comfortable taking those type of folks, people who are more specialized, and make them productive.

As I was saying it really depends on the organization, early on I would probably hire a full stack generalist and probably for the five, six hires, maybe. Depending on what kind of product it is. And then you start filling out the team with things where your skills are maybe lacking. A lot of times many good engineers tend to not be great at doing markup or maybe they don’t like doing front-end, in which case you should focus on somebody else who is comfortable doing CSS, JavaScript that kind of thing.


How do you know when you’ve found a good one, though? How do you actually seek, locate and identify good talent?


That’s actually a great question. Somebody from my side, again I have a relatively wide net in that I would try to consider as many candidates as possible. The one interesting thing is it kind of depends on how much – it’s definitely harder to recruit at a smaller company. So in a very, very small company I would probably go to people I know.

Say you’ve raised your Series-A now you’re just looking to hire on, also for all the hires I would probably get referrals, too. Just because it’s really hard to find good talent, and so if you can get someone to vouch for you that usually speaks volumes. There’s a lot of things that kind of influence whether a person will be a good fit, there a technical realities, but also important is how well you work on a team.

There are people that are kind of really talented but are sort of lone wolfish, someone that is more territorial about a code. There’s all these things that could happen that may be undesirable from a team perspective, but you want someone who is 1. smart, 2. works hard 3. gets things done and 4. is team oriented. You have to like the people you work with otherwise, especially with deadlines, you want to create a dynamic where the team is communicating and working well with one another.


So instead of referrals, or beyond the fact you ideally would like to have someone to vouch for this person. How do you specifically identify whether or not someone has those skills if you aren’t maybe quite as familiar with them?


I will look at people’s code, if it’s out there. It kind of gives you a sense for how organized they are. One thing I sort of like to see from engineers is I like engineers who create readable code. Writing code in some ways is kind of like writing a paper.

If you revise your paper enough times it sort of gets better and more maintainable, I definitely look at people’s code. And then in terms of, the real test is when you bring them in for an interview. Just my own personal style, some senior people may have problems, but I like having interviews built on something. For one thing it measures all the things that I guess would be required in the real life workplace which is, you’re going to be giving features, some problem set which you’re going to have to kind of internalize and figure out how to create a working system for.

My personal interview or one of them, tends to be I give you some time to build up something. It could be something like build me blackjack or something like that. I will give you maybe a code structure and make sure there is language within and just have you see how far you can get in the amount of time allotted.

One thing that all managers want, we definitely want people that can take the objectives of the company, translate them into working code. Then there’s all the other soft skills that you need, you want them to be reliable, be able to communicate well, communicate efficiently, which would also be determined through the interview. The primary thing is, if you can code, I'm interested in talking to you! So, from all your perspectives...coding is one thing I feel like it’s a steep long learning curve and the more you do, the more things you build the better you’ll get at it and stuff like an interview will come easily if you build enough things.

Just keep your mind open, build stuff and always be on the lookout for new technologies, too.

I don’t know if I completed your question.


Was there a question, Andrew?


Andrew, great advice by the way, I’m soaking it all in. I do have a question though in terms of communication. So you talk about how you worked on the business side as opposed to just coding and on the engineering side.

What effect has working on the business side or non-engineering roles, how has that changed your perspective in communicating with others? Not just as a coder, but how to effectively communicate what needs to be done, how to connect with people, just generally how to connect and communicate effectively?


Yeah. The one advantage – it’s kind of interesting actually, the one advantage I think engineers have. If you have built something you can kind of easily figure out what’s possible – and that may seem sort of obvious to an engineer – but to businesspeople, they aren’t able to do that. You can create a plan that’s sort of actionable, just by knowing it can be built, based on your experience. To the extent possible, having any sort of technical skills, even if you don’t decide to do for the rest of your career, knowing what’s possible it’s hugely valuable. It will help you understand other businesses, other products just because you will have a sense of how something works.

Yeah, it’s a great advantage, I don’t know. In the Bay Area it’s probably definitely necessary, but yeah, definitely a strong card to have.


Great answer, thank you.


Any other questions from you folks here or anyone else outside? I certainly have a few here as well but I want to make sure everyone has a chance.


A quick follow up, are there any – just a follow up to my previous question. Are there any red flags that you’ve seen in the past teams and past engineers, like things that are not good and things that could be improved in general, like any stereotypes?


Scale through design & infrastructure fundamentals.

In some ways, yes. There’s one thing that I sort of noticed with this newer generation, the productivity tools and the way that production has advanced. Most technology now is geared to making the developer able to release a feature very, very quickly, and one of the things I think is somewhat important is to have a solid understanding of how the internals of things work. What I mean by that is traditionally the way Cal (UC Berkeley) teaches its curriculum, they teach it as this pretty set – the curriculum is such that you learn basics. It starts with maybe how a processor works, how memory works and then you learn assembly, you learn C and then as you go up, the systems build on top of those things. Those core things, like operating systems, compilers and databases. Three things I think people, if you have the time, just try to take a course to understand how they work. It will help you in a variety of ways so that when you’re actually in an interview – you can make better design decisions about how to structure things.

One of the things—I’m probably talking about this a little too much, one of the interesting things is you have to be able to scale a product to essentially everywhere out there in the world. I think those fundamentals help you understand how to build the next layer and sort of the next layer up, so when you’re at the point of creating a service that virtually any element of traffic can see or a large amount of traffic can see, you have to learn how to build that. There’s a variety of skills and things that you will have to learn and you will never understand them until you understand the basics.

I don’t know if I completely answered your question.


No, you did thank you. Here, when we learn things at Viking Code School, let’s say we’re learning Ajax for instance – we actually build Ajax from the ground up using JavaScript so that really kind of helps understand what’s going on under the hood. I feel like that’s a very good approach in learning things before using them or while you’re using them, so yeah, that’s a great answer – thank you.


In terms of red flags, technical depth. You will definitely see, just to kind of give you guys – people will, if they come from, depending on their age – some of them will ask you core CS questions in part of interviews. What I mean by that, is "what’s the difference between a point and a reference?" They’ll ask you things that they think a person should know and it may trip you up if you are completely caught off guard and don’t understand it.

It’s kind of weird, the culture is to not have a false positive in hiring. Unfortunately, the way that sort of translates tactically when people do interview, is they will sometimes ask you things – they may not necessarily be fair but they’re trying to make sure that they aren’t putting on somebody that is actually going to be detrimental to the codebase essentially.

Just be prepared for that, that’s sort of part of interviewing as an engineer. But other than that, answer truthfully, think through your problems, speak clearly, explain your designs, explain your thinking when you’re on the call and interviews and that will give you the best shot at trying to get an offer.


What makes up the "perfect hire?"

So, can I actually flip the question on its head a little bit and ask: what do you think are the characteristics of the ideal developer? The perfect person, the perfect hire?


That’s very interesting. The perfect hire, huh? OK, for me it’s a combination of a couple things. Completely technically proficient and by that I just mean you should be able to take any feature out there and sort of know how to build it, but beyond that one of the things that is sort of underrated that has a really deep impact is having good judgment or common sense, that would be my second one. One of the things, you can spend almost an infinite amount of time in proving code but knowing when you have something that’s sort of good enough and how to essentially manage your time to such that you’re actually providing optimum value for your time – is sort of like very hard to test for but very, very important. Then having a good business sense, a good product sense, is what I should say.

The last thing most product people want, and when I say product people these are the people that are kind of in charge of telling you what features to build. The last thing a product person wants is to have to articulate point by point what’s needed. They would like to be able to, at a very high level, kind of give you what they want built and have you just follow up with that questions, in terms of where it’s ambiguous so they don’t have create this massive spec to get something implemented.

Technical skills, good product sense, and then good judgment would be my top three.


And I guess related to something we were talking about before this started, you mentioned kind of the role of passion and specifically that there are some folks who maybe were not as passionate about development who got into development through college, or maybe some decision that was made long ago. Do you mind just kind of talking to the role liking what you do has and the growth of development of your career?


The thing is, regardless of what you decide to do in your career. Learning the stuff is hugely valuable, so there are people who decided not to – as an engineer you have actually a couple of options once you sort of graduate I guess.

Going to the point, just knowing and being a former engineer that usually puts people in an OK position to be a product person or project manager simply because as long as you can articulate features in a way that allows an engineer to build them and you can shift to becoming more business focused.

These days another really common thing you hear about are these growth marketers. I think at almost all levels now in companies, having technical skill can allow you to do certain job functions extremely efficiently, just with like a little bit of programming.

Some of these roles would technically be not building a product but you’re building something that maybe drives traffic or figures out how to buy traffic. Knowing how to program definitely, you may be your primary skill but it will definitely serve you well. If you think about it, you have some tedious task you have to run or some task where like the decision making can actually be encompassed in an algorithm, if you can code it. That makes you infinitely more efficient and if you don’t have to ask somebody to do it for you, that makes you just even more valuable.

Passion for development births efficient mastery.

Just having the skill I think is good but the people who are really passionate about building things, eventually I think if you put enough time into anything you will eventually become almost a master at it.

That part I think is definitely key if you want to have a long career. One of the things, technology does change, so over the course of just my career. I first started off programming C, C++ then I did Java for about ten years, I did Rails, .net, Django. I have probably built in almost all frameworks at this point and it’s sort of added necessity in some ways. These frameworks have definitely gotten more productive over time and things will continue to change.

Objective C and Swift may be popular now but there’s no guarantee of what’s going to happen five or ten years from now. You have to love technology because you’re going to have to learn and continue to evolve as your career goes forward.


Great. I know we have to be conscious with your time, so I think maybe if it’s possible we could leave on one note which is one I typically will ask which is that:

If you were sitting in these seats, if you were at this phase in your career talking to the you who is now. You who is now, what is the advice that you have for the younger, fresher, earlier version of yourself?


I guess, I don’t think I have the ability to maybe do this as much as when I was younger just because of all the things I had mentioned about, like it being hard to start. It was harder to start a project on your own, but to the extent that now you can, especially when you’re looking for your first job try to build something that you can demo.

Build demos others can use!

I think actually having a demo for you guys going out there is probably one of the strongest points you can create, and also do something that you’re passionate about. I think that will allow you to put the time and effort and love into it to make it something that’s impressive.

Yeah, get out there and build something and try to get people using it. I have seen a lot of great ideas, but if you can show passion for something and put that in code, I think it will be a first good step into your careers.


Thank you so much for that Andrew, and thank you everyone else who’s here with us right now and who’s listening now and later in the future. This is the Viking Codecast with Andrew Tso and I just want to say thank you everyone, thank you Andrew and that’s a wrap for tonight.

Have a good one.


Thank you.

Contacting Andrew


From n00b to ninja, we'll help you to become a developer
Subscribe to get expert guidance on learning, building, and getting hired delivered right to your inbox each week.

We guarantee your privacy 100%. Your information will not be shared.