Google recently released a new way to prevent spam: the invisible reCaptcha. The HubSpot product team is introducing this new tool on all forms in our product soon, because it'll help customers generate more legitimate leads. Want to give it a try? You only need a few steps to add invisible reCaptcha to your website.

There are some companies that have special co-op and internship projects that are separate from their normal stream of product development. Often, the work of co-ops and interns never sees the light of day, or at least not while they're at the company.

We fundamentally do not believe in this approach. We believe that the best way to learn is by doing, and therefore, the best way to learn how to be a software engineer is to do what a software engineer does.

We broke up with scrum about six years ago.

Agile development served us well in startup mode, but as we added more seats, opened new space, and launched new tools, it actually started to stunt our product culture’s growth. Take autonomy, for starters. We think engineers should have complete autonomy over their code and part of the product. And even though scrum is designed to protect developers from the demands and distractions of your CEO, marketing team, sales team, etc., it can actually tie their hands. There’s no trust being built between product and the rest of the company; sprints end up more like transactions than conversations.

Many software developers are familiar with a “fizzbuzz”-type problem in coding interviews. The idea is to ask a fairly trivial coding question of candidates to make sure they are competent coders. This can be done on-site, or in a phone interview format. Although well-intentioned, these kinds of questions are annoying and insulting for qualified candidates, can give false negatives as a result of trivial errors (especially if asked on a whiteboard) and are tedious for interviewers to ask.

We all dream of a perfect, unencumbered world, working with a pristine code base or starting a project from scratch. In reality, I’ve started enough projects to know that I can build myself into a corner just as well as anyone else can, and that things always get messy unless you spend an incredible amount of time refactoring. I’d like to offer some advice about taking over someone else's code based on my experience: Keep your code teardowns to yourself. I learned this the hard way.

Like many companies, we were affected by last week's S3 outage. We were surprised, however, by the extent of the impact to our systems. It was a bit of a wake-up call, and we realized how much of a failure point S3 had become for us and how little we were doing to protected ourselves against S3 downtime.