Posts from October 2015

As a student going through the cooperative education system at the University of Waterloo, I have the opportunity to start at a new internship every 8 months. This means one thing — a ton of onboarding. I’m definitely not an HR expert, but as I’ve been onboarded four different times at three different companies in the last two years, I have some idea of what makes for a good start at a software company.

At the beginning of September, I started my co-op term as a software engineering intern at this startup going through hypergrowth. What’s hypergrowth? — think, learning to ride a bike by pushing yourself off at the top of a steep hill and figuring it out as you go.

This philosophy makes for a pretty unique first week, and provides a few lessons that I believe can be applied to the onboarding process at any company. Here’s a few things which I think stood out.

Read More …

What is #hootjobs? 

At Hootsuite, we do a lot of hiring. A few months ago, we launched #hootjobs on Twitter as an easy, interactive way for people to engage with our staff and our recruiting team. Anyone – prospects, job seekers, and the curious – is invited to ask questions about job openings and life at Hootsuite. On Wednesday October 20th, our current engineering co-op students took to Twitter for a co-op edition of #hootjobs.

Read More …

As our organization grows, we’ve discovered that it’s hard to scale mobile capabilities across the engineering group. As a scaling strategy, we decided to try embedding mobile developers within product teams. This is the story of our experiences with three experiments.

At the time of writing, we have north of 100 engineers organized into stable teams. Each team is responsible for some part of our product or infrastructure (e.g. Web Dashboard, Publishing, Billing, Analytics, etc).

Our Mobile team works on native iOS and Android apps that include features across several of these product teams. For example, features owned by the Publishing team on the Hootsuite web dashboard would be built and maintained on our iOS and Android apps by the Mobile team.

There is an expectation from our customers that (in most cases) we provide a comparable native mobile experience for the functionality that exists in our web products. An issue that we have run into is that the number of native mobile app developers is only about one sixth of the total number of engineers, thus the Mobile team’s backlog grows much faster and the team feels that it is constantly playing catchup. Because building native mobile apps is such a specialized skill, it’s also hard to hire mobile engineers at a pace that allows the team to keep up.

Three Experiments

To alleviate this problem, we ran three experiments to grow native mobile expertise in our non-mobile feature teams. Training some of the engineers on these teams who are interested in native mobile app development is a good compromise to hiring, because existing engineers are already familiar with our products, our technical stack, and our culture.

If these experiments prove successful, we envision having native iOS and Android engineers working on teams that are responsible for a set of product features like message publishing or engagement streams. For example, the Publishing team is responsible for back-end as well as customer-facing functionality related to publishing messages on the Hootsuite web dashboard, it makes sense that the team would also own publishing-related functionality on native mobile apps. The core mobile team will maintain the platform that other product teams will build upon and stay responsible for the overall quality and architecture of the apps.

Read More …

What is TDD/BDD development?

TDD comes from “Test Driven Development”. OK, but what does “doing TDD” mean? Doing TDD means letting the tests drive your design, hence the “Driven” part in the name. What that boils down to is writing your tests first, watching them fail and then making them pass by writing your code.

Yes, this can sound pretty confusing! But trust me, it’s worth it. Read on to rest of the post, where I present, a step by step process of writing code using TDD.

FYI: There is a derivative of TDD called BDD “Behavioural Driven Development”. Basically, it’s the same thing as TDD: you write tests for your code first, but the difference consists in how these tests are written. BDD describes the tests using the Gherkin language (a known tool for this is Cucumber).

Note: The examples going forward are written in JavaScript and I will present some specific tools and some web examples. Don’t worry about it, if you know some programming then you are good to go. The concepts presented here can apply to any language and you can easily find equivalent tools.

Test Types

When you write code you must know if it runs well. This means you must know if there are bugs or logic errors. You achieve this by executing the code against an input.

Read More …

Sometimes when you’re developing a product and you are faced with a difficult problem, a clear view of your application structure can help you understand it and solve it faster. Also, having to read and understand poorly written code can make it harder to come up with a solution for the problem.

By using static code analysis we’ve managed to integrate and develop two tools that improve the overall experience of our developers, thus increasing overall code quality as well as general productivity. Read on to find out how we implemented these tools and how they work in our environment.


Static code analysis means analyzing code without executing it. This concept is most commonly used to check if the source code has any errors before runtime, and it’s most often seen in compilers which can find lexical, syntactic and even some semantic mistakes.

First, we need to understand how static analysis actually works. At its core we have the AST which stands for Abstract Syntax Tree. An AST is a tree representation of the structure of the source code where leaves represent constants or variables and inner nodes represent operators or statements.

AST Tree Representation
Image from

ASTs are also called “parse trees” because they are often the output of a parser (usually the parsing stage of a compiler). In JavaScript some parsers are actively developed, but one of the most used is Esprima. Esprima serves as an important building block for some JavaScript language tools, from code instrumentation to editor autocompletion. To see how esprima works we have the following example:

Code Example before Esprima

Esprima takes the code and returns a JSON formatted, ESTree compatible, object which describes the program as a tree structure. Even though each generated node has its own properties, the “type” property is common to all nodes.

Read More …

Hootsuite is using Webpack as a solution for our Static Asset Pipeline, which compiles, concatenates, minifies, and compresses static assets for the Hootsuite website. We chose Webpack because it is a powerful build tool for single-page applications (SPAs). Webpack is good for figuring out module dependencies, making it easier for developers to organize code structure and reuse modules/components among multiple entry points.

In this blog post, I’ll show how you can use Webpack in a project by providing some sample webpack configurations and a git repository as a demo to try out. When you finish reading this blog post, you should be able to configure your web project:

  • to reuse modules and components for single/multiple entry point(s)
  • to build unique bundles for each entry point
  • to build a common bundle for the entry points
webpack module bundler
Image from

Read More …

According to the Nielsen Norman Group’s study on web response time, when a website takes more than 100 milliseconds to load, we start to notice the delay and feel the computer is “working” hard on the command (but not fast enough to our expectations). That’s a problem we’ve faced at Hootsuite too.

As we have grown to serve larger customers – those with hundreds to thousands of members and social networks – our customers started to experience performance issues like loading delays, redundant server communications, and not-so-friendly page refreshes. Most importantly, the Member Management pages – where our customers organize the relationships between members and social networks – could take more than 500 milliseconds to render. We rewrote our Member Management pages using React + Flux and lowered the page load time to under 100ms; an 80% savings. This early improvement makes us excited to see how React & Flux can benefit performance for the rest of our site.

Read More …