Search Results for: job application

The best advice for someone who’s on the job hunt this new year

“Don’t be boring.”

When I asked Amanda Lannert, CEO of Jellyvision, what advice she had for people who are looking to get a job, that’s the answer she gave.

As a CEO of a rapidly growing 400-person company, soon to be 500 people, Lannert has done her fair share of hiring.

“It feels like companies hire people, but in fact people hire people,” she explained. “By and large, recruiters are bored. People play it safe. They commodify themselves into just a bullet-point list of skills and experience.”

By not being boring, Lannert pointed out how you’ll catch a recruiter’s eye, and make yourself much more likely to land that initial phone call or interview.

At the same time, it’s also a great way to assess the fit of the role for you, as a prospective employee. When you show who you are as a candidate — what you value, what environment you work best in — and don’t get a call back, that company may be saving you some time and energy.

How do you not be boring? Here are five things to try:

Focus on the cover letter, not the resume.

At Jellyvision, Lannert shared how they place supreme emphasis on the cover letter. “There’s nothing more refreshing than seeing someone who takes a chance to be incredibly human in a cover letter or an outreach, to put themselves forward,” she says.

This means language that’s real, down to earth — not stiff, business jargon-y, and cut from some googled job site template. As someone who’s reviewed thousands of applicants for jobs for Know Your Team, I’d often set aside an application when the person would start their cover letter with, “I’m interested in X role. Please see my resume attached.” Everybody writes that in their cover letter — focus on saying something different.

Show, don’t tell.

A few years ago, a friend of mine wanted to land a job at Trunk Club, a company he’d been dreaming to work for some time. The only problem was that they weren’t hiring at the time. I suggested that he show them what he had to offer the company — not just tell them. So my friend whipped up a 50-slide PowerPoint presentation detailing ideas, suggestions, and projects for exactly how he could improve their online presence and user experience. He did the work of showing how he’d be an asset to the team — not just telling. Lo and behold, they created a role for him and offered him a job.

Get creative.

As a CEO myself, when I was hiring Know Your Team’s first full-time programmer several years ago, I’ll never forget how one applicant wrote me a poem — yes, a poem — perhaps 20 lines long that described who he was and why he desired the role. While we didn’t end up selecting him (he lived outside the United States and we required that the person live stateside), I remember that application so vividly even years later. He took a chance, got creative, and stood out from the 400+ applications we received in the first 72 hours alone. He was far from boring, and it worked.

Demonstrate you want this job, not just any job.

Another way to not be boring is to make it clear: “I want to work here, nowhere else.” This past year, when we were hiring for our Chief Technology Officer role, someone took the time to build a custom software application, just for Know Your Team. He’d replicated the Know Your Team software to the best of their ability, using what he’d gathered from screenshots he’d seen online. His intention was to demonstrate that he was technically up to snuff for the role.

My greatest takeaway was that it showed he wanted to work here, and nowhere else. I was impressed by him wanting this job, not just any job, and that caught my attention.

Sound like yourself.

Perhaps most importantly, you should make sure you sound like yourself. Don’t try to write a poem if you’re not good at writing poems. Don’t try to be funny in your application if you’re not funny. Be thoughtful in portraying the truest version of yourself — not what you think the employer wants to read.

If you’re concerned about how to do this, the key is simply to take put a little time and care into your application. Don’t rush your writing your cover letter. Think about how you can thoughtfully show who you are and what you can bring to the company. When you pour considered thought and energy into something, your true self will come through. Being not boring is about being yourself, more than anything else.

Keep this credo of “Don’t be boring” in mind, as you apply for a job. Dare to be different, and stand out from the sea of bullet-pointed list resumes and bland cover letters. The less boring you are, the more memorable you are. And the more memorable you are, the more likely you’ll land the job you want.

---

Claire is the CEO of Know Your Team – software that helps you become a better manager. Her company was spun-out of Basecamp back in 2014. If you were interested, you can read more of Claire’s writing on leadership on the Know Your Team blog.

This article was originally published for Inc.com.

The entire conversation, together in Basecamp

Basecamp 3 is great for keeping your entire team on the same page. All your to-dos, important events, documents, and conversations in one place, wherever you are. But what if the conversation starts outside of Basecamp?

Email is hard to avoid. Small businesses of all kinds depend on email to get things done. You discuss plans for the new office with your contractor over email. You review job applications submitted via email. You receive marketing emails from competitors you want to share with your team.

You could paste these important emails into a message or text document, but keeping up with replies can be a real hassle.

With the new Forwards tool, you can save any email to Basecamp 3, collect comments from your team, and reply directly to the original sender. Now, the whole conversation — comments and replies — lives in one place.

Getting Started

To start using Forwards in Basecamp 3, turn it on via the “Pick your tools…” screen. You can even rename it to something like “Job Applicants” or “Survey Responses” to suit your needs — whatever works!

Once you’ve turned it on, Forwards will appear beside the Message Board, To-dos, and all the other tools in your Basecamp:

Forwarding Emails

Now that you’ve enabled the tool, you can send emails two different ways:

1. Forward any email to save@3.basecamp.com and we’ll send you a response email asking where to save it.
2. Forward email to your personalized dropbox address and we’ll automatically save emails to Basecamp 3 without being asked where to file it. This is especially handy if you want another service to forward emails into your Basecamp directly.

After you forward it to Basecamp, your email will show up in the Forwards inbox along with all the other emails you’ve saved:

Click through to view the email, add a comment, or reply directly to the sender. Either way, your team is always in the loop!

Comments are for your team’s eyes only. The original sender will never see what you write. Replies are emailed to the original sender and shared with your team.

Basecamp 3 will collect replies from the original sender and thread them in alongside comments from you and your team. It’s all there — the original email, every email reply, and any comments along the way.

Thanks for using Basecamp 3! We hope this makes it easier for you to keep your entire email conversation — not just comments from your team — in once place.

---

Running your business on email, chat, and meetings? No wonder you’re frazzled — that’s the hard way! You do not have to put yourself and you team through the anxiety ringer all day, all week, all month, all year, and all career. There’s a better way.

Do yourself and your whole team a solid and switch over to Basecamp 3. It’s the saner, more organized way to run your business. We promise.

Chairman Klein and members of the Senate Industry, Business and Labor Committee-

My name is David Heinemeier Hansson, and I’m the CTO and co-founder of Basecamp, a small internet company from Chicago that sells project-management software and email services.

I first testified on the topic of big tech monopolies at the House Antitrust Subcommittee’s field hearing in Colorado just over a year ago, where I described the fear and loathing many small software makers have toward the app store duopoly. 

How fees upwards of 30% of revenue, applied selectively, and in many cases capriciously, put an enormous economic burden on many small software businesses. How paired with the constant uncertainty as to whether the next software update will be rejected, or held for ransom, can put entire businesses in jeopardy.

I was then merely speaking on behalf of my many fellow small  business owners. As someone who’d heard the tragic stories from app store duopoly victims, whispered out of fear of further retribution, for the better part of the last decade.

Little did I know that just six months later, Basecamp would be in its own existential fight for survival, after launching a new, innovative email service called HEY.com. Apple first approved our application to the App Store, only to revert themselves days later, after we had publicly launched to great critical acclaim. They demanded we start using their in-application payment system, such that they could take 30% of our revenues, or we’d be kicked off the App Store. A virtual death sentence for a new email service that was aiming to compete with the likes of Google’s Gmail and Apple’s own iCloud email hosting.

Keep reading “Testimony before the North Dakota Senate Industry, Business and Labor Committee”

We have two rare openings on our Core Product team for Rails programmers. We’ll be accepting applications for the next two weeks, aiming for a flexible start date in October.

We strongly encourage candidates of all different backgrounds and identities to apply. This is an opportunity for us to bring in a different perspective and we’re eager to further diversify our company. Basecamp is committed to building an inclusive, supportive place for you to do the best work of your career. We aren’t looking for ideological clones, but for people who share our beliefs about writing software well.

Keep reading “We’re hiring Rails programmers”

Basecamp is hiring three new System Administrators for our Operations team to help us deliver fast and reliable applications, like Basecamp and our new email service HEY. Our infrastructure exists both in colocated data centers and in the cloud, and you’ll be working alongside our existing team of Blake, Eron, John, Matt, Matthew, Nathan, and Troy.

As you might gather from the names, our operations team today is not nearly as diverse as we’d like it to be, or as the rest of the company. We therefore strongly encourage candidates of all different backgrounds to apply. Basecamp is committed to building an inclusive, supportive place for you to do the best and most rewarding work of your career. We are an equal-opportunity employer and are committed to building a company that embraces and celebrates diversity and inclusion.

Keep reading “Basecamp’s Ops Team is Hiring”

Since we started working on HEY, one of the things that I’ve been a big proponent of was keeping as much of the app-side compute infrastructure on spot instances as possible (front-end and async job processing; excluding the database, Redis, and Elasticsearch). Coming out of our first two weeks running the app with a real production traffic load, we’re sitting at ~90% of our compute running on spot instances.

Especially around the launch of a new product, you typically don’t know what traffic and load levels are going to look like, making purchases of reserved instances or savings plans a risky proposition. Spot instances give us the ability to get the compute we need at an even deeper discount than a 1-year RI or savings plan rate would, without the same commitment. Combine the price with seamless integration with auto-scaling groups and it makes them a no-brainer for most of our workloads.

The big catch with spot instances? AWS can take them back from you with a two-minute notice.

Keep reading “Running spot instances effectively with Amazon EKS”

There’s no perfect process for hiring great programmers, but there are plenty of terrible ways to screw it up. We’ve rejected the industry stables of grilling candidates in front of a whiteboard or needling them with brain teasers since the start at Basecamp. But you’re not getting around showing real code when applying for a job here.

In the early days of the company, we hired programmers almost exclusively from the open source community. I simply tapped people I’d been working with on the Ruby on Rails project, and I knew that their code would be good, because I’d seen so much of it! This is how we hired Jamis, Jeremy, Sam, Josh, Pratik, Matthew, and Eileen.

But if you only consider candidates from the open source community, you’re going to miss out on plenty of great programmers who just don’t have the time or the inclination to contribute code to open source.

And unfortunately, it’s rarely an option for candidates to submit code from a previous job with an application to a new job. Unlike design, which is at least somewhat out in the open, commercial code is often closely guarded. And even if it wasn’t, it’s often hard to tease out what someone was actually personally responsible for (which can also be a challenge with design!).

So what we’ve started to do instead at Basecamp is level the playing field by asking late-stage candidates to complete a small programming assignment as part of the final evaluation process. I’m going to show you two examples of these projects, and the submissions from the candidates that ended up being hired.

Keep reading “Hiring programmers with a take-home test”

Basecamp’s newest product HEY has lived on Kubernetes since development first began. While our applications are majestic monoliths, a product like HEY has numerous supporting services that run along-side the main app like our mail pipeline (Postfix and friends), Resque (and Resque Scheduler), and nginx, making Kubernetes a great orchestration option for us.

As you work on code changes or new feature additions for an application, you naturally want to test them somewhere — either in a unique environment or in production via feature flags. For our other applications like Basecamp 3, we make this happen via a series of numbered environments called betas (beta1 through betaX). A beta environment is essentially a mini production environment — it uses the production database but everything else (app services, Resque, Redis) is separate. In Basecamp 3’s case, we have a claim system via an internal chatbot that shows the status of each beta environment (here, none of them are claimed):

Our existing beta setup is fine, but what if we can do something better with the new capabilities that we are afforded by relying on Kubernetes? Indeed we can! After reading about GitHub’s branch-lab setup, I was inspired to come up with a better solution for beta environments than our existing claims system. The result is what’s in-use today for HEY: a system that (almost) immediately deploys any branch to a branch-specific endpoint that you can access right away to test your changes without having to use the claims system or talk to anyone else (along with an independent job processing fleet and Redis instance to support the environment).

Keep reading “Seamless branch deploys with Kubernetes”

We’re hiring a programmer to join our Research & Fidelity team to help shape the front end of our Rails applications and expand our suite of open-source JavaScript frameworks. We’re accepting applications for the next two weeks with a start date in early April.

We strongly encourage candidates of all different backgrounds and identities to apply. Each new hire is an opportunity for us to bring in a different perspective, and we are always eager to further diversify our company. Basecamp is committed to building an inclusive, supportive place for you to do the best and most rewarding work of your career.

ABOUT THE JOB
The Research & Fidelity team consists of two people, Sam Stephenson and Javan Makhmali, whose work has given rise to Stimulus, Turbolinks, and Trix—projects that exemplify our approach to building web applications. You’ll join the team and work with them closely.

In broad terms, Research & Fidelity is responsible for the following:

• Designing, implementing, documenting, and maintaining front-end systems for multiple high-traffic applications
• Building high-fidelity user interface components with JavaScript, HTML, and CSS
• Assisting product teams with front-end decisions and participating in code reviews
• Tracking evergreen browser changes and keeping our applications up-to-date
• Extracting internal systems and processes into open-source software and evolving them over time

As a member of the R&F team at Basecamp, you’ll fend off complexity and find a simpler path. You’ll fix bugs. You’ll go deep. You’ll learn from us and we’ll learn from you. You’ll have the freedom and autonomy to do your best work, and plenty of support along the way.

Our team approaches front-end work from an unorthodox perspective:

• Our architecture is best described as “HTML over the wire.” In contrast to most of the industry, we embrace server-side rendered HTML augmented with minimal JavaScript behavior.
• We implement features on a continuum of progressive enhancement. That means we have a baseline of semantic, accessible HTML, layered with JavaScript and CSS enhancements for desktop, mobile web, and our hybrid Android and iOS applications.
• We believe designers and programmers should build UI together, and that HTML is a common language and shared responsibility. Our tools and processes are manifestations of this belief.
• We are framework builders. We approach intractable problems from first principles to make tools that help make Basecamp’s product development process possible.

Here are some things we’ve worked on recently that might give you a better sense of what you’ll be doing day to day:

• Working with a designer during Office Hours (our weekly open invitation) to review and revise their code
• Researching Service Workers and building a proof-of-concept offline mode for an existing application
• Creating a Stimulus controller to manage “infinite” pagination using IntersectionObserver
• Investigating a Safari crash when interacting with <datalist> elements and filing a detailed report on WebKit’s issue tracker
• Extracting Rails’ Action Text framework from the rich text system in Basecamp 3
• Working with programmers from the iOS and Android teams to co-develop a feature across platforms
• Porting Turbolinks from CoffeeScript to TypeScript and refactoring its test suite
• Responding to a security report for our Electron-based desktop app and implementing a fix

ABOUT YOU
We’re looking for someone with strong front-end JavaScript experience. You should be well-versed in modern browser APIs, HTML, and CSS. Back-end programming experience, especially with Ruby, is a plus but not a requirement. You won’t know how all the systems work on day one, and we don’t expect you to. Nobody hits the ground running. Solid fundamentals with software development, systems, troubleshooting, and teamwork pave the way.

You might have a CS degree. You might not. That’s not what we’re looking for. We care about what you can do and how you do it, not about how you got here. A strong track record of conscientious, thoughtful work speaks volumes.

This is a remote job. You’re free to work where you work best, anywhere in the world: home office, coworking space, coffeeshops. While we currently have an office in Chicago, you should be comfortable working remotely—most of the company does!

Managers of One thrive at Basecamp. We’re committed generalists, eager learners, conscientious workers, and curators of what’s essential. We’re quick to trust. We see things through. We’re kind to each other, look up to each other, and support each other. We achieve together. We are colleagues, here to do our best work.

We value people who can take a stand yet commit even when they disagree. And understand the value in others being heard. We subject ideas to rigorous consideration and challenge each other, but all remember that we’re here for the same purpose: to do good work together. That comes with direct feedback, openness to each others’ experience, and willingness to show up for each other as well as for the technical work at hand. We’re in this for the long term.

PAY AND BENEFITS
Basecamp pays in the top 10% of the industry based on San Francisco rates. Same position, same pay, no matter where you live. The salary for this position is either $149,442 (Programmer) or $186,850 (Senior Programmer). We assess seniority relative to the team at Basecamp during the interviewing process.

Benefits at Basecamp are all about helping you lead a healthy life outside of work. We won’t treat your life as dead code to be optimized away with free dinners and dry cleaning. You won’t find lures to keep you coding ever longer. Quality time to focus on work starts with quality time to think, exercise, cook a meal, be with family and friends—time to yourself.

Work can wait. We offer fully-paid parental leave. We work 4-day weeks through the summer (northern hemisphere), enjoy a yearly paid vacation, and take a one-month sabbatical every three years. We subsidize coworking, home offices, and continuing education, whether professional or hobbyist. We match your charitable contributions. All on a foundation of top-shelf health insurance and a retirement plan with a generous match. See the full list.

HOW TO APPLY
Please send an application that speaks directly to this position. Show us your role in Basecamp’s future and Basecamp’s role in yours. Address some of the work we do. Tell us about a newer (less than five years old) web technology you like and why.

We’re accepting applications until Sunday, February 2, 2020, at 9:00PM US-Central time. There’s no benefit to filing early or writing a novel. Keep it sharp, short, and get across what matters to you. We value great writers, so take your time with the application. We’re giving you our full attention.

We expect to take two weeks to review all applications. You’ll hear from us by February 14 about whether you’ve advanced to the written code review part of the application process. If so, you’ll submit some code you’re proud of, review it, and tell its story. Then on to an interview. Our interviews are one hour, all remote, with your future colleagues, on your schedule. We’ll talk through some of your code and some of ours. No gotchas, brainteasers, or whiteboard coding. We aim to make an offer by March 20 with a start date in early April.

We look forward to hearing from you! ✌️

We spend about $3 million every year to run all the versions of Basecamp and our legacy applications. That spend is spread across several on-premise data centers and cloud operations. It does not include the budget for our 7-person strong operations team, this is just the cost of connectivity, machines, power, and such.

There’s a lot of spend in that bucket. The biggest line item is the million dollars per year we spend storing 4.5 petabyte worth of files. We used to store these files ourselves, across three physical data centers for redundancy and availability, but the final math and operational hassle didn’t pan out. So now we’re just on S3 with a multi-region redundancy setup.

After that, it’s really a big mixed bag. We spend a lot of money on databases, which all run on MySQL. There’s ElasticSearch clusters that power our search. A swarm of Redis servers providing caching. There’s a Kafka pipeline and a Big Query backend for analytics. We have our own direct network connections between the data centers and the cloud.

Everything I’ve talked about so far is infrastructure we’d run and pay for regardless of our programming language or web framework. Whether we run on Python, PHP, Rust, Go, C++, or whatever, we’d still need databases, we’d still need search, we’d still need to store files.

So let’s talk about what we spend on our programming language and web framework. It’s about 15%. That’s the price for all our app and job servers. The machines that actually run Ruby on Rails. So against a $3 million budget, it’s about $450,000. That’s it.

Let’s imagine that there was some amazing technology that would let us do everything we’re doing with Ruby on Rails, but it was TWICE AS FAST! That would save us about ~$225,000 per year. We spend more money than that on the Xmas gift we give employees at Basecamp every year. And that’s if you could truly go twice as fast, and thus require half the machines, which is not an easy thing to do, despite what microbenchmarks might delude you into thinking.

Now imagine we found a true silver bullet. One where the compute spend could be reduced by an order of magnitude. So we’d save about $400,000/year, reducing everything we spend running our app and job servers to an unrealistically low $45,000/year. That reduction wouldn’t even pay for two developers at our average all-in cost at Basecamp!

Now let’s consider the cost of those savings. We spend more money on the 15-strong developer team at Basecamp than our entire operations budget! If we make that team just 15% less productive, it’ll cost us more than everything we spend to run Ruby and Rails at Basecamp!

Working with Ruby and Rails is a luxury, yes. Not every company pay their developers as well as we do at Basecamp, so maybe the rates would look a little different there. Maybe some companies are far more compute intensive to run their apps. But for most SaaS companies, they’re in exactly the same ballpark as we are. The slice of the total operations budget spent running the programming language and web framework that powers the app is a small minority of the overall cost.

For a company like Basecamp, you’d be mad to make your choice of programming language and web framework on anything but a determination of what’ll make your programmers the most motivated, happy, and productive. Whatever the cost, it’s worth it. It’s worth it on a pure cost/benefit, but, more importantly, it’s worth it in terms of human happiness and potential.

This is why we run Ruby. This is why we run Rails. It’s a complete bargain.