Matthew J. Martin, Founder, Front-End Engineer: Career Mentorship Advice for New Programmers + Job Seekers

Matthew J. Martin, Founder, Front-End Engineer: Career Mentorship Advice for New Programmers + Job Seekers

On FinTech, startups, serving others and cultivating a discovery mindset as a new developer.

Matthew J. Martin is CEO and Founder of Blossom Finance. He's also a seasoned, self-taught front-end engineer, full stack web developer, Product Lead and UX aficionado!

In this Codecast, Matthew gifts a sharpened, lively view into the FinTech (financial technology) world, shares his own winding path into software development, makes the case for why being crystal clear in what you do (and don't want) only progresses your career, and shares timely tips on current tech company hiring practices.

Key Theme » Build to Serve

The big things for me were – it had to be pure software. It’s “helping” the world, it’s making the world a better place. I didn’t want to do social networking or consumer apps, like entertainment-related consumer apps. I wanted to do something that falls under that “umbrella” (of helping the world). I’m putting it in quotes because you actually have to look under the hood at what it’s doing. At least, as an “umbrella” idea, it’s making the world a better place, or it’s helping people. It’s providing a valuable, concrete service. (Matthew J. Martin)


"At the end of the day, as a software engineer, understanding the product and customer needs is actually very important – a lot more important than you might think."

"So when you’re at a good software company or on a good team, there’s usually a stack of tools that help you do your job. There’s like a pipeline to create, to produce code, to test it, to vet that code in terms of quality – does it satisfy the feature requirements – then move that into production. So there’s this whole pipeline, and generally in software companies – and good ones – there’s a very nice pipeline that you set up that’s automated."

"The biggest challenge for any startup is obviously time/money. It’s really money, because money can buy time..."

The Codecast

Watch on YouTube

Full Episode » Transcribed


Hello, welcome to the Viking Codecast. My name is Erik Trautman I’m the founder of Viking Code School. Viking Code School is a series of programs that are immersive, and flexible programs allowing students anywhere around the world to learn professional web development, and we train people from advanced beginner to job-ready.

Here with us today we have Matthew and he is – I don’t even know where to start – but he’s a former software engineer who is developing – who went through the development stack. Got fairly bored with development stack and decided to move into product (laughs), went back to development. Has been in the back-end and front-end. Has a journey through UX, as well and is currently founder and CEO of Blossom Finance and has been working in FinTech lately. He has all sorts of interesting stuff for us today.

So Matthew, thank you for joining us and first of all, welcome! My first question for you would really be how did all of this get started? I’m interested to hear how this journey has progressed over the last – what is it, 15 years now?


Yeah, thanks for the introduction Erik and thanks everyone for tuning in. So, straight out of high school I didn’t have the plan to get into software development. I kind of fell into it realizing, I need to do something to make money. My first experience with programming was in high school, programming a TI83 calculator. I don’t know what TI calculator is on the market now that people use in high school, for their upper division math, but that was in the back of mind. I had more fun programming my calculator when I should have been paying attention in class! Almost failed the one math class because of that, because I spent so much time actually programming the calculator, writing games and stuff like that.

Self-taught journey beginnings.

That was sort of the first tinkering. I sort of taught myself to program on the TI83. When I was a senior in high school they had a Visual Basic class, so that was my first formal class or formal education into programming. It wasn’t a very helpful class. The teacher that taught it was actually just a math major that they were like hey, "you know what programming is."

This was back in – I’m going to date myself here, but this was 2002, so 2001/2002. Then eventually realized, I was like I should probably do something tech related because I liked programming, that was kind of cool. I started taking some classes at a private university, a private school called ITT Tech. Which some of you may have heard of which is a big rip off, a lot of waste of money. They sort of – rather than take the approach of private education like, let’s equip you with the best and most efficient tools, they sort of mock or mimic a more formal university environment – but with a lot of filler. As opposed to let’s get down and dirty, let’s give you the tools you need.

A strong work ethic leads to "lucky breaks."

That did give some important tools for software development, but really, my big break came when I was working at a Home Depot and I made a sale that had taken a long time. This guy came in and he had wanted all sorts of things. So I was driving forklifts around, pulling stuff off the shelf and running every which way. Just trying to give him the best customer service I could. At the end of the sale he shook my hand and he’s like "you know, I could use someone like you at my company. You’ve got a really good attitude; I actually have an electronics company." He later told me my face lit up like a light bulb and I was like – oh yeah!

I was like "Wow! This is awesome." So he actually hired me to work in shipping and receiving. It was not a programming gig – but it was a foot in the door. That’s kind of how I got into the industry.

A few months after that the general manager came through the shop and said, "You know how to program? Why are you putting boxes together and putting stuff in boxes, you should be writing programs. You should be using your skills." So that was sort of my lucky break. That sort of got me my first paid programming gig, was at Benchmark Media Systems.

That same general manager later moved back out to Silicon Valley and was like "dude, if you want to really advance really quickly and really be on top of your game, you really need to come out to Silicon Valley or come out to California." He encouraged me to do that. I did do that, I ended up taking a position at Logitech in a business unit that – Logitech’s a hardware company. If you don’t know their name, look on your desk you may have one of their mice or keyboards sitting on your desk.

Getting into the Financial Tech realm.

I worked on a music product, a network music product that had a heavy software component to it. Basically, got sick of spending a lot of time and sort of like working long hours and burning the candle at both ends every year to make the Christmas rush to get products on the shelf for Christmas – that will be in a landfill in two years. So I kind of got burned out on hardware and I was like, "what can I do in the pure software field?" That’s how I got into Financial Tech (FinTech). I figured, I want to do something that’s not going to end up in a landfill and that’s going to help people’s lives or generally make the world a better place, in theory, right?

That’s how I got into financial services. I was at Xoom, they do mobile money transfer – excuse me, money transfer, so family sending money overseas to their family back home. Then later moved to Boku, they do mobile payments. Later I went to Monitise, they produce mobile banking software, and then later made the leap to do my own venture.


How did your role evolve though, from that initial web development position? I guess it maybe wasn’t necessarily development. You got picked up by the GM who said you know how to code, code some stuff for us. How did that role evolve into working in hardware and what is it like working in software, in hardware, what does that actually look like?


Yeah, it’s kind of a cool, initial role; it was a lot of internal tools initially. It was working with internal tools like sort of homegrown internet kind of thing built in PHP. This was back in PHP-2 days maybe, I think PHP-3 had just launched. It was like building internal tools that were useful, basically just writing software that makes people’s jobs easier and gives executive management access to better information. Then, the cool part about it was, we had, in the factory environment there was this mobile barcode scanner. So it was like this barcode scanner and we put a Wi-Fi enabled SD card in it so that connected up to the network. I wrote a Java app that ran on this little barcode scanner that connected up to the mothership which was the intranet software that I wrote. You can imagine people building electronics. They go out to the factory and they scan a shelf. They have a bill of materials, when you make electronics you have a bill of materials – here’s all the thousand things that go into an iPhone, right?

You have to go in the factory and scan, you need 100,000 resistors of this value, so you go and you scan it and blah, blah, blah – it was like putting all that together. That was kind of fun. So I got a little bit of the network aspect, the fact that there’s a web application there and also there was a little bit of hardware aspect, too. We also had, I’m trying to remember the project it’s been a long time ago. We found an open source – it was a Windows barcode scanner but we didn’t want to learn C# or write C#. I don’t even know C# existed then. but we wanted to write in Java. So we found an open source virtual machine for Windows C, whatever it was, something like that.

We had to modify this open source virtual machine to run on this specific hardware, which is pretty hardcore – but it was fun, it was a fun experience.

Then the things that got me in the door – Logitech. Where it was like a music-related thing and I was working for an audio electronics company so it was like, "this guy knows audio and he can do software and web development." So just kind of the right fit. Had I been coming to a pure software role in Silicon Valley, I probably would have been way under qualified for that, at the time. It was probably a good interstitial role at Logitech. I had the resume that, maybe, was weak on the pure software side – if I had gone into a whiteboard coding interview and they’re like, "implement breadth first search," I’d be like, "I don’t know what those words mean," right? But because I knew, because I could demonstrate I can make web applications, and they were like, "this guy knows about audio," that’s how I sort of got in.


That’s an interesting thing for a lot of people that come from non-traditional backgrounds which are a lot of the people who are listening to what we’re doing now. They don’t necessarily come from a four year CS degree or a CS masters or anything like that. So they’re always trying to figure out how to stitch together their background and make that into something that’s a little bit more attractive than just guy off the street learned how to code and finds his way in.

What actually worked for you in terms of selling yourself along those lines?


Get Hired #1: RESEARCH company products & services.

One big thing, getting into Logitech, I knew their product. You can’t always do this depending on the business, but people like to be flattered. People like to feel like they’re important or people care about them, or they’re a big deal or whatever.

If you go into a job interview and you know a little bit about the product...The worst thing you could do, the worst thing – especially in a later stage interview and they (the interviewee) say something like, "so...what do you guys do?" I understand the reality of a job market, some people just get shopped around by the same recruiter to a hundred companies. But, if you can come in and be like: "So, I understand you have these products, these three products, but I’m not clear on like who do you actually sell this product to." At the end of the day, if you’re interviewing a bunch of companies. It should be a two way conversation – it’s not always – but ideally it should be.

If part of that conversation you can be on the other side and demonstrate that you have some rudimentary knowledge of what the company does, as an engineer you want to understand that side of things.

Sorry, what was your question? How do you sell yourself with maybe a non-traditional background. For me it was, I actually knew their product, it was a Squeezebox product so I actually knew the product, I had used it. So that was big. Versus, like when the Director of Engineering came in and said, "tell me about the last project you worked on," and he’s like "can you draw the architecture on the board for me?" I was like, "draw on the whiteboard?!" I don’t think I had ever drawn on a whiteboard in a business setting before. So that was very different coming into Silicon Valley.

The fact that I understood the product, I think that was big. People even told me after the fact that was a big selling point for me. It’s like, "yeah he seems like a smart scrappy guy and can probably figure it out – and he knows the product."




Get Hired #2: See job descriptions as mental checklists.

But to your point, any time you can – anytime there are things that are related, people like to tick boxes, mental boxes, so in terms of when you think about when applying for a position, definitely think about mental tick boxes. Whatever the job description says, they’re looking for those things. They want to be able to make mental ticks of those things, so if they say Node.js and Angular or Ember, and Bootstrap. The very first three things on your resume should be "experience with Angular, Node.js..." whatever the other one I said was. Because they are going to mental tick box: "OK tick, tick, tick – we should talk to this guy on the phone."

If it’s a company in the logistics space. If you worked at Amazon Fulfillment Center that can actually play into your favor. You may think, "oh, I worked in fulfillment, Amazon Fulfillment Center – ugh. That’s not professional, white collar software..." but that can actually work in your favor. You know a lot more than the average, just vanilla, traditional background software engineer coming in.

At the end of the day, as a software engineer, understanding the product and customer needs is actually very important – a lot more important than you might think.


Cool. You made the transition from hardware, from supporting hardware to moving into FinTech. What motivated that decision and then what were the major differences that you found going from world to the other?


That’s a great question. The thing that made me eventually pull the trigger on moving – I was at Logitech just under three years and 2008 the Crash hit – so Logitech like restructured everything. Half of the entire group I was in, they fired. It was like, maybe 100 people in the business unit. Half of them canned – not canned “laid off”, right? "Made redundant" in UK terms.

The 50 of us that were left, half of them went to go work on Google TV, the first target hardware version of Google TV. The other half stayed on to work on the product that we actually signed up to work on, and they put me in corporate marketing – because they’re like oh, "he can build websites so we’ll put him in corporate marketing."

Get Hired #3: Clarify your motivation.

I was like, "I don’t want to work in corporate marketing" so I was like, I need to go find something else to do. Now’s a good time to do something – the big things for me were it’s pure software. It’s “helping” the world, it’s making the world a better place. I didn’t want to do social networking or consumer apps, like entertainment-related consumer apps. I wanted to do something that falls in that “umbrella”. I’m putting it in quotes because you actually have to look under the hood at what it’s doing. At least, as an “umbrella” idea it’s making the world a “better" place, or it’s helping people. It’s providing a valuable, concrete service. So, money transfer was like, clearly – that’s providing a valuable service that people need.

FinTech & tangibly solving problems.

The thing I like to say is, when it comes to financial services and money transfer, if grandma is sick and she doesn’t get the money on time to go to the hospital, like that could be life or death. So it’s really, really, really important – if the software crashes and grandma doesn’t get her money and has to wait an extra three days, like, she could die. That’s sort of ridiculous, extreme example but that could actually happen.

Hardware vs. pure software company distinctions.

The differences between the sort of, software supporting hardware and the pure software, one thing that was really cool – obviously the cycles are really short. You can do a lot shorter cycles in pure software. Hardware, you have cycles but there’s like a physical thing that needs to be made. So, typically in a hardware company, when you get something manufactured – the software you can iterate fast but that has to be somewhat compatible, if you think about versions of your software have to be compatible with versions of the hardware. Before you get to mass production you have to go through various stages of like pre-production, pre-production qualifications, so there’s all these “sprints” or “batches” I don’t know what the right term is. You have various iterations of the hardware, the software somewhat needs to follow that. Then you have some freedom to do faster cycles.

The pure software cycle obviously you’re not constrained by that. You’re only constrained by how easy it is for us to scope, size, book, build, test, ship – right? Like how fast can we do that. In the case of like companies like Facebook that could be five times a day or ten times a day, whatever. The same thing with Google, right? That’s sort of my philosophy as well, keep that size really, really small.

So that was the big difference is the cycle size can be a lot smaller. The other interesting thing was the data driven nature of it. So hardware you can do user testing and stuff, but you can’t really run as many experiments. Once it’s been designed, you can’t really change the form factor after the fact. It’s baked, it’s plastic or metal whatever, a combination of both. With software you can run unlimited – again your experiments you want to run to change things are only a function of how much time do you have, and cost trade off of that. That was another really cool thing at Xoom, they were really good, this is one thing I picked up at Xoom. They were very good about not necessarily running user experiments, but just looking at the data and figuring out what were the right things to focus on, the right businesses to be on, versus not be on based on the data. Now everyone talks about A/B testing or multivariate testing, but at the time that wasn’ they have very experienced payments people there. That’s why they were very data-driven. But that was another big thing.

The other thing, too...big difference between hardware... I guess, this may not be true in all places, but software-wise I think there are software-focused companies – I’ve heard people say that hardware companies don’t do software well. Which maybe is the case.

Great companies default to extreme efficiency.

So when you’re at a good software company or on a good team, there’s usually a stack of tools that help you do your job. There’s like a pipeline to create, to produce code, to test it, to vet that code in terms of quality and actually does it satisfy the feature requirements, and then move that into production. So there’s this whole pipeline, and generally in software companies – and good ones – there’s a very nice sort of pipeline that you set up that’s automated. Hardware companies to some extent have that, but I would say it’s not as polished.

Software engineers, we’re all like "lazy", right? So we love to optimize that stuff, that’s another difference.


What about in terms of the actual development challenges that are faced, in each of those cases? I would imagine those are very different, and in particular FinTech has its own challenges and maybe that’s depending on exactly which portion of the platform you are working on, but I’m very curious to hear that. because I don’t think we hear from enough people who are in particular in the FinTech side of things.


Development challenges: hardware vs. software.

That’s a great question. On the hardware side, often time you're memory constrained or processor constrained or you’re dealing with small processor small memory footprint so a lot of time that’s a constraint. Or a lot of times, here’s an area where they’re similar: in the hardware world often time you have constraints related to – we have these whole bunch of devices in production that have this old version that has this thing you have to work around. It’s constraint – because the firmware is baked in with this thing and we can’t change that, or whatever.

FinTech software development challenges.

Similarly, in the FinTech world, a lot of times you’re dealing with financial – the older school financial services, APIs are very kludgy. The way payment cards work is really kind’s very, very messy. So you have the official ISO standard that says one thing. The bank you’re working with their specification which says a different thing. Then you have the reality which doesn’t match either of those things. That can be really, really, really challenging, and I’m not exaggerating in the least that’s seriously the way it is – across the board. It’s amazing how well the payment card industry works all the time – because under the hood it’s really, really messy. Payment cards, specifically.

That’s sort of a similar challenge there, you have the stuff that’s out there in the wild and you have to deal with it. The big challenge, and then another analogy is like, maybe with the hardware you’re constrained on memory. You’re not constrained at all in memory in FinTech, but you end up being challenged memory-wise, at scale. In the FinTech world, most FinTech is a volume business. When I was at Boku we were doing, at one point I can remember is, seven transactions a second on average. That’s a very high scale, so throughput is incredibly important, the memory footprint is incredibly important.

If you write a little bit of code you might not think anything of it to do N squared, but when N becomes a million (laughs) or when N becomes seven a second – that’s non-trivial. The other big thing in FinTech, somewhat in hardware and software both. Hardware is a little bit more steady state ... Well, so the big thing in FinTech is a lot of times you just can’t go down, especially if it’s a volume business.

If you go down you’re losing money, you’re hemorrhaging money every second that you’re down. That’s a big thing, and that’s true of any business in theory but there are some businesses where you have a little bit more flex time. But Financial Tech especially, every moment – especially payments, payments specifically – every second you’re down you’re losing money. Versus, if someone’s Squeezebox stopped playing, stopped working for an hour. They will be pissed off they won’t be playing music but then again you don’t have residual revenue from them anyway. So an impact, to the business standpoint, it sucks and it’s bad but you’re not losing money because of it. It’s not like people aren’t buying new Squeezeboxes at Best Buy because you’re down.

Uptime is a huge thing in terms of challenges in FinTech. The other thing – hardware moves quickly in terms of new models. So oftentimes, you start with a green slate every year, every two years or every six months in hardware.

FinTech is very much, think about like an old village, if you ever looked at maps of London from the top, it’s everything sort of grows organically out and you end up with this giant city with all these cobblestone streets. Sometimes it feels like that when you get to applications at scale. There’s going to be potentially hundreds of engineers that have touched the code, hundreds of different integration – dozens of integration endpoints, external integration endpoints with all those workarounds that I mentioned and plus all the features. Think about all the new features and then there’s going to be legacy features to support and there’s probably features that you still support, in theory, but maybe don’t work. It becomes messy in practice and there’s always something technical that you’re going to be dealing with to fix, and to re-factor things to make them a little bit better, to some extent.

That’s a big difference, versus with hardware – it’s greenfield, a lot of the time.


I did want to ask just one more thing about this particular arc.

Would you mind just talking specifically about one of the projects that you worked on, and then kind of what the day-to day of that was when you were working at those early FinTech companies? Like on Boku – that’s probably a good one.


Project workflow example on a FinTech team.

Sure. Actually, Monitise is maybe a better one, it’s a little bit easier and a little bit more straightforward to explain. So if you have a bank which I’m sure pretty much everyone in the hangout, or is listening, has. You probably have an iOS or an Android app that you can download for your bank. The project I worked on – the US has about 100 medium to large sized banks, a good many of them, I’d say in the dozens of them, use this software that I built with a team.

The selling point to banks was like, you have a Cordova-based application so it was Angular, JS, running in Cordova on iOS and Android – and I think Blackberry at one point in time. That was the selling point: "hey banks you buy this one thing and you have the same experience across both devices, with a few optimizations for each device." My role changed, so I was sort of in a more senior position – I was a lead I don’t want to say senior. I was senior, but a more lead position early on in the evolution of the project.

Phase I – Research.

Initially, in the first phase it was a lot of research. I came into the company, there was this sort of homegrown hodgepodge of four or five different libraries that were being used to achieve that. I was like "hey, single page applications have come a long way we should use something like Angular or Ember or similar, and that will improve the quality of the product and help us move faster."

The initial phase was I did a lot of research: building proof of concepts, like demonstrating here’s how it could work. Showing why should we go Angular versus Ember, stuff like that. It’s making the case for the management team: here’s why we should go with this tech stack. Research and coding to support that research and a lot of meetings, and stuff.

Phase II – "Selling" change through getting "buy in."

The phase after that, is sort of like, we’ve pulled the trigger – and a lot of that is communication, too. So a key part of that, communicating with the team. Some people like change, some people really embrace it. Other engineers you’ll find are just like "oh, I don’t know, I don’t know if we should change. We’ve invested a lot in the old way of doing things." So you get a lot of those people. You have to make sure everyone has bought in, right? That is, talking with people and showing them the benefits of why we should do it this new way and why they should learn these new technologies, etc. That involves more meetings, and meetings actually training people on here’s how you use these tools, here’s how it all fits together.

Phase III – Building.

Then you go to a phase where it’s like, "OK let’s actually build it." Some of that second phase of let’s build it, initially there is some plumbing you have to put in place. That application, the idea was different banks could pick or choose different features. So Wells Fargo might have online bill pay, checking and savings account, credit cards and mortgage. Bank XYZ might not have a mortgage product. Bank ABC might also have a loyalty and offers program – so we had to have these drop in sort of modular architecture where banks could pick and choose the things that were in. Then, think about logging into your bank. Every bank has a little bit different login, sometimes you show the site key and password, sometimes it’s a pin, sometimes it’s this sometimes it’s that. So it had to support a big matrix of features.

That initial phase of plumbing was like, "how do you do that? How do you translate this very complex business requirement into actual Angular code and Angular modules?" In a typical day, in that phase two, it was a lot of – in theory drawing things on whiteboards "here’s how it could work" – and then actually going and writing code and trying to make that work.

Refinement, Specificity, Presentation.

Then obviously the other complexity too, is like, every bank has a different brand. The application isn’t going to look the same, so it’s a completely different color, look and feel for every bank. So all those, distilling all those into how do we actually make something that’s modular that we can very quickly... We had the core engineering team, then there was this whole separate team, once they sold it to a bank that separate team would actually "color it" so to speak, would actually brand it for that bank and deliver it to them. Turn on and off all the features.

We had to figure out how do we make this easy for that team to do their job – to actually deliver it to the bank, in the right configuration with all the right look and feel.

New Features Enhancement.

Then the third phase, after that was somewhat mature, after we shipped the initial version then it’s like: "OK adding new features, adding modules." Now they want to support password-less pin on the first page, or now they want to add this coupons thing. So just adding features and figuring out how those all fit together.


It sounds monolithic, I mean, massive!


It was a very big project!

Bonus Phase – Unblocking your team.

Then as a more senior level member of the team, obviously a lot of my day, too, involved code reviews, helping others. If someone gets blocked, "hey, there’s this error and I can’t figure it out" – pulling a chair next to them and scratching my head with them and like, "oh, I think it might be this." Or, looking over their shoulder and reviewing their code. So towards phase three, I would say it was less active coding and more assisting and enabling.


Cool, thank you. Alright, how about questions, anyone here have anything?


Yeah, I’ve got one. I was wondering about how much security goes into this and like what was the approach to internet security? I’m sure in financial tech that’s a big issue, so I was curious.


Yes, a great question. Specifically, the mobile banking app I mentioned, and I don’t know if anyone here uses Angular or is familiar with Angular – is it a mix of – is it, everyone full stack?


We go through Angular. We do Rails on the back, JavaScript–Angular on the front.


FinTech software & security implemention.

OK awesome. So one thing that’s pretty common when you have like you mentioned, security is very important – is request signing. The idea is a REST API you have some client, like I’m the client. I have a secret and I sign all my requests with this secret, so that the REST API can say, "oh, this request was actually from Matthew," not just some man in the middle.

One way to do that is to have a key on the device and then you take, for example, if it’s a GET request – very similar thing in Boku actually, too, in most FinTech APIs. You do something like, in general:

  1. alphabetize all the GET parameters

  2. take the base URL, plus those alphabetized GET parameters, plus a non-C value or a timestamp, plus the secret that only the client knows in theory

  3. MD5 hash that or use some hash of that – and add that on as an extra parameter. So, "hash equals blah."

The REST API takes all that information and reverse engineers it, because it’s a shared secret so the REST API knows about that secret. So it can say, "Ah! This request definitely came from Matthew or anyone who actually had Matthew’s secret."

That prevents people from sending arbitrary requests. Another use of that is like I’m calling some financial services API – how do they know that it’s coming from my servers and not someone else’s servers? One thing you can do is white ist IP addresses, that’s pretty secure, but having that signing mechanism is a really common way that that’s implemented. Then, different banks have different flavors of that. But, in general, that’s a pretty common thing, specifically in that mobile application that was definitely used.


Thank you – other questions?


Oh sorry! I wanted to mention, I wanted to touch on Angular! One cool thing about Angular it has HTTP interceptors so you can register, for every outbound request before you send the request – do something with it, pre-process it. That was how we implemented that, was we used Angular’s HTTP interceptors so every outbound request got signed according to this algorithm.

Actually there were four different flavors of that algorithm depending upon the bank. Based on however the bank was doing it, that version of the algorithm would get tacked onto every request. Sorry! I did want to plug Angular real quick, because Angular makes that really easy.


(Laughs) I guess Angular won in the "Angular versus Ember" battle.


Yeah it seems so, for sure. By a number of users certainly Angular is the clear winner.


Cool, other questions?


Yeah I’ve got one, I’m just pretty interested in startups and I was thinking maybe I might start one somewhere way down the line from here, but I was wondering what your biggest challenge in creating Blossom was? Any major hurdles that you had to overcome that weren’t obvious upfront?


That was exactly the next line of question I was going to have! (Laughs) Before diving in, do you mind explaining just a little bit what Blossom does?


Blossom Finance as a Microfinance platform.

Sure. Blossom, I’m sure everyone’s heard the term crowdfunding, right? So Indonesia is the world’s fourth largest country in the world. It’s 250-million people, about 80% of those people don’t have bank accounts. So there’s something called "microfinance"which is basically like little mini community-run banks that serve as financial institutions in places like Indonesia.

The problem in Indonesia is there’s not enough money. There are plenty of people who are actually qualified to get an investment from a bank to start a small business that can generate income for their family. The problem is there’s a lack of money – there’s a lack of capital, in investor terminology.

What we do is we crowdsource money from places like the US and invest it into profitable microfinance in Indonesia. Our tech platform helps us do that more efficiently, collect all the data, manage all the accounts, all that type of stuff. That’s what we do in a nutshell. So, an investor in the USA can give us money and then we help them distribute that to a whole bunch of these, what are called MFIs or Microfinance Institutions, and then those guys go and invest in ten or a hundred or whatever it is businesses. Then those entrepreneurs create some business that generate profits, and those profits are shared with the Microfinance institution, technically the mini-bank and then we get a cut of those profits back and we pass those back to our investors. So essentially a marketplace for microfinance investments.


Cool, and then Morgan I believe you were asking what were some of the challenges?


Yes, so what was the biggest challenge in getting that started up and set up?


Biggest challenges for getting startups off the ground.

It’s a great question. The biggest challenge for any startup is obviously time/money. It’s really time right – it’s really money, because money can buy time. Ultimately it’s a problem of money.

We didn’t get some initial early funding so that’s a problem for any startup. Once you overcome that — I don’t know if you’ve read the Eric Ries’ The Lean Startup (book), one thing I really like that he says in that book is “most startups fail not because they didn’t have really bright engineers or the best technology. They fail because they’re doing something that no one cares about, and no one needs or no one wants.”

Product/Market Fit

Product/Market Fit is really a huge, huge challenge for any startup – as it was for us. We initially started in the US, and we realized early on that there was not a big enough market to support what we were doing. Which is why we decided to – after we almost run out of money – we decided let’s go to Indonesia and give this a shot. Can we figure a viable model in Indonesia?

Turned out we hit on something really, really great in Indonesia. We had a thesis at the time, but we had to actually go to Indonesia and figure it out. The biggest challenge for us was "hey, our money is going to run out and this is not going to work and definitely not going to be able to raise money," more money because what we’re doing in the US is not working.

We can A) pack it in and say we gave it a shot, it didn’t work or B) we can, in terms of product/market fit we can go to a different market and adapt the product to work in that market. That turned out to be a very good decision for us. So product/market fit is really, really huge and every company, not just startups but startups especially struggle with this. Once you think you’ve achieved product/market fit often times you’re not quite there and it will take several more durations before you’ve actually reached it. I would say product/market fit was the biggest.

Legal Complexity

Other challenges: legal stuff, any time you do financial tech legal stuff is complex. By complex I mean expensive – so, no matter how legally complex something is – again this goes back to money, everything goes back to money!(Laughs) If you have the money you can pay someone to figure it out, but lawyers are expensive. It’s like, how do you do everything legally and above board but in the cheapest way possible? Because you don’t want to over invest in something before you know you’ve achieved product/market fit. It’s kind of like the chicken and the egg. Hey we can’t do XYZ because we’re not sure – we have to make sure we’re doing everything legally, but to figure that out, we have to pay lawyers hundreds of thousands of dollars. If we pay lawyers hundreds of thousands of dollars and we run out of money then that may have not even been the right product to build.

Sort of the chicken and the egg problem there, but it all goes back to money because if you have unlimited capital then that’s not a problem, right? So hopefully that’s a good answer to your question.


How did you solve it?


We, kind of – I guess, you could say – how did we solve it?

Research, really. Just being scrappy and just talking to a lot of people, having coffee with a lot of people. I got on LinkedIn – when I got to Indonesia – and anyone who knew about Microfinance or Indonesian stuff, like who could speak English, we grabbed coffee.

So a lot of research to figure out what’s the regulatory environment here. How can we make this all work, in addition to product/market fit, like what is the right product here, what do people need, what are the challenges, all that stuff. It was just kind of being scrappy. I can say I may actually be one of the only people where LinkedIn has been very, very helpful for me. Because I was able to go to a country where I had no connections whatsoever. Literally zero, and actually find useful people, get in touch with useful people, and actually end up launching a product.


So why Indonesia, then, if you knew absolutely no one?


Based on some preliminary research, we had a thesis there was a strong market need there. So we had ran some insights that Microfinance was booming in Indonesia but was capital constrained. Our thesis was around taking a high tech approach to capital for microfinance using a Sharia model. Indonesian is a 90% Muslim country – so the traditional banking model doesn’t work, you can’t do something like a lending club in Indonesia. I mean you can, but it doesn’t work within the religious framework. So our thesis was around using crowdsourcing with a Sharia compliant model to solve this capital problem, in this massive market. If you are going to do a startup and you’re going to do something of volume you need a really massive market, and then you look at there’s other countries beyond that. Our thesis was like, we think we can solve this problem of capital constraint in Indonesia. Which based on everything we had read, there was a big need for that, so that’s why we chose Indonesia.

I was also inspired by, I think it was – what’s that guy on Shark Tank, O’Leary, Kevin O’Leary, is that his name? The bald guy – Mr. Wonderful on Shark Tank. Anyway he gave an interview one time I watched and he said, "if I was 22, 23, coming out of college, or whatever, graduating some program," he’s like, "I would not try to focus on developed markets like the US, I would get on a plane and I would go to Brazil or I would go to China, that’s where the opportunities are, the big opportunities are in Asia, Southeast Asia specifically and Brazil." He’s like, "I would just buy a one-way ticket, get on a plane, go there and figure it out." I thought, that’s what I’m going to do!

But it turned out, I couldn’t buy a one-way ticket because you actually need a round trip to get a visa on arrival. So I had to buy a round-trip ticket. But practically the next best thing – it was practically a one way ticket, right!


If I could kind of tie things back to the development side. Up until this point you had primarily been a developer, an engineer or something very close to the software stack.

During those iterations you were working within someone else’s vision, product timeline, product road map, things like that.

How did you find that your understanding, or at least your implementation of the development process changed when you went from that sort of working in someone else’s company, to suddenly you’re building your own startup? And, you’re feeling the pressure of all those extra constraints of "Oh my god we’re running out of money! We have to get this thing built," and all of that?


Evolving from Employee to Founder lessons.

For one thing, I realized very quickly now I have a very low tolerance for engineers who don’t ship. I think you get, even in small to medium-sized company, it’s amazing how engineers can sort of exist but not really ship – aggressively.

Great teams ship code, quickly!

I realized quite early on, I was like, "people aren’t shipping code, they can’t stick around." One resource I think is interesting and worth reading is published by a company called Knote, it's called Ship While You Sleep. Their thesis is, there’s tons of engineers all around the world who are very good and you can hire relatively cheaply. Don’t waste time interviewing them, just hire them immediately and tell them you’ll give them a 20 hour paid trial and see if they can actually produce, software.

If people can actually produce software and it is actually useful then it’s like OK, let’s keep paying them to do that versus you spend all this time interviewing these “rock star” engineers who work at these unicorn companies and it turns out they can’t ship code. My tolerance for not shipping code, certainly – we have to get stuff done.

I guess, I have enough startup experience to sort of understand the trade-off of we could optimize it and do this but we don’t know if this is actually going to be a long-term product. I was comfortable with this idea of we may need to put in ten hacks to make it actually work – something that we can get up to test it.

I guess I was already sort of comfortable with that. An extreme example of this is like – I forget where the story comes from. But some company had a feature that they advertised on their website. They didn’t know if anyone actually needed it, but they thought people maybe would need it. So they put it up and it was on the product marketing page and they never actually built it – until like a year later when a customer was like, "hey, I can’t figure out how to use this." And they’re (the company) was like "hold on, hold on!" So, like a month later they built and shipped the feature and told the customer "OK, it’s ready for you to use!"

That’s kind of shady! (Laughs) I wouldn’t go that far, but that’s an extreme example. I wouldn’t recommend doing that. But in terms of being responsible for we got to get stuff out the door. Also taking a low-tech approach, that’s a big thing, I had to get more comfortable with taking a low tech approach – or, no-tech approach.

In the spirit of The Lean Startup, sometimes you can do things with low or no tech first to validate that it’s even like a user need or user feature. I guess even when I was doing product management, it was a more medium to large-sized company. Boku at that time was 80 people so that’s not super big, but it’s certainly not working in a garage, right?

Even then it was going out on my own, headed to lean in even more, to just do more really cheap, low-tech or no-tech experiments, I would say.


Cool, thank you. I got a question from the audience here:

"What are hidden issues that professional software dev’s you’ve mentored over the years that come up and surprise you? What are the resolving tips you’ve found to help them evolve beyond that?"


When he says problems, he or she says "problems", do they mean like, problems with the developer – like issues they have?


Yeah, I believe so.


Software developer issues to watch for.

OK. I think this is true, some people just write really ugly code. I don’t mean ugly, like it’s convoluted – but some people just write messy code. Like, they’ll have arguments in a function that aren't used in a signature. Or they’ll declare variables that aren’t used anywhere. Or they’ll leave off semicolons and JavaScript is forgiving enough to do semicolon insertion. Or they’ll sometimes use camelcase, sometimes use underscore case. I call that messy code.

Writing "messy" code.

A tool that’s helped overcome that, and also the *asterisk here is like, people are defensive of their code. So if you go in and say "hey dude, you need to make all things camelcase." They’re like "oh well, in my old company we use underscore case," or whatever. So using tools like JSHint, for example or a similar code linting tool, or code formatting tool, it solves two problems.

Number one, it creates a specification that you can point to and say "this is how we do it at this company. We can change it – but this is how we do it, today. If we want to modify we can, but it’s checked into the version control system."

Yeah, great tip – JSHint is awesome, I totally agree! (In response to a viewer's DM message to Matthew in Google Hangouts chat.)

It formalizes the specification, and number two, it actually checks and enforces the standards.

Another great tool that I would say works cotangent with JSHint is JSBeautify, so JSBeautify does things like do you put a space between the function and the opening parenthesis of your function declarations.

Do you put spaces after commas? Like indentation, all that type of stuff. JSBeautify will enforce those standards – but also you can use it to just format the code for you. If you have engineers that maybe they’re good engineers, they’re good developers, but they just write really ugly-looking code – that’s fine. You just put it in your build system, so the build system enforces it. And they can just run a single command and it fixes it for you – so you don’t have to waste time on that. So that’s a good thing.

Another thing is: sometimes, people have great potential but they don’t always... Like sometimes they’re very intelligent and they have great potential but they don’t always think in the most – they don’t always write code that’s in the most straightforward manner.

Over-complicating code solutions.

It’s hard to put my finger on what I mean by this. I can think of a concrete example that occurred not too long ago where, there was this series of methods that were operating on an object that needed to assign new properties. Like a middleware stack where if you’ve used Express, or something like that. It was this middleware stack – not Express but a similar framework. It’s adding stuff to this object, building up this object and at the end, it's doing something with it.

They started with an object. They added something to it. Then they created a copy of the object, and then they were using like a promise library and the promise library they were calling "map" – which was reaching a new object. It bounced all around. I was like, "dude, you have the original object, just use that."

To me that’s very obvious but sometimes some people they just get into the nitty-gritty of the code, and they have a little bit of a convoluted thought process. Having code review is a great way to do that.

The resolution: WTF metrics!

One great metric I love in software is the WTFs per minute metric. In general, code should produce the least number of WTFs per minute.

So one time – this is another good example. I had a somewhat junior engineer, he read someplace that instead of doing – oh, what was it? Oh – "reverse for-loops run faster than decrementing an integer, one is faster in JavaScript than incrementing integer," so he wrote a bunch of code with all his for-loops like decrementing! There was other consequences of that, that were really kludgy!

There was like a WTF every few seconds! I was like no, "that’s OK, that’s not going to be your constraint in this case. You’re not going to be processor bound because your for-loops are incrementing and decrementing."

Because this is a WTF, the cost to the company, of having another engineer try to re-factor this code or work with this code or understand it – their time of reading your code and saying "WTF!" and figuring out what’s going on far outweighs the cost of additional...Not that it actually would, but in theory, if it was adding more processing cycles or more processor time or memory, in this case the WTFs costs vastly outweigh the detrimental for-loops versus incremental for-loops costs. (Laughs)


Nice. (Laughs) Thank you. Is there maybe one more question that we could address here?


Yeah, I had a question. Specifically, when you started up Blossom – what was the hiring process like, looking for talent?

Is there a litmus test of what you looked for, was there a process? I know you mentioned that you have low tolerance for people who don’t ship – what was your process like in finding talent?


That’s a great question. Unfortunately, initially I paid too much attention to what other “experts” said about early stage hiring.

Early-stage hiring adjustments.

They were like it should be more of a cultural fit and blah, blah, blah and so I found someone who was more interested in what we were doing and the values of the company, producing the type of product we were producing. The early stage hires weren’t actually able to ship that great, and then I was turned onto this ship while you sleep methodology. So the methodology for them is, just post a job someplace, figure out what your capacity is.

Hire the first few people who apply – don’t even look at their resume just hire them and give them a very, very tiny task. Here’s a page change the button text to sit from this to this. Or, right now the button goes to this page – make it go to that page. Really, really tiny miniscule tasks, and then have your stack set up so we already had a build system, and a continuous integration system, all that stuff.

Code quality tools like JSHint and JSBeautify. So, can they follow instructions, actually write code that does what you want it to do, and get that to move through that development pipeline successfully, within a reasonable amount of time. So I did a paid trial of 20 hours, and if they could do that, I would keep them on. If they couldn’t do that the other term for this methodology is "hire by firing."

The idea is you make the net really wide, the funnel is really wide, easy to hire people and then you just fire a lot of them and it’s nothing against them, they couldn’t achieve the results so you’re just not going to keep them around.

But some of those people will. The thesis is: my time and the time of the team to interview them is way more expensive than paying them, let’s say they do nothing for 20 hours, twiddle their thumbs and play Xbox – for 20 hours. OK, that’s still less money than if I had brought them in for two days of onsite interviewing and coding test and phone screen and reading their resume and filtering through resumes. I’ve saved a ton of money by actually just paying them money than spending our money by interviewing. That’s the process we use now and fortunately that’s worked very, very well for us. If it’s more of a core team hire – (prior example) that’s for general engineers.

Core team hiring practices.

If it’s more of a core team hire, the process is generally, I like to just talk to people for five minutes. Asking something very generic like, "hey tell me about yourself?" Just so they’re comfortable, because a lot of people get nervous, but the only thing I’m looking for there is: can they speak English, can I understand them, and do I not hate them?

A big no-no: skills exaggeration!

Then, I just do a very simple coding exercise. You’d be surprised at the number of people who have a resume that looks OK, on paper, and they can’t write a for-loop! I literally had one, a week and a half ago. I had a guy who looks good on paper – and we did a live coding session together. It was a very, very simple coding exercise. And he’s like, "OK I just need to look up the syntax." I’m like, "for what?" He’s like, "for a for-loop."

I’m like, you’re applying for a JavaScript position and you don’t know how to write a for-loop in JavaScript, and you have JavaScript on your resume – are you serious?!

Hiring candidate coding challenge process.

Those kind of things I’m filtering for. (Laughs) and then beyond that, if it’s like an office here in San Francisco, generally, following a phone screen, bring them in – give them a coding test. The first is like: can you write code when you have someone looking over your shoulder, and it’s like, "OK you have to write it now – using only the things in your mind."

Then following that, give them something they can take away. Spend as much time or as little time as they want, with an eye to looking for do they complete the problem, do they solve it completely, follow all the instructions and produce nice clean code? That’s the coding test. Take that away and do it on your own time, spend an hour, half an hour doing that and make it really nice.

Whiteboarding session philosophy.

Then bring them in-person for whiteboarding session. My impression of the whiteboarding coding test, it shouldn’t be a "gotcha question" like you know or you don't. It should be something that’s a little bit open-ended, so it’s more problem-solving.

I’m going to tip my hat here, but I’m going to ask people: implement a web application that has these three requirements. Number one: when I join the web page it shows the list of IP addresses of everyone else who is currently viewing this page, including mine. Requirement number two: when someone new opens the web page their IP address should dynamically appear in the list – without a page refresh. Requirement number three: you can guess, when someone leaves, likewise their IP address should be removed. Three simple requirements, sounds very simple but it’s actually more complex than you might think.

I like it because it’s open-ended, it covers full stack. I tell them you can use any technology – you’re the CTO – you decide, but here’s everything. Then at the end I say, "now we’re successful and we have a million users currently viewing. How would this change your design?" If we get to that, if we get that time. So that’s what I like to ask in-person. I think those type of questions are better than "implement breadth first search, red markers only, green markers are not allowed."


Cool, well thank you so much.


My pleasure.


Thank you. I wanted to be conscious of your time and we of course have managed to pack a whole lot in here but I think we’re out of hours. Matthew, thank you so much for talking with us, it feels like we have just gotten started.

If anyone is interesting in continuing the conversation how could they reach out to you on social media or anything like that?


On Twitter I’m @OhByTheWay, and then we can follow up from there.


Alright, well thank you to everyone who’s participating, thank you again Matthew for taking part. For everyone else this is the Viking Codecast signing off for this week and we’ll see you guys next week. Take care.


Thanks Erik, thanks everyone – bye, bye. Cheers!

Contacting Matthew


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.