Reader questions: Software Development Job Search from Quantitative Background

A Notre Dame alum reached out to me recently about switching to software development from a quantitative background. My response seemed like they'd be of general interest, so please use it for good, not evil.

---

In the job search in general, the task is to match what a company needs and wants with what you have done and what you can do. Your task is to make that mapping as clear as possible throughout the process. The resume gets you the phone screen. The phone screen gets you the interview. The interview gets you the job. The best person for the job doesn't necessarily get the job; the person who is best at getting the job gets the job.

1)  How do you think I should pitch myself in my resume / cover letter to software companies?  How can I play down the fact that I have no work experience with "real" languages (e.g. Java / C++).

In my book, any Turing-complete language is a "real" language--anything from writing expense report software in Java to writing Tetris in Brainfuck. To me there seems to be an anecdotal inverse correlation (whatever that means) between demanding proficiency in a particular language and the quality of a company's software.

Amazon, Google, Microsoft, Facebook, etc. will all let you solve interview problems in the language with which you're the most comfortable. Even if the language is esoteric (e.g. Haskell (don't actually try to solve interview problems in Brainfuck)), if you can explain how your code works and runtime characteristics like big-O memory and runtime performance then you should be just fine.

So how do you play down your hipster programming language work experience and real language academic experience in a cover letter? Just don't bring it up. There's no template for a cover letter. You have experience in legitimate programming languages and your coding and problem-solving skills will be assessed interactively anyway. Map what you've done and what you can do to what the company's needs and wants.

2)  How helpful would it be to start taking on Python/Java projects on GitHub?  I've heard that showing people that you're a "doer" makes a really big difference in marketing yourself.

Project experience is always impressive. Any opportunity you have to hyperlink your resume to something you've built is worth taking advantage of. Each hyperlink is an incarnation of the mapping between what you've done and what the company needs or wants (in the most general sense, it shows you have written code that does something).

Contributing to existing projects also mirrors what you'll do on the job. Very rarely do you start on a new system from scratch, and when you do the new system becomes an existing system after only a few months.

Finally, contributing to projects is a great way to learn a new language and see how it's used in practice. A good project will show good habits not only for the code itself, but for the code's organization and tests. This will also expose you to a lot of bad habits (which you can also learn from: if a stanza of code seems to make no sense, it's probably poorly written. Once you figure out what the code is actually doing, think about which language features could have made the code more readable) and get you used to setting up development environments and getting new code running.

Now for the flip side: Contributing to a project is a time investment. It's easy to get over-committed in life, so get a handle for what you can include in your routine and live within your time budget. The most helpful thing I've done on this front this year was to start using a to-do list app. Many of the benefits I just attributed to contributing to a project on GitHub are accessible by merely browsing the source code on GitHub. You have to decide whether to prioritize the additional work of contributing a patch (or just forking your own branch) in return for a compelling work sample. Having such a link isn't a prerequisite by any means, but it's definitely a boost.

3)  Let's assume I don't have the legendary skills / experience required by tech firms like Amazon/Google.  What are some examples of tier-2 tech firms that are known / respected?  I feel like I might have a shot at firms that aren't quite as good as Amazon.

I'm a bad person to answer this question since my tech career started with a summer internship at Johnson & Johnson followed by full-time at Microsoft followed by full-time at Amazon. I probably have a big head about it.

There's a range of consulting firms, smaller tech companies, companies that specialize in mobile development, high-frequency trading firms, startups, and contractor agencies outside of the megacorporation world. There are also large companies and various government agencies that do some in-house software development.

If I were good at answering this question, I'd be able to give the pros and cons for working at each, as well as what they're looking for and how to prepare. If you insist on preparing for not being good enough (wow, I definitely have a big head), I recommend researching some specific example companies for these categories. Employees at these companies will have better answers for the pros and cons of where they are.

No matter where you go, your first goal is always to make yourself as awesome as possible. It's easy to take jobs as a proxy for self-worth, and it's okay to be proud of where you work, but don't let where you work define your identity. When I got my offer from Microsoft senior year of college I'd felt that I had made it. Being smart and achieving was a big part of my identity, and my employment by Microsoft was a nice encapsulation of my achievements and sacrifices. I had a view of myself as a Microsoft employee. It defined my identity. The problem was I wasn't happy with my work there. Deciding to look around for other jobs was very liberating: First I saw that my team was bigger than my role, then that Microsoft was bigger than my team, then that the software industry was bigger than Microsoft, then that the world was bigger than the software industry. When I went from Microsoft to Amazon I also went from thinking of myself as an SDET who works for a great company to a great SDET who happens to work for Amazon (and I friggin' love Amazon). I'm an SDE at Amazon now, but the principle holds: I'm a sharp guy with a lot going on who happens to work for Amazon as an SDE (a fitting incarnation of such awesomeness (there's that big head again)).

Goal setting

I love Amazon. I love my team. You have to push yourself. If you’re hitting more than 70% of your goals for the year, you’ll get scolded for not pushing yourself enough. It’s an interesting rule of thumb and I love how that contributes to challenging ourselves constantly.

How about this: The first year on the job, commit to goals of a certain value. Maybe even hit these 100%, you sandbagger. Next year, commit to delivering double the value. Hopefully now you’re in the 70% zone. For the next year, commit to delivering double that 70% value (140%). 

You should hit about 70% of that value (we’re at 1.4 * .7 = 2 * .7 * .7 = .98). .98 / .7 = is a 40% year/year growth in the value you can deliver, which makes sense in your first few years at a company between early ramp-up and increasing ROI from early tool development. 

If you’re automating anything repetitive, if you’re constantly soliciting customer feedback, you’ll be working much faster on more of the right things. Since 6/7 of software projects fail and the #1 reason for project failure is building the wrong thing, you won’t be doing 1.4x the work every year but you may still yield 1.4x the value. And if you can do that, nobody cares if your actual effort increases. J

Drop the T already

Which T? This T:

The title of Software Development Engineer in Test arose when Microsoft saw a need to have more technical staff involved in testing software than the Software Test Engineer (STE) army it maintained. Managers and recruiters lured candidates to these open positions with assurances that, while there might not be as much coding in these roles as an Software Development Engineer (SDE) would have, SDETs really are just SDEs on the Test team. Some teams got the memo and actually used their SDETs as SDEs on the test team. Others changed their STEs' titles to SDET and told them to learn to code. Others simply changed their STEs' titles to SDET.

Microsoft and Amazon maintain that hiring guidelines for technical skills for SDEs and SDETs are identical. There is an entire discipline devoted to software testing (STEs/Quality Assurance Engineers (QAEs)), so SDETs are expected to master that job as well as their own. This is somehow seen as special, even though SDEs should become very familiar with the business domain of the products they product anyway.

In spite of having an identical coding bar on paper, seeing SDETs as second-class developers is still the rule rather than the exception. This is true wherever SDETs are not expected to deliver as much functionality through building software as their SDE peers, which is also the rule rather than the exception. That SDET you hired in part because he could code at the SDE level? He won't be nearly as valuable to your company in three years if you don't support him in his efforts to add value through building software.

Software Testing/QA teams provide specific services for the products they support. Some of those services, (e.g. tooling, automated test suite creation and maintenance, integration testing libraries to export to other teams, load testing) require good software developers. Developing test plans, traversing exploratory testing checklists, designing test passes to maximize ROI, filing and advocating for bugs and communicating a level of risk assessment with a software product are important disciplines, but they don't require the high computer science technical bar that large software companies demand of SDET job candidates.

Expectations for SDETs don't just vary from company to company; they even very within large companies such as Microsoft and Amazon. Everyone knows that SDEs write code and that SDEs at Microsoft/Amazon/Google/Facebook need to be really good at writing code. They don't know what to expect from candidates with SDET experience.

Your smartest, most valuable SDETs are keenly aware of when their technical skills are growing and when they are not. Your smartest, most valuable SDETs are so smart and so valuable not just because they have talent but because they have spent countless hours perfecting their arts of software development, software testing and software project management. Your smartest, most valuable SDETs will fight tooth and nail to protect these investments in themselves and in their careers, and your smartest, most valuable SDETs will not have any trouble finding employment on teams that can promise the growth they desperately need. And even your smartest, most valuable SDETs need this growth, and need it especially, or else your smartest, most valuable SDETs will fail to measure up against either their QAE or SDE peers since they are spending less than half of their time in one of those roles.

Think about how you treat your SDET interns. SDET internship projects are almost always tool development SDE projects. This is both because you want the intern to have a positive experience and because current full-time SDETs are too bogged down in project delivery (test planning, test plan execution, test plan result reporting, regression test failure troubleshooting) to write tools that would help themselves and their peers. I've seen it over an over again: Teams recognize the need for a tool, think of it as an "intern project" and recruit for the summer while they continue to support customer-facing projects. The summer intern is a sharp kid and delivers a working version of a tool that looks great in the demo. Demand for the tool spikes since the team was correct when they identified the need, and the intern's toy becomes a valuable asset to the team. The problem is that while the tool works as a proof-of-concept, the implementation is awful and the tool needs to be refactored or rewritten to address future needs. "Maybe that's a good project for next summer's intern."

At the end of the day you've lost a valuable technical growth opportunity for your best SDETs who are dying to write more code for you as their job, you've tricked an intern into thinking that SDETs really are just SDEs on the test team (which they should be if you're going to title them SDEs in Test) and you've racked up technical debt with a bunch of rookie mistakes embedded into your new business-critical tool. Any gains you make in the space of a full-time hire for next year will evaporate as the former intern realizes that he liked his internship because he was an SDE, not an SDET and seeks employment elsewhere.

Drop the T for your team's sake. Look at each of your directs. Give them a choice. If their expertise has focused mainly on test planning and how to find the highest-severity bugs in the shortest time possible, they will benefit in a prestige-enhanced QAE or STE role. If they can't measure up as SDEs then they need to know now. If you, as a QA manager, run a team that doesn't have enough value to add through building software, you need to know now, and the SDE+QAE bastardization that is the SDET job title only adds chaos and confusion to the mix. You don't need SDETs; you need QAEs and SDEs on the test team.

A tale of two software career paths

Software can be the best of careers, it can be the worse of careers. It's up to you.

Path 1: Write sensibly-designed software, resilient to change, on a fast update loop. You aggressively squish bugs, of which you have fewer than do your peers because of your unit tests. You talk to people early and often. Work isn't killing you, so you have time to learn stuff--cool stuff that improves your designs, makes them more fault-tolerant or speeds your update loop. You can take on more responsibilities as your services take care of themselves and process is automated away. There's a lot more work up-front, but your tech improvements keep paying huge dividends. You have the option of decreasing your workload even as responsibilities increase. Increasing responsibilities increases your visibility, influence and rewards. You're a star individual contributor. What you do matters. You learn enough about corporate politics to magnify the influence you have from your technical prestige. You're good at that, but do you understand business? You have a nonzero risk of becoming part of The Problem at your company. If you're The Problem now, that's fine. You're a star IC, we're happy to have you.

Path 2: Continually accepting one-off shortcuts to deliver the task at hand. You deliver results fast, or you don't have to work as hard at the beginning, or you don't know how to squeeze in long-term improvements. You get into constant Fire Drill mode. Work is exhausting you. You don't have time to learn anything cool or try anything new. Extra responsibilities are punishments. You fear them. You're stuck working nights and weekends to keep your head above water for things that shouldn't be that tough. Your projects aren't important. You become very political to compensate for an inability to deliver. You're good at that, but do you understand technology? You have a nonzero risk of becoming part of The Problem at your company. If you're The Problem now, try again somewhere else and try to be more like that #1 guy.

Engineers Needed

The world needs engineers and science-types. If you're not needed in your current role, find a way to move to where you are. The world is bigger than your team, bigger than your company, even bigger than your city.

After decades and decades of the world shrinking due to technology, it's time to sit back and reflect that the world is still a pretty large and exciting place that needs people who can do what you do. Polish up that resume and get out there.