It’s October, the time of year when leaves start to fall from the trees, and companies start to recruit college students for summer internships. Last week, I spent half a day interviewing some of those candidates. I also came across a long Hacker News thread called I Hate HackerRank. So I thought it would be a good time to revisit the dreaded coding interview.

« Continue »

In July of this year, Stack Exchange Inc. released an online tool that lets you calculate how much money you would make if you worked there. The number you get out of the tool is based on four factors. There’s a salary floor based on the position you select (e.g., Developer or Product Designer), an adjustment based on your years of professional experience, and a bonus for living in one of a few high cost cities (New York, San Francisco, or London). Finally, the tool takes into account your skills.

Having written in the past about skills for programmers, I was interested to see what Stack Exchange decided was important for success in a programming job. Here’s what I found.

« Continue »

You can become a better software developer by improving your ability to organize information. A key part of that skill is being able to communicate what you know in writing. Whether you’re enlightening your peers on Stack Overflow or writing FAQs for your team, it’s good to have a reputation as a person who Knows The Answers. If you can write clear technical designs, how-to guides, and other documentation, you can have a lot of influence. In fact, even if you just write for yourself, you can get things done faster by avoiding trips to the Web to repeatedly look up the same information.

Here are some tips on when, what, and how to write as a programmer.

« Continue »

Cal Newport likes to distill the components of productivity into the following formula:

Work Accomplished = Time Spent x Intensity

We all have 24 hours per day, excluding the occasional leap second. That plus the need for sleep puts an upper limit on the Time Spent component of the formula. Intensity, in theory, has no upper limit. You could spend a lifetime getting better at concentrating. So it would seem that the Intensity component is the one to target for improvement.

There’s some truth to that analysis. Cal’s fixed-schedule productivity technique starts by making Time Spent a constant. Intensity is the only component you’re allowed to adjust.

But as you make your way toward that gloriously fixed schedule, it’s helpful to track how many hours you’re actually working, as well as how intensely you’re focusing during those hours. To do that, you have to follow a few rules.

Here are four rules to make use of the Work Accomplished formula.

« Continue »

Another session of Top Performer is underway, and one of the goals of the early lessons is finding a skill that is important for success in your career. That has me thinking about skills for programmers. Today I’m going to focus on one particular skill that is critical for programmers working on a team, and becomes more critical as you work on larger projects.

I wrote about a few different skill categories in Skills for Programmers. If you’re a new college graduate starting a full-time job, you might have strong algorithmic problem-solving skills, knowledge of Computer Science fundamentals, expertise in a few specific technologies, and good work habits. Depending on your background, you may even have some of the soft skills required for success at a software company. But what new graduates generally don’t have is experience working on a large codebase that a team of programmers has built up over several years.

When you’re building a small project from scratch, technical questions can be answered through a Stack Overflow search. You still have to think about timeless software engineering questions like good design and whether you’re building the right product for your target audience. But you can rely on others who are working with the same technology to get you unstuck.

When you’re maintaining or enhancing a large software system as part of a team, it’s not enough just to know the technology you’re working with. You also have to know the details of the specific system you’re working on. As I wrote a few weeks ago, that means you have to figure out how to learn from local experts.

If you have a general programming question, find the answer on Stack Overflow, and later forget the answer, you can always find it again. I do that all the time. But if you forget an answer that you got from a local expert, you have to go back to that expert to get it again. That’s an inefficient use of a scarce resource, and it might make your expert grumpy. You want to make the best use of your local experts or, if you’re the expert, ensure that others make the best of your time. You can do that using the skill I’ll be exploring today.

« Continue »

There’s a certain kind of programming problem that you won’t find the solution to on Stack Overflow, programming blogs, or even an old-fashioned paper book. It’s the kind of problem that is, to use an old Stack Overflow term, too localized. Imagine you’re working on a software team and you encounter one of the following situations:

• You run a local build (without changing any local files), and it fails.
• You’re working on a feature, and you need to know how to simulate a credit card payment for your product, without actually submitting a credit card.
• You’re about to submit a database schema change, and you want to test the database upgrade process the way it will actually work in the shared test environment and on the live system.

There are a few ways you could potentially solve these problems. You can always use the old standby technique of Googling keywords and seeing if you can match the general results with the specific needs of your project. That may get you some interesting options, but it’s likely to require a lot of work.

If your team has good internal documentation with a search function that works, then you may be in luck. If you can find documentation about the exact scenario you’re looking for, then you’re even luckier. Keeping internal documentation is a good practice for any software team, but it does require discipline. Stack Overflow is even trying to encourage team documentation (as long as the team is willing to publish it to the world) with their teams feature.

When Google and internal documentation fail, there’s still one more thing you can try: ask a local expert. Here are a few tips on doing that effectively.

« Continue »

“The relationship between deep work and collaboration is tricky,” writes Cal Newport in his recent book on focused productivity. That’s for sure. The goal of deep work is to expand your cognitive abilities in a distraction-free working environment. But many people don’t work alone. And as anyone who has worked on a team can attest, co-workers can be a source of distraction. How can we reconcile deep work goals with the need for collaboration?

« Continue »

To find a job you love, you can start by considering your career values, what specific job is compatible with those values, and what skills you need to do well at that job.

If you already have the job you want, you still need to decide what you want to work on. The job description that you might have perused before applying for the job could tell you something. For a programming job, that might include technologies you’ll be using, background you should have, and a general idea of the product you’ll be working on. But within those general boundaries, you have some control over your daily work. That allows you to customize a general job description to fit exactly what you want to do.

« Continue »

Over the past couple of weeks, I have been writing about software careers, including career values and characteristics of a good programming job. This week: types of skills used in a programming job.

« Continue »