I’m distilling what I’ve learned from almost 40 years of job hunting and interviewing, both as a candidate and as an interviewer. I have experience with programming jobs both in and out of the tech industry, and 10 years freelancing.
My experience ranges from big companies to startups. Big employers will have a more defined process (and it will prove harder to bypass). Smaller companies and startups generally follow a less formal hiring process.
Starting the job search
Posting résumés (or CVs) online and sending out lots of emails may help with the numbers game, and if you have in-demand skills it can’t hurt to get your name out. In most cases a more targeted approach works better.
- Identify companies you want to work for.
- Learn as much as you can about them.
- Use your contacts to give you leads.
- Work with recruiters if necessary, but only with someone you feel comfortable with.
- If you live physically close to the company try to meet people who work there. Go to local meetups and user’s group meetings employees might attend.
- Ask all of your friends and professional contacts if they know someone at the company. I’ve hung around offices at lunchtime and approached people at nearby delis, asking if they work at the target company, and if I can join them. Don’t stalk employees, but there’s nothing wrong with asking people about the place they work — people usually like talking about themselves.
I have been freelancing as a remote developer for over ten years. I specialize in legacy systems and taking over abandoned and unfinished software projects. I see the problems customers have hiring and working with freelance developers. Here’s my advice for avoiding some of the potholes.
Here’s a list of things I know, or at least know about, as a web developer. I’m sure I’ve left a lot of things out. Web development is a large and complex collection of technologies, tools, languages, protocols, and services. I started programming for the web back in 1995, so I’ve been able to adapt to changes and learn new tools as they were released. If I had to learn web development from scratch today I’m sure it would take me a long time to master even a few of these things.
I was asked today on Twitter about how to find work as a digital nomad. My comments are too long for a Twitter reply and may be interesting to people who don’t follow me on Twitter, so here goes.
I’ve worked on big projects, small projects, in huge teams and by myself, in fossilized federal agencies and cool Silicon Valley companies. I have learned and used at least twenty programming languages. I’ve lived through waterfall/BDUF (big design up front), structured programming, top-down, bottom-up, modular design, components, agile, Scrum, extreme, TDD, OOP, rapid prototyping, RAD, and probably others I’ve forgotten about. I’m not convinced any of these things work.
I get paid to take on technical debt. In my work I see a lot of hard-to-maintain code, and I see many of the same avoidable problems over and over.
I specialize in debugging, fixing, maintaining, and extending legacy software systems. My typical client has a web site or internal application that works, more or less, but the original developer isn’t available. Business requirements have changed and the software hasn’t kept up. Or my client has something that is “almost finished” but they parted ways with the developer after using up their budget and schedule. Usually there’s a list of missing features and bugs.
In my career as a programmer I’ve seen lots of projects go off the rails because of strict adherence to some practice, rule, or fashion. It may be something the entire team has bought into, like OOP or TDD. It may be something a single member of the team bullies everyone else about, like tabs vs. spaces or braces style. Even a programmer working alone can sabotage a project by honoring fetishes above productivity.
I’m your next potential dream boss. I run a cool, rapidly growing company in the digital field, where the work is interesting and rewarding. But I’ve got to be honest about some unfortunate news: I’m probably not going to hire you. … If you want to survive in this economy, you’d be well-advised to learn how to speak computer code.
— Kirk McDonald, president of PubMatic, writing in the Wall Street Journal, 10 May 2013
This is another article beating the “everyone must learn to code” drum. Employers can’t find enough people with programming skills, schools aren’t turning out enough engineers, jobs at these cool companies are left unfilled because American students are too lazy or short-sighted to spend a summer learning “basic computer language.”
If only it was that simple. I have some complaints about this “everyone must code” movement, and Mr. McDonald’s article gives me a starting point because he touched on so many of them.
Programmers love to optimize their code and their tools. Why then is there so much slow and bloated code and so many arcane and fragile tool chains? Because programmers aren’t always optimizing for efficiency. There are many things programmers can optimize for, and a team can quickly end up working at cross purposes when everyone is optimizing for something different. Here are just a few of the things programmers optimize for: