How to Vet a Startup’s Culture While InterviewingBy Chris Muir
When you're considering a job at a startup, it's important to take their culture (workstyle, values, and environment) into account. Here's what to look into.
Devpost is the home for hackers, a community where you can meet great developers, build a portfolio of your work, and compete in online & in-person hackathons. We think it’s important to tell the story behind your code.
Why We Rebranded
When we started ChallengePost in 2009, it was a platform for online competitions (challenges). And back then, challenges could be about anything: videos, ideas, software, recipes, etc.
About two years ago, we noticed that our best and most inspiring challenges were about software and tech. We shifted our focus solely to software developers hackers and got more involved in the hackathon scene & building tools to help hackers celebrate & showcase their projects. And in July, we decided to rebrand to reflect that shift and our commitment to it.
Two Months to Make DNS Changes?!
You might think that, tech wise, rebranding is easy. Once the design & marketing team figure out the creative stuff, it’s just one big find / replace. Change the logo, some CSS and text, fiddle with DNS, redirect to a new URL, and you’re done—right?
It might be that easy in some cases, but it’s largely dependent on the context. (And FYI, it took Holly and me ~ four months to do the “creative stuff.”)
At Devpost, that context included many disparate factors like our users, product, business needs, infrastructure, data, integrated services, email deliverability, SEO, code base, etc. Each one of these factors came with its own caveats and issues. Just being aware of them was hard enough. Coordinating the changeover to minimize potential problems required a lot of planning.
Ross, our CTO, created a Trello board to capture all the concerns his team needed to address. In many cases, it simply listed what we knew to be the problem and what we believed to be its importance. The list included things like:
And oh yeah, we also needed us to perform this switch before the fall hackathon season and with minimal impact to existing clients. In other words: as fast as possible and with no mistakes!
In preparation for the big day, we spun up sister versions of the site for our staging and production environments. This meant that devpost.com could be live well in advance on the switch without concerns about DNS latency. We were also able to upgrade key dependencies of our architecture (e.g. Ruby and Redis) on the Devpost stack and troubleshoot those changes without affecting our challengepost.com production environment.
The tech team also needed several weeks to work through changes in the codebase. In addition to the surface-level changes, like the new site design, they needed to refactor out a bunch of assumptions in the business logic and our data, most notably, the domain on which we served the site. Making these things configurable enabled us to run the site on arbitrary domains—something that might be easy to do for a brand new business—for us, was not straightforward. This meant working through several years of accumulated business and technical decisions that were impeding the current needs.
As with all choices in tech, there are tradeoffs and not everything we needed could be accomplished in advance. To maintain continuity with our OAuth providers, like Facebook and GitHub, we had to switch settings manually during the transition.
By running two versions of the site, we also needed to ensure data continuity. We could have tried a number of things, like sharing the database layer or setting up a parent-child relationship between the stacks. But, after working with the team at EngineYard, we decided the easiest approach would be to shut down site traffic and run scripts to import the data one time between the stacks during the transition.
ProTip: Call your hosting providers in advance and ask for their help. They’ve probably done this before.
Playbooks & Practice
When we realized we’d have a number of steps to work through during the transition, we wrote a playbook to orchestrate the changes. Steps included “Put up maintenance page”, “Shut off background processes”, “Trigger mysql backup”, “Kick off Chef recipes”, “Enable nginx redirects”. This level of detail meant we could assign roles to each member of the development team.
Ross and his team also performed several “dress rehearsals” on our staging environments, so that every member of the team had the experience of working through his or her role and potential problems that might arise.
On Game Day, July 28th, we were online before 6am ET (Ross was at the office at 5:15am.) to make final preparations before kicking off the rebrand at 6:30 in the morning. After some tense moments of running scripts, changing settings, and monitoring the system, Devpost was live to the public before 7:15am. Tech spent the remainder of the morning on followup tasks like additional settings changes and CSS tweaks that we had punted on earlier.
By noon, at what felt like the end of the day, it was time to celebrate with champagne from the boss and ice cream cake. Success!
ProTip: Remember, no matter how much you test, the only place where issues in production happen is in production!
More than Code
Upstairs in the marketing loft, I chewed my fingernails waiting for CNAMES to start working and preparing to update our social media profiles. Unlike the tech team, I couldn’t practice or rollback most of these changes:
Rebranding was a major team effort and our team executed it quickly and with minimal issues. It was a great show of solidarity, efficiency, and most importantly, planning. If you have any detailed questions about what we did or how we did it, tweet us @Devpost!
Every week we send out a newsletter called Ruff Notes with our personal thoughts on something interesting we’ve read, as well as product updates and news from our community.