The moment I realized I needed a CS Degree

A little more than two years ago, I was in London, UK and had just finished a 12-week hacker school. Rather than looking for a dev job during the course’s demo/graduation day (as is the norm at a hacker school), I was getting ready to move across the Atlantic to Vancouver, Canada to begin my Bachelor of Computer Science degree at the University of British Columbia. Here’s the story of when I realized a hacker school really wasn’t enough to get me where I wanted to go.

The story

It must have been something like Week 8 of the hacker school when I started thinking about applying for jobs and what my options would be at the end of it. I remember checking out a bunch of companies that used Rails in London and looking up sample interview questions on the careers section of their websites and Glassdoor. There were quite a few smaller independent firms that seemed open to hiring a hacker school grad, and their questions didn’t seem so bad.

At that point, I had just started to get comfortable with Sinatra and Rails and had probably built my first couple of web apps – a classifieds website for university students and a lowest unique auction site. And, as you do when you’ve just started to get the hang of a new field, I was thinking that I was getting pretty good – they call that the Dunning-Kruger Effect. I remember thinking that if things had worked out, I could have built a Facebook, I mean how hard could it be (building a scalable, secure and efficient system is hard as it turns out, and that’s ignoring the user acquisition and growth side of things).

But being the sensible person I am – I’m trying not to cringe as I write this post – I figured I should probably work there first. You know, get an idea of the finer points. Besides, I’d heard great things about the company from people who worked there. I’d even visited the office once before (the one at Page Mill Road I think) and it was pretty cool (free drinks, open plan office, Herman Miller chairs). So I checked out the careers section of their website and started trying to solve a sample engineering problem – back then Facebook had engineering challenges that you could solve to get contacted by a recruiter.

The sample challenge was to write a solution to the Tower of Hanoi.

Diagram of the Tower of Hanoi

Tower of Hanoi

As per Wikipedia, the objective of the puzzle is to move the entire stack of disks from one rod to another while obeying these rules

  1. Only one disk can be moved at a time.
  2. Each move consists of taking the upper disk from one of the stacks and placing it on top of another stack i.e. a disk can only be moved if it is the uppermost disk on a stack.
  3. No disk may be placed on top of a smaller disk.

If I remember correctly, the aim of the puzzle was to generate a sequence of moves which solved the problem.

Come again?

Yep, I had no idea where to even begin – and this was the sample challenge. The one that was meant to give you an idea of how to handle input and output, rather than being representative of the difficulty of challenges since the real ones are always a lot harder than the illustrative examples.

I remember doing some research on the Tower of Hanoi and discovering that it had to do with something called recursion – I only had a vague idea of what that was at the time. Most importantly though, I found out that this was a well-known problem taught in pretty much all CS degrees as part of their introduction to algorithms and data structures.

The more I read about the topic, the more I realized I didn’t know. My brief moment of (over)confidence in my abilities quickly evaporated and I figured out that knowing how to build a web application in something like Rails is not the same as being a Software Engineer – that building an MVP of a social network site is not the same as engineering one. The former can be done by following Michael Hartl’s famous Rails tutorial, while the latter requires knowledge of computer science and algorithms, hardware, growth, marketing, data science, etc, if the app is to stand any chance of success.

Doing the hacker school was great for figuring out that coding for 8, 9, 10, 11, 12 hours a day was something I really enjoyed, but most importantly, for learning how much more I still had to learn if I wanted to tackle really complex problems with code.

And so I looked around for CS degrees that took students with a previous degree. There were a couple of Master’s programs in the UK which seemed ok but a bit too short; most of them were only one year in duration and I didn’t think that was enough time to get a really thorough understanding of fundamental CS theories, plus they didn’t seem to have the top-tier tech companies recruiting from there.

The top CS schools in the US on the other hand, generally didn’t offer second degree programs. Some, like Stanford, didn’t admit students for second Bachelor’s degrees at all, while others like Waterloo required students to start from scratch and do a 4 year program.

And then I found out about the Bachelor of Computer Science (BCS) program at the University of British Columbia in Vancouver. It checked all the right boxes. It was shorter than a regular CS degree but not that short (advertised as 2 years, but 2.5-3 years in practice) and had good links to American tech companies (Facebook, Google, Amazon and Microsoft recruited its students) and had a decent reputation (something like 30 to 60 in World Rankings if you buy that sort of thing). And before I knew it, I was on a plane to Vancouver, Canada.

And that’s it. That’s how I ended up studying for a CS degree and how I kind of went full-circle this summer interning at Facebook – something I am certain I could not have done with just my experience at a hacker school, not by a long shot. It’s also been a while since I solved the Tower of Hanoi.

Here’s the code I wrote for it during my intro to algorithms class in my first year of my CS program – it’s probably a little rough around the edges but I remember thinking at the time I wrote it and solved the problem, wow, I’m really getting somewhere.

 

#include <iostream>
#include <string>

using namespace std;

void moveDisks(int, string, string, string);

int main(int argc, char* argv[])
{
  if( argc != 2 ) {
    cerr << "Usage: " << argv[0] << " n" << endl;
    return -1;
  }

  int n = atoi(argv[1]);
  moveDisks(n, "A", "B", "C");
  return 0;
}

void moveDisks(int n, string from, string transition, string to)
{
  if(n == 1)
    cout << "Move disk from peg " + from + " to peg " + to << endl;
  else {
    moveDisks(n-1, from, to, transition);
    cout << "Move disk from peg " + from + " to peg " + to << endl;
    moveDisks(n-1, transition, from, to);
  }
}

The Best Laid Plans Gang Aft Agley (often go astray)

I started the year with best intentions for this blog and then let it slide completely – my bad. When I left you last, it was the new year and I had a couple of big goals – the most important of which was landing an internship for the summer at a top-tier company.

And wow, that was an adventure to say the least.

Applying for a summer internship

Being based outside of the USA but interested in internships there made the application process hard. It wasn’t always easy to figure out who would sponsor a J1 visa for the internship and who wouldn’t (apart from the really big companies – they all do) and so there was a lot of wasted time with applications.

Even before that though, and the reason for why I took a break from writing this blog, is that I had an offer fall through after putting all my eggs in one basket so to speak. At the end of December last year, I found a really exciting top-incubator-backed startup that I was interested in and so I pulled out all the stops to get an internship there. When they asked for an answer to a screening coding problem, I gave them answers in three different programming languages. So yeah, I really went all in – even working on the take-home project on a sunny beach during winter break and fully-testing everything in a new language and framework which I knew fit the task, but which I hadn’t previously used.

Don’t count your chickens

And so… I was super stoked to hear that I received an offer from them in early January and was pleased that my internship search had finished. But on the same day I received a congratulatory fruit basket, the company withdrew the offer because they didn’t want to sponsor my J1 intern visa. And that sucked. Mostly because I heard back via email rather than a phone call, also because I was eating a chocolate covered strawberry (from the aforementioned fruit basket) when I got the message. And above all, because I’d been given lots of reassurance throughout the interview process that getting a visa for the internship wouldn’t be a problem.

But hey, I get it. It’s a startup and things change. You’ve got to go with the flow. And so the real search began.

Starting the internship search again

At this stage, I had a couple of interviews with top-tier companies lined up which I totally bombed because I’d spent so much time focusing on getting the job at the startup. Not great for morale by any means. Desperate times call for desperate measures and so I stopped going to a lot of my classes so I could focus entirely on interview prep (more on that in another post) and applications. I knew I had a really good GPA and could afford to let classes slide a bit.

I sent out a bunch of applications to companies I was interested in. Got replies from lots of them saying they weren’t hiring students from Canada just yet, and also a few interview invitations and a couple of rejections. It was really interesting to see companies taking very different approaches to resume screening – a few of them were really open to non-American schools that weren’t Waterloo (a top-tier CS school that is based in Ontario, Canada); UBC is a good school, maybe like 30 or 40 in the world (whatever that means) but not yet a great one. Equally, there were a few well-known companies who used keyword scanning and had automated rejections sent out – there is no way anyone can screen a resume at 11pm in an hour! The same thing happened to all of my classmates, some more qualified than me I’m sure, and that’s just lame.

And so I kept plugging away. I got pretty far with a well-known consumer review company but since it was late in the application process, they ended up adding extra rounds of interviews to the loop (without telling me!) and it ended up being a question of headcount – I think. It felt like they started screening people out not based on whether they passed the interviews or not, but on who was perceived as the “best” of the people remaining. My resume is interesting, I’ve been to a top-tier school, Cambridge, but not in CS and it’s hard for a UBC CS student to go head-to-head on paper with one from a CS school like Carnegie Mellon. And that kind of sucked because it felt like even being objectively good enough to be an intern at the company wasn’t sufficient, you had to be better than the other candidates (or at least perceived that way). But their loss perhaps, in any event my interest got a little killed by the acqui-hire who interviewed me in the penultimate round who really didn’t sound interested in working for the tech company at all! Not exactly a good sign.

But just when things started to look a little bleak, I received three offers in the matter of a week and a bit. Yep. I had offers from a pre-IPO Canadian company, a real estate tech company, and…Facebook.

The big two year bet

It’s funny. I set out on this Bachelor of Computer Science program at UBC two years ago with the sole aim of being able to get a job at Facebook, an internship being a great route into this, and I almost didn’t even apply there. I wasn’t sure if a big company would be a good fit since I’d really enjoyed working at Axiom Zen for my first internship and wasn’t a huge fan of the bureaucracy of the big company I’d worked at before going into tech.

Facebook was the last internship offer I received, and it was actually the first offer I got with the Canadian company that motivated me(?) or maybe gave me the confidence, to just go for it. I mean, what better way to see what a company is like than do an internship there, and well, it’s Facebook. And if you fail, so what, you have options. Nothing to fear here. Move along.

The resolution

I’ll save the application details for another post perhaps, but once I received the Facebook internship offer, I accepted it pretty much immediately. Truth be told, I was leaning towards the real estate tech company until the very end because of the small-team vibe it offered and I could see real value in their product –  but when you’ve got the chance to see what software engineering is like at a tech giant, one whose products you use day-in-day-out, and which you set out to work for two years ago and is the reason you realized you needed a CS degree in the first place (the Tower of Hanoi question I reference in this post was one I tried and failed to solve at the end of Makers Academy and was a sample interview question on Facebook’s career page), you’ve got to take it.

What now? Well, I have a bunch of unpublished posts that I wrote over the last few months which I’d like to clean up and publish. A couple on how the rest of the academic term panned out, why a CS degree was necessary to getting an internship at Facebook (a bootcamp is DEFINITELY not enough, don’t believe what they tell you), and some things I’ve learned over the last 8 months or so about how to get an internship and then make the most of it.

I’d better get moving. My last term (at least for fulfilling my program requirements) starts at UBC in a few days.

 

Coding in 2015

Happy New Year!

I’ve spent the last few weeks recharging before heading back to school.

It’s about that time of year when people are drawing up their new year’s resolutions (or was I suppose to have done that already?). While 2014 was a great year for helping me get the core algorithms and data structure under my fingers, as well as pick up more than a few new languages and frameworks, there’s always more to learn.

Rather than come up with resolutions – which generally focus on bad habits to break – here are some things I hope to achieve with code in 2015:

  • work through an iOS tutorial and build a mobile app that is geographically contextual
  • build a long-term, fully tested side project in Node (since building things at hackathons is a completely different skill)
  • get an intermediate proficiency (comfortable with syntax, interview capable) in C or C++
  •  teach a CS class – I’m TAing a software engineering class and teaching a Java crash course this term so this one should be sorted pretty quick!
  •  land a top-tier internship at a company where I can work to build something meaningful
  • solve more programming competition style questions (I’m doing a practical algorithms class this term)
  • and as graduation starts to inch closer and closer, get a job offer at a company that I know I want to work at

Ambitious? Sure, but why not! Having these goals are going to help me shape how I approach the year and figure out what to prioritize. This list definitely isn’t set in stone. If anything, I have a feeling I’ll be adding more to it fairly soon! At the end of the year, I’ll look over what I’ve done to achieve these goals and what did/didn’t work.

My Internship at Axiom Zen and Beyond

Axiom Zen

Time flies when you’re having fun.

A couple of weeks ago, I finished my last day as a software engineer intern at Axiom Zen – I’m heading back to school for the new year.

As far as internships go, I don’t think my time at Axiom Zen could have gone any better. During my internship, I got to:

  • make a real contribution to Timeline – working on and owning features that will be used by many thousands (if not millions) of users
  • develop my front-end skills and pick up Angular.js
  • implement and deploy a strategy for making our single page web application crawlable by search engines
  • learn some new tech and put it to use from day one, developing account and security related features for our Go-based API
  • participate in hackathons at Waterloo (Hack the North) and Vegas (Money 20/20)  – getting time off and help with expenses!
  • improve my ping-pong skills
  • work with lots of interesting, fun and talented people

So yeah, it’s been a pretty good few months! The only thing I regret is not being able to see Timeline through to launch! I’m definitely looking forward to seeing it released to the general public in the new year (it’s currently in beta).

One of the things I’ve learned while working at Axiom Zen is how much I enjoy working in close-knit environments. Working in a startup – or even a tightly coordinated team in a larger organization – leaves you nowhere to hide, you sink or swim on your merits and ability (as opposed to arbitrary things such as how long you’ve been with the company). And that’s great because it means you get lots of responsibility and a chance to grow into the “reach” part of your role. Perfect for someone who wants to get to the next level of their craft.

Beyond…

Looking ahead to the new year, I’ve still got another two terms of school split up by a summer internship before I graduate. And that means… applying for jobs again!

As you can tell, I definitely enjoyed my time at Axiom Zen, but I’m also excited for the opportunities next summer presents. Whether that’s working in a completely different industry, at a startup, or even for one of the “Big 4”, here’s what I’m hoping to get out of my next internship:

I’d like to

  •  learn more of the stuff you can’t read about or learn in the classroom, particularly around code and system design (sure there are design patterns but knowing when to use them comes with experience – I think)
  • get experience working on scaling infrastructure and/or security
  • get a chance to work with large data sets and distributed computing
  • work in an industry that resonates with me and which has real social value (e.g. education)
  • work with fun people who are smarter than me and for whom work is a lot more than the 9 to 5
  • have real responsibility

Is that a bit ambitious? Maybe. But why not? If you told me a year and a half ago – at the beginning of my coding journey – that I would be winning hackathons, engineering software in languages I’d never heard of, and meeting makers from around the world, well, I probably wouldn’t have believed you. And yet, here I am.

If there’s one thing I’ve learned about tech and coding this past year, it’s that anything is possible. And very much like a good book, I can’t wait to see what happens next.

Just another Saturday – Office Hackathon at Axiom Zen

Internal hackathon this weekend at Axiom Zen. The theme is office hacks and we’re building:

  1. a ping-pong score and stats tracker (inspired by Si digital) using iBeacons for player identification and capacitive touch for scoring
  2. bathroom status indicator
  3. GitHub pull request tracker – determines stats for how many pull requests for a given repo were merged without review/comment

Today I worked a little bit on the ping-pong scorer, looking at the basics of the Spark – a micro-controller that works and is flashed/re-programmed over WiFi. Very cool (even for someone who doesn’t know much about hardware).

In the afternoon, I moved over to look at the GitHub pull request tracker and worked on scaffolding a basic Node.js and Express app using Mongoose and MongoDB.

Oh, and most importantly, I got to play the new Super Smash Bros. on the office Wii U. A good Saturday then.

I went to Vegas and lost (I think)

To keep up with the hackathon-ing theme, I spent the weekend before last at another hackathon – Money 20/20 – but this one was  a little different since it was open to professionals and students. Oh, and it was in Las Vegas! Talk about a great location! Money 20/20 is the biggest tech finance conference in the world(?), bringing in delegates and speakers to talk about the latest trends in the industry from Bitcoin to Apple Pay. This year they ran a hackathon the weekend before the conference and booked a fantastic space for hackers to attend at minimal cost – $10 – at the Aria hotel. Being a finance based hackathon, and in Vegas on top of that, meant that there were some crazy cash prizes up for grabs. USD 20k prizes for the top 5 teams, 5k prizes for another 5 teams after that and sponsor API prizes as well e.g. 15 Bitcoin!

The company I’m interning for, Axiom Zen, sent out an email a few weeks before the hackathon to ask if anyone was interested in attending and pretty quickly, we had a group of 10 hackers representing – one team of 5 (the max size) developing a time tracking and invoicing app for contractors (Hour Flow), a team of three developing an all-in rapid trading Bitcoin mobile app (BitBuyBit) , and a team of two (which I was in) developing an API for game developers to integrate Bitcoin powered competitions (Propane).

Axiom Zen took care of booking our flight tickets and accommodation for the night before the hackathon, and so all we had to do was plan and come up with ideas that used the sponsor APIs (a rule of the hackathon). I’d like to think the ideas above sound pretty interesting, and it definitely took some coming up with them – for the team I was in at least. My partner is one of the front-end engineers I work a lot with at Axiom Zen, which worked out well since my skills have (until recently) been focused on the back-end and with only two people and a 24 hour hackathon, there isn’t too much time to pick up new technologies!

Neither of us were super familiar with Bitcoin – which two of the sponsor APIs were based on – and the other sponsor APIs ,which were payment based, didn’t particularly inspire us since they seemed to emphasize design rather than any novel tech. But hey, Bitcoin is the topic of the moment so after at trip to a Bitcoin ATM in downtown Vancouver (Bitcoin is surprisingly hard to buy), we were good to go with our Bitcoin powered API for game competitions idea.

 

First Impressions and Tech

We turned up the night before the hackathon and spent it off the strip at a huge house that one of the founders at Axiom Zen found for us, but since it was Friday and Halloween, getting a cab back to the Strip was a little harder than we though – hour and a half wait, anyone? – and so we spent the night in and got some pizza.

And this was just the airport...

And this was just the airport…

The morning of the hackathon, we all headed off to the Aria hotel and well, if you’ve never been to Vegas, it is some place. Everything is done on an excessive scale. Paris has the Eiffel Tower, well so does Vegas. Egypt has a pyramid, well so does Vegas. You get the idea. The hackathon was held in one of the conference rooms in the Aria and it was pretty epic. It was the best organized and well catered event that I’ve ever been to. Meals were buffet style and there was a range of sodas that was restocked throughout the day and night.

Eiffel Tower in Vegas

Who needs to travel to see the sights when you can go to Vegas

My team ended up building our app in Rails for the backend and Angular running on Node for the front-end. We had different backends since that let us keep things pretty self-contained which enabled us to work independently of each other. I used Rails for the same reason I’ve always done, it’s fast to prototype things and it’s the backend language I know best. Would another tool like Node have been more suitable – yes, and I’ve made a pact that I’m using Node for the next hackathon I go to (as I write this, I’ve now picked up enough Node skills to get by with at a hackathon). Saying that, after using Rails for the last couple of hackathons I’ve been to, building up the API for our product wasn’t too challenging. The hardest part was having the sponsor API we were using go down in the last few hours before submission and making changes to the database schema while sleep deprived.

Never mind, it was all over pretty quickly. Work had been really busy in the week leading up to the hackathon and so this was definitely the hackathon I was most tired at – I was sleep drunk by 1am. I’m still not sure if I’m glad that the clocks went back with the end of daylight saving – on one hand we got an extra hour of hacking, and on the other, well, we got another hour of hacking. It probably worked out for the best since the sponsor’s API went down towards the end and we were getting 500 errors up until the last 30 seconds before hacking finished – couldn’t figure out if it was the sponsor’s API or us for a long time. Anyway, onto the judging.

 

Judging

Judging happened in two phases. In the first phase, teams pitched to a rep – normally a CEO/CTO or some other senior officer – of the API sponsor. Two to three teams were then selected from the 9 sponsors to move onto the next round where they would have 2 minutes to pitch their product on stage to a panel of judges composed of the judges in the first phase.

Conference room with people getting ready for judging

Getting ready for the judging

Two of the teams from Axiom Zen team made it through to the next round – the team working on the time management/invoicing app and also the team I was on. The team building the quick buy/sell Bitcoin were really unlucky not to have made it through. The fact that they were literally the last team out of 100+ teams to pitch in the first round made it hard to make an impression when all the judges wanted to do was move onto the next phase (we were behind schedule as always seems to happen at hackathons) and also, their idea was stunningly and beautiful simple – which I think judges may have held against them. If that didn’t quite make sense, let me put it this way – although it’s not quite the same (since the Bitcoin buying/selling app was much more complex and valuable), an app like Yo would never win a hackathon and yet, everyone in the tech industry knows it!

The team that made the time management app were one of the first few finalists up on stage to pitch and they were great. It was an amazing pitch. It helped a lot that one of them was the guy who I won Hack the North with a month or two ago – he pitched then too! They definitely benefited from having finished working on their app early during the hackathon – an hour or two before the end – and were able to practice their pitch beforehand. In contrast, I ended up pitching our app on stage while trying to figure out what to say just in the moments leading up to it – and… well, I ended up fumbling on stage. It was pretty painful.

I had the first few sentences of my pitch memorized but once I deviated from those, well, I just got lost. Think long awkward pauses and the camera guy hissing at me. I guess when you memorize something, you don’t really have a train of thought and that makes it really hard to adapt to changes or a missed line/word.

 

The aftermath

It took me more than a week to finish this post because I was pretty disappointed at costing my team a prize – we didn’t place and I feel pretty confident in saying that our hack was better than some which did. But I guess that’s life. You live and learn. It was pretty cool though that the other finalist team from Axiom Zen picked up a 20k prize!

After lots of thinking this past week, the three points I’m taking away from this hackathon are:

1) Fatigue is debilitating and it can be hard for you to realize that in the moment

2) Don’t try to memorize a speech since you’re at risk of not following your own train of thought and you’ll be unable to adapt with even the slightest change in environment/presentation

3) When it comes to competitions and maybe investments, a good pitch is better than a good app. You need to communicate what you’ve done or even what you will do (some hackathon can be bits of cardboard stuck together but if you can sell that…)

Above all, is to keep on trying. What is it they say about falling down 8 times and getting up 9.

I spent a little while after the hackathon recovering and feeling sorry for myself (and for my partner too for messing things up!) but by Monday night, I figured the best way to deal with it was to get back on the horse again , and so I started learning Node. And a few days later, registered to participate at Startup Weekend Vancouver – a weekend where the idea is to create an MVP and startup in just a few days. That’s this weekend and I figure it’ll give me a chance to apply what I’ve learned about Node and maybe about delivering a good pitch as well.

So yeah, keeping busy and moving forward is probably my way of dealing with my slip up at Money 20/20. At the end of the day, my team did well to make it to the finals, and it was definitely good experience getting the chance to pitch in front of lots of people – better to lose $20k than $200k, or maybe even $2m(?). You never know where this crazy tech stuff will lead. And just like Vegas, I think that’s what keeps it exciting.

 

 

Three things I learned from DubHacks

A week ago, I participated in DubHacks, a student hackathon at the University of Washington, building a live polling app on my own. Just after the event, I was feeling pretty positive about the experience but it was probably only over the next few days, once I’d showed the app to a couple of people and paid my sleep debt, that I realized there were a couple more concrete things I’d learned from participating in the event and which are important enough to warrant a blog post:


1) I’m still not a designer – don’t use more than two fonts on a page

After showing the app to a couple of people at work, the designers pointed out quite clearly that I’d made the very obvious (to them at least) mistake of using more than two fonts. That’s a generally a design/visual faux pas, multiple fonts can work depending on the circumstances, but a good rule of thumb which I didn’t know before is to keep it to two fonts and use size and weights to add hierarchy


2) Over-optimization is just plain silly – trust the tech

In my last blog post, I said that I wanted to get some feedback from other engineers at Axiom Zen where I’m interning to find out how better to structure my database in the future. After talking to them, I realized very quickly that I most definitely over-optimized – trying to bend over backwards to structure my tables in a way which would help solve efficiency/optimization problems that didn’t exist. I made the mistake of not trusting the technology to do what it was good at – in this case, PostgreSQL, which is great at doing joins and lookups efficiently even when records go up into the thousands (or ten thousands?).


3) No one cares how you did it, just that you did

This is probably a good reminder more than anything. I went to the hackathon liking the romance of doing something completely on my own but as it turns out, no one really cares how you did it, just that you did. And by that, I mean all that users care about is what you put in their hands. They don’t care about your drama, that you lived in a jungle for a year to accomplish it or any of that jazz. Make it good and they’ll be happy.

For the most part, and definitely never in time pressure situations, going it alone is just stupid. If you’re doing it just because that’s fun and fine. If you’re trying to build a product that will have real value, go get a team.

 

 

Another weekend, another hackathon – DubHacks 2014

Coding has well and truly become a part of my life! I spend my weekdays coding at Axiom Zen as an intern and my weekends either reading up on new tech/languages or heading out to hackathons. How much has changed in a year. I think I used to watch Netflix on the weekends…

It’s Sunday morning and I’ve just gotten back from another student hackathon, DubHacks, which was hosted over 24 hours at the University of Washington in Seattle. It was their first time hosting the event and while there were some growing pains (having dinner at the same time the hacking starts is never a good idea), it was great to see how the movement for student hackers is progressing.

The event was a lot less diverse than Hack the North a month or so ago since DubHacks was a lot smaller, maybe around 300 hackers, and there was only a little money for travel reimbursements. Luckily Seattle is a lot closer to Vancouver than Waterloo, so it was just a 4 hour bus ride. That might seem long by European standards but definitely not in North America!

Opening Ceremony at DubHacks

Hackers Representing

I went down with a couple of other students from UBC, most of whom I didn’t know before but we had a good old time. I decided to work on a project that I’d been thinking about for a long time but never gotten around to – an app for conducting live polling of an audience. The idea is to have students in a lecture/class or attendees at a conference/presentation answer questions in real-time, thereby keeping them engaged and providing valuable feedback for the speaker to respond to, perhaps diving into an area of identified misunderstanding that needs to be clarified.

If you’re thinking that this would be a problem well solved by something like Node.js which is great for real-time apps, you’d be right. Unfortunately, I’ve been a bit behind on the learning Node front since I’ve moved onto working on front-end dev at work, which meant picking up Angular over the last few weekends. But c’est la vie. I used Rails and jQuery instead since the hackathon was a short one and I wanted to be able to code as much as possible, rather than reading docs (inevitable as it is).

For the real-time functionality, I used Pusher which delivered the messages between server and client – a big thank you to them for providing me with a free upgraded account for the weekend! They made it super easy to integrate with my Rails server and JavaScript front-end.

One other thing to add is that I ended up flying solo for the event.

I decided to work on my own at DubHacks because I thought it’d be a kind of fun endurance challenge (I managed 33 hours without sleep!) to see how much I could build on my own – plus some of my friends couldn’t make the event. I figured it would be a nice change from collaborative coding which while vital to getting things done in the real world, necessarily involves not coding a lot of the time. Don’t get me wrong, working in a team is essential but there’s something fun about being the decision maker and executor. It can be fun to live and die by your own sword – or to put it another way, I just wanted to see what I was made off. Skills I need to continue working on would become more glaringly obvious and help me figure out what to concentrate on the next few months.

For the most part, I pulled it off. My main weakness in web development continues to be design and that’s ok – I’m an engineer after all – on the coding front, my front-end skills are still not at the same level as my back-end but it was nice to see that things are coming along. The app I made doesn’t look half bad at all. The downside was that spending so much time on the front-end and design meant a few bugs in the finally demo-ed app. Super frustrating since I fixed all of them this afternoon (after the hackathon) in an hour, but when you’re sleep-deprived it is hard to think of manual test cases and spot the stupid bugs. I also need to learn more about database design, I think that’s probably something that is hard to from a book and is mostly learned from experience in the real-world. I’m definitely going to ask my co-workers at Axiom Zen how they would have designed the database for my app and see what design decisions I can improve on in the future.

I didn’t win a prize at this event which was disappointing (who doesn’t like being competitive!) but not surprising now that I think about it. My app had small but obvious bugs that took away from the end-product, and wasn’t novel enough to warrant attention amongst the hardware hacks and distributed prime number finders at the event 🙂

Winners of hackathons, I’ve realized, tend to build projects that are technically novel – that would impress other hackers – and while they need to solve a problem, it is not essential to for the problem to be a particularly painful one or for the solution to be readily adoptable. It’s a hackathon not a product-thon if that makes sense. It has to have some value but building cool stuff for its own sake deserves a lot of respect as well. Some of the winners used a Myo, Google Glass and Oculus to control a robot and be able to see the visuals via Skype. Pretty cool.

One other thing I’ve been reminded of at DubHacks is that there is no need to build the core tech itself, at least not at student hackathons. For example, the grand prize winning team didn’t need to build or understand the complexities of the speed reading api that they exported to multiple clients/platforms, it was enough that they got it to work and could put something in the judges’ hands and say, hey this is some cool stuff. Winning Hack the North a month ago, was like that too. We solved a problem using a complex API that neither of us understood (hey, it’s an NP complete problem!) but still created something that was cool.

Space Needle

Good thing the Space Needle is tall and near the bus stop – there wouldn’t have been any sightseeing otherwise!

So what next?

Well, after building a prototype of my live polling application at DubHacks, I still think the problem it tries to solve exists and is one that needs a good/better solution, and so I’m planning to continue developing my live polling app over the next few weeks. It will need to be a complete re-write since the Rails app I made is some of the least DRY (so wet?) code I’ve written in a long time – the number of random script tags and !important CSS tags would be embarrassing in the real world, but hey it’s a hackathon app!

So yeah, definitely going to use it as an excuse, if I needed one, to learn Node and to come up with something more robust. It’s annoying to have to use a technology stack you know is ill-suited to the problem because you don’t quite yet know the alternative. Inspiration to continue learning then. Always keep on learning.

Oh, and here’s the app I built (plus an hour of post-hackathon tidying up of the most obvious styling issues and bugs).

Screenshot of LivePoll homepage

LivePoll – I’m definitely getting better at this design thing

Hack the North

This time last weekend, I was on the other side of Canada in Waterloo, ON, hacking away. Maybe it has something to do with the distance traveled to get there, but it seems like a long time ago. I almost feel like I’m moving backward taking this weekend easy (and by easy, I mean getting more than 6 hours of sleep total from Friday to Sunday).

Hack the North is Canada’s largest student hackathon and this year’s inaugural event held last weekend had about 1000 students attending from countries all across the world. Generous sponsorship meant flight tickets were significantly reimbursed 80%+ of the cost, and so students from as far away as Amsterdam and Shanghai were in attendance.

There wasn’t any specific theme to the event, other than to build something cool that worked – no one said as much but I surmise that’s the aim of every hackathon. Lots of cool hardware was available to work on as well, from Myos to Pebbles and Oculus Rifts.

Getting to the event from Vancouver was an event in itself, a crazy early start, then waiting at the airport on the other side for the shuttle to Waterloo, and then the trip on the shuttle itself. Who knew that the traffic in Toronto, where everyone flies into, would be so bad.

There was a little dinner left when we arrived and then we got to hear some amazing speakers open the event. We had Chamath Palihapitiya who was formerly in charge of growth at Facebook and is now in VC, starting the fund The Social+Capital Partnership  He spoke about startups and gave realistic advice about what life in tech is like. Chamath was extremely confident and charismatic, and it’s easy to say that he is one of the best orators I’ve ever heard. Check out his talk here (the video is still not up but I’ll update this post when it is!).

image

The hacking started at midnight and my friend Daniel and I got to work building a travel optimization app. It uses Yelp’s API to get a list of attractions in a city and Routific’s routing optimization API to provide an efficient route to visit the attractions in a single day if one exists. A quick way for tourists to determine how much they can get the most bang for their buck on their vacation.

There were chips and soda aplenty to keep people powered through the event, and there was even a small sleeping area. Unfortunately the sleeping area wasn’t really too well organized, it was brightly lit and far too small so I guess they didn’t expect many hackers to sleep much during the event. Daniel and I ended up finding chairs in a random room on the Waterloo Campus on Saturday morning for a couple of hours of sleep.

Saturday night/Sunday morning was probably the most interesting. People were definitely starting to feel the burn by that point and this was the scene at 4am

image

image

Every team got a chance to pitch their app in 100 seconds in front of a selected group of the judges, so there was definitely something to aim for during the hackathon. It’s all a bit of a blur but I spent most of Sunday morning trying to finalize the general flow and look of the app – I am definitely not a designer.

In terms of the stack, we built our app using Angular and had a Rails back-end for interfacing with the various APIs. Neither of us had used Angular before so that definitely made the hackathon interesting to say the least. We figured if you can’t try out some new tech in a hackathon, when else can you!

One of the things we found is that Angular, a JavaScript front end framework, is very domineering. You either use it completely for the front end, or prepare for some unexpected behavior if you try to mix in some regular JavaScript in there. We definitely ended up finding ourselves in the latter position, as we moved to get things working even if that meant doing things in less than the Angular way.

Another thing I learned this weekend was about OAuth, an authentication protocol which we used to communicate with the Yelp API. Since it uses tokens and secret keys, it wasn’t possible to have just a front end, we needed a back-end as well to prevent exposing our keys. This is different from something like the Google Maps API which we used as a map and for geocoding in our app (since Yelp doesn’t always return an attraction’s latitude and longitude) where client exposed keys are OK.

By the time hacking stopped at 10am, I’d been up for more than 24 hours, with little sleep before that period(!), so I managed to get a quick nap before we pitched in front of the judges.

Our app lacked the design polish of other teams, but the judges found our app pretty interesting, as did the engineers from Yelp who we pitched to separately (main prize vs API specific prizes basically). I thought we did decently for a team of two who were using a different stack than normal and it was great to find out later that Yelp had awarded us the prize for best app to use their API at the event!

We are getting 4 leap motions between the two of us. I’ll make a post once those arrive in the mail! Definitely interested to see what can be done with the hardware. Hardware hacks are not something I’ve really explored before.

But yeah, what an experience. Daniel and I work at the same company as coop software engineers, Axiom Zen, and it was great that we got the Friday off to travel to the hackathon and that we got so much support from them. They were pretty stoked that we managed to bring home a prize as well, using an API from a company they are helping accelerate. It’s great to work somewhere which gets as excited about things like hackathons as you are.

So what next? Work is super busy, there’s always lots to do but I’m enjoying it – more on that soon. I saw some interesting apps built in Node.js at the hackathon so that’s on the agenda this weekend! I’ll post if I build anything half decent 🙂

And if you’re wondering how you can get involved in hackathons, ChallengePost is a great website to start off with. They list hackathons going on around the world, both offline and online.

Hello there – A postface to the summer

Time flies. It really does.

One of the things I discovered when I first started this blog is that I really enjoy writing, and as much as the writing, the thinking about and reflecting. I haven’t taken the most direct route into coding by any means and so when I first started, I figured it would be a good idea to write down the little things that can help speed up a coder’s learning – partly for you, the reader who may be anywhere in their journey to coding mastery, but also for me, we tend to forget things if we don’t write them down and think about them!

And yet, it’s been a while since my last post simply because I’ve been too busy doing, and haven’t had a chance to come up for air and think, well, what have I learned the last few months? What would I tell past Jeremy to help him learn better.

Over the last few months I have:

  1. Done summer school for the first time and the last – I’m in an accelerated program so we’re pretty much in school year round!
  2. Completed the “interview courses” at UBC in Algorithms and Computer Systems – i.e. the ones that are meant to provide the foundational theory for answering most interview questions
  3. Built a web application for locating bike racks in Vancouver using Google Web Toolkit for a class project
  4. Started a four-month internship (a co-op really) at Axiom Zen, a startup in Vancouver downtown
  5. Coded a LOT during my internship
  6. Convinced myself (again) that I could definitely work as a software engineer (as a decent one too, I think – but then again I’m biased)


Classes, classes, classes…

The first three points in the list above kept me pretty busy all through summer, taking 4 courses at one time is no mean feat. I was super excited to take the courses that everyone said would prepare me really well for interviews for my next co-op and for a full-time job after graduation, but to be honest, I realized that the profs mostly covered the theory in a somewhat abstract way, and it was left to you to connect the dots come interview time. A typical university education some might say, but with the wealth of resources available out there, and if your one and only goal is to get the best software engineering gig as possible, I feel confident enough to say that learning CS theory in a university setting is not strictly necessary by any means. Helpful yes, but meeting up/being mentored by someone who already knows the stuff and thinking about the own problems – which university sometimes gives you little time to do – is more important. When learning about computation systems or algorithms at university, it’s easy to take little diversions into long and complex areas of the field which, while academically interesting, are not things anyone expects you to know in the real world 🙂

Some of the things I learned this summer were definitely interesting though. Particularly the intermediate algorithms course, which covered different approaches one can take to designing an algorithm for a particular problem – everything from stable matching to the debate over P vs NP.


An internship

I finished my last set of exams in late August, took a weekend off (can I even say that? Weekends are default holidays right?) and started my four-month software engineering internship at Axiom Zen. It’s technically a co-op since it’s coordinated through UBC and my university program, but there’s not much difference – I’ll call it an internship from here on in, just because it’s probably a lot clearer to anyone who’s not studied in Canada!

Before starting at Axiom Zen, I’d visited the office and the people a couple of times and really hit it off, so I was pretty much raring to go and started the Monday after classes were over. The company works with clients to develop web and mobile apps as well as incubates its own in-house startups, so it’s definitely a very interesting environment to work in. There is a pretty much flat hierarchy, so that’s definitely been a change from my last job where it was very clear who answered to whom and when (not the why so much, they always left that part out).

Learning and working/coding in the real world is a new stage to my coding journey, and one that I’m looking forward to sharing with you over the next few months. The plan is to write short posts with the little nuggets of wisdom that I’ve gleaned from working at the coalface of the industry, things you don’t or can’t generally pick up at school or working as an independent.

Since I started at Axiom Zen, I’ve been treated pretty much like a full-time software engineer and have written lots of code, and just generally gotten involved! That’s definitely something special – we’ve all heard of those internships where you do little more than fetch coffee and sneakily check facebook – so I’m having a good time and learning lots which I hope to translate into a collection of posts. Stay tuned!