All Articles

From the Military into Software Engineering (2/5): The Hustle

Finding the Right Roles

  1. Engineer or Manager (and which specific title)?

    A common question for transitioning military is which side of that line to start on. A military resume often speaks strongly to managing roles, but after years of useless safety briefings and counseling statements, you may just want to get on the keyboard. Know that this is a two-way door: many managers start off as individual contributors, which can make them more competent and respected software managers.

    What’s more is that there are multiple steps on this keyboard - whiteboard spectrum: technical program managers and product managers fit somewhere in the middle, as managers of process rather than people.

    What’s the difference? Imagine a Product X that’s looking to launch Feature Y. It might work like this:

    • The product/program manager sets the timeline for the feature’s milestones: to beta on Day N, released to public on day M, etc. It’s the product manager that reports up to directors/higher management, and who coordinates with other stakeholders and among teams.
    • The software development manager, leading a team, is tasked with realizing that goal. Knowing her/his engineers, s/he divides up the work, checks in on them, and provides more resources where necessary. This manager uses whatever project management philosophy is trending, leading sprints etc.
    • The engineers, being different ranks/experiences, focus on different work items. They often coordinate directly amongst each other, without the manager, in meetings, code-reviews, and shoulder-taps.
    • The infrastructure on which this product and feature are deployed, maintained, tested, etc. is maintained by systems engineers, who are explicitly operations-focused, and/or by DevOps engineers, who are multifunctional developers who also operate their product.

    All of the jobs above are called different things at different companies:

    • Software Developers, devs, are the focus of and have all the many titles listed there. Folks who can sling code but generally aren’t expected to Linux.
    • DevOps == Systems Reliability Engineers (SREs) == Systems Development Engineers (sysdev) == Folks who are expected to code decently and Linux decently. Note that at some companies, like Amazon, devs are themselves expected to operate their products, blurring the lines between the two.
    • Systems Engineers focus on daily operations. Similar to a SysAdmin role.
    • Support Engineers are customer-focused, and know enough about operations and infrastructure to solve common issues or escalate to another engineer.

    Note that engineers at the same level but in a different role may earn drastically different salaries.

    Beyond that, the different ranks/levels will play different parts:

    • Entry-level engineers might take an issue off of the queue/sprint board, ask another engineer for advice, then submit a code review to the team when complete.
    • Mid-level engineers will work more independently and on bigger-scope pieces of the product.
    • Senior engineers might build the overall API, and will evaluate and accept/reject work by lower levels. Management will generally defer to their technical judgment.

    Even in my limited experience, it seems that managers can have wildly varying levels of technical skill, from being the most capable and confident engineer of the team, to entry-level equivalent and relying more on people skills. Both models seemed to fit their specific environments well.

  2. Big Tech, Lean Startup, or In Between?

    There are some great perspectives about this online. The best I’ve read, and one that holds up after trying out both options, is by Dan Luu.

    Big Tech is comfortable, pays more, and carries weight on a resume, but mobility is slow and hard, and you won’t strike early-Google riches. You may be able to focus on one particular feature or field, and possibly do research or push boundaries, but you’re just as likely to get parked in a boring role pushing buttons for The Man.

    In a startup, you may fill multiple roles and your pace of learning may be much faster, and if you’re lucky you’ll ride a wave of growth to riches and a prestigious role…or the company will go under and you’ll have to go and try it again.

    Many people bounce back and forth to enjoy the experiences of both and end up well-rounded.

    I would offer this advice:

    • If you’re leaving the military because of pay, location, wearing a uniform, waking up early, or similar things, but generally like the structure and the way that people work together, Big Tech may be perfect for you, because it shares that hierarchy and mentality in many ways.
    • If you’re leaving the military because you don’t like its control over your life, the many, many meetings, its slow-moving processes, and the daily non-sensical decisions forced upon you, then you may not like the structure of Big Tech, and should look to a smaller firm at first.

    Of course, there are big differences between even the most rigid company and the military, and among firms. This is a generalization.

    FWIW, in retrospect, I poorly estimated the structure and pace of Big Tech work, and would have been happier at a startup at first.

  3. Which Company Do I Want to Work For?

    This is a complex one. In retrospect, I would use these criteria in order:

    1. The people you will work with daily (possibly also the people interviewing you). Are they motivated? Friendly? Competent? Are you going to learn things from them? What are their backgrounds? Startup folks will be very different from prior federal contractors. Tech people from traditional businesses will have a different mindset from tech-company veterans.
    2. Technical culture and software tooling: this was one I didn’t consider at all when I was last hired, but it affects your life quality on a daily basis in engineering. Does the company use and try out open source tooling? When a polished solution already exists, do they use it or try to recreate their own? If there is no solution, do engineers have the freedom to experiment? What cultural weight do they place on software quality? Do tools continue to be supported after the fun of prototyping is over?
    3. Work culture of the company as a whole, best found on Blind, Glassdoor, Quora, etc. Just like, the truth is somewhere between the 1-star and 5-star reviews.
    4. Quality of life: what kind of hours are expected? How often and how stressful are on-call rotations?
    5. Room for growth: you may quickly realize this isn’t the right role, level, or team for you. Is there room to move up and around? Is your team and company growing? It’s much easier to move up when everyone is moving up.
    6. Office environment: if you care about ping-pong tables, quiet workspaces/phone booths, a rooftop, or an open bar, you can find those.

The Job Hunt

  1. Take Your Time

    It may feel like a rush to get a job and get paid/be useful again - but you’re only going to make this transition once. Your resume won’t be what my companies and interviewers expect for an engineering role, but many will give you the benefit of the doubt as you leave the service. Once you’ve settled into the civilian world, you’re in the same line for promotion as everyone else. You get to define your own starting point.

  2. Rank and Performance Reviews Mean Nothing

    For some, that will be a disappointment. For others, that should be hugely empowering. A friend of a friend left the service as a lieutenant colonel and was dismayed to only receive offers at the college graduate level. The fact that you were responsible for X people, Y dollars, and Z vehicles means little here. No one cares about or will even ask for your performance reviews. The fact that you are a veteran, and possibly a combat veteran, is as far as they’ll be interested to know.

    …That being said, you probably have some pretty sweet stories, and interviewers love stories, especially those that differentiate you. More on that shortly.

  3. The Best Time to Get Promoted? When You’re Hired!

    Don’t sell yourself short - interview for any role you’re interested in, continue interviewing until you get turned down enough, and grow into the best role you’re offered. Don’t assume you have to start at the lowest level, and don’t spring for the first offer you get. You likely won’t be able to exit and re-enter the company at a higher role, and will have to climb the ladder at the same time as everyone else, which is a lot more work and time than just interviewing better.

  4. Personal Connections are Best

    You’ve probably already heard that referred candidates are far more likely to be hired than those applying through online services or email. But beyond just getting hired, those personal connections are likely to line you up for a better job, too.

    Take a certain big tech company. If you apply to a recruiter or otherwise through the front door, you get lined up to interview with the teams that need someone the most. Could that be because they’re doing awesome work and are growing super fast? Maybe. It’s more likely that they either (a) do mundane work they can’t interest other internal hires in or (b) can’t retain their own people and are backfilling. If a personal connection inside the company can give you the scoop, and line you up for a team that s/he knows does work you’d like, you’re more likely to enjoy the job you get.

  5. Know the Engineer Levels Big Tech follows a pattern here: entry-level jobs for college grads; mid-level jobs for competent developers; higher level jobs for architects at increasing scale.

    On top of this, pay will also be graduated based on job type/title: a software development engineer will make more than a systems engineer of the same level, who may make more than a solutions architect, and so on.

    At least one engineer on your interview loop is responsible for “leveling” you within your role. When you receive an offer, make sure you understand what level that is.

    While named/numbered levels is a familiar concept to you, there are a couple differences from the military:

    • A level-5 in one job role may make more money than a level-7 in a different one.
    • Moving between ranks can be much simpler, given you impress the right people. Company culture drives the timeline here, but it’s nowhere as rigid as the military’s promotion timelines.


Cracking the Coding Interview (CTCI) is written to address exactly this topic, with perspectives on all the big tech firms. Having read it both before and after my own experience, I can’t recommend this book enough. I won’t duplicate her advice, but can share a few more things I saw along the way.

  1. CTCI focuses on software engineering (read: algorithms) questions only. If you’re looking for a DevOps or Systems role, you’ll need to know different things:

    • Software development jobs will be coding and algorithms
    • Systems Engineers will have to answer trivia about protocols, standards, kernel internals, etc.
    • DevOps candidates will face a mix of these two: Linux (Bash) and Windows scripting, sysadmin tasks, and (simpler) coding

    The intent is to measure your general breadth, depth, and exposure to knowledge in your chosen domain.

  2. Drive the Narrative: Tell Your Story

    Interviewing candidates is not a full-time job. Different companies incentivize it different ways, but it’s safe to say that interviewers often have some deadline or project they’d rather be working on at that moment. What does that mean for you? Don’t get back on your heels, just responding to questions and fending off that feeling of incompetence; take control, drive the interview. Find reasons to tell the stories you want to tell. If you’re being grilled on a topic you don’t know well, move the conversation towards something you do, or at the very least tell stories about how you didn’t know thing X in the past but two weeks later you were a pro and everyone loved you for it.

    I had one interviewer completely focus on those stories for almost all of a 45-minute interview (it was supposed to be about a different topic), and found later he gave a two-thumbs-up review. Not to mention, it was also more relaxing than being grilled about systems design.

  3. Take Credit

    I kept being reminded in interview prep, and at least once in an interview, to stop talking about “We did…” and instead talk about “I did…” That feels weird to military people, especially former leaders, but at companies where they care about individual competence, they want to know that you yourself are actually capable of things and not just riding a wave of success.

  4. The Loop

    A common pattern begins with a preliminary phone screen of an hour or less, which the company/team will use to filter out long shots and keep the team from wasting time on a full interview loop. Candidates who pass the phone screen will be invited on-site for an all-day ‘loop’ of about 6 interviews. Each interviewer is tasked with evaluating some different part of your technical ability and fit for the job, and all will be evaluating your personality.

    6 interviews? Yes. Interviewing for a role is a full-day gig. One of those may be an informal lunch break, alongside another interviewer. At my company, at least, that is not an evaluated interview (barring any red flags), so you can relax and ask questions but still focus on making a good personal impression.

    One of the interviewers is the hiring manager, whose opinion is the most important of anyone in the loop. How much more important depends on her/his management style. S/he should be upfront about being in that role or it should otherwise be obvious.

    How do they make their decision? I’ve only seen a 4-point scale, from ‘strongly decline’ to ‘strongly incline’, with interviewers recording feedback and voting individually before discussing amongst themselves. Generally, you can survive a ‘decline’ but not a ‘strongly decline’, and if you get all ‘inclined’, you still might not get hired. Impress at least one person who will fight for you!

  5. The Interview Goes Both Ways

    This is common advice, but if you’re suffering from impostor syndrome, it is pretty hard to take to heart. Evaluate the team that’s interviewing you - even if you pitch perfectly and get the offer, it’s really up to you to know if it’s a good fit. See the next part for some tips on making that decision.

    There are some yellow/red flags to watch out for, which might be explainable but also might be a sign of things to come:

    • Interviewers significantly late, or completely unprepared, or complete no-shows (is this how they respect one another?)
    • Interviewers who haven’t read your resume or other similar materials you provide (are they just looking for bodies?)
    • Taking you out to lunch but not picking up the bill (do they invest in their people?)
    • Interview questions that are all over the board (does this team even know what it focuses on?)
    • Your level of expertise is above interviewers on most subjects (Employees should never be interviewing for a role above theirs - so these people will be your managers and mentors. Should they be?)
  6. Questions to Ask

    Have some questions written down, since interviewer should give you at least a couple minutes to ask questions back. This is:

    • A chance to evaluate the role and culture. As above, you’re the best judge of whether you’d fit.
    • Another chance to show your chops on things you know well

    A good starting point:

    • Tech stack: while you should already have an idea going in, it may vary even team-to-team within a company. If the company uses multiple languages, ask which one they prefer.
    • Code cleanliness: team conventions, linters, testing requirements, etc
    • Ongoing education: conference attendance, travel, open-source contributions
    • What is onboarding/training like? If there’s no good, ready answer for this, and this isn’t a tiny company - run away!
    • What will my first project be?
    • What are the oncall rotations like? How often, how long, is return to the office required, how frequent are high-severity issues? No answer is “wrong” here, just something to keep in mind given your lifestyle
    • My favorite, for managers: what does the model employee look like to you? This one says so much about the company and their own leadership style. While they may try to hedge words carefully to give you the answer you want, there’s no perfect right answer on this one.

    It’s best to save questions about time off, extenuating life circumstances, remote work, etc until after you receive an offer.


You may get a “Thanks, but…” email or call from the hiring manager or recruiter. That’s not the end of the story, though.

  1. Get Feedback

    You may be very disappointed, but don’t show it too much. Ask for any feedback the interviewer can provide. They have access to all the notes of your interviews and the reasons for the decision. They may say “we can’t,” but they should be able to at least give a high-level impression like “your theory is great but your coding needs work.”

  2. Move Laterally

    Ask if the recruiter can suggest any other positions there they would recommend. At this point, you may actually be able to skip the phone screen and go right for another interview loop. Make sure you ask about the differences between the two roles, to make sure you prepare for the right thing.

  3. Retry

    You may be eligible to retry just for the same role, either immediately with a different team, or after some waiting period. The waiting period is a function of how much you missed the bar at the interview. At maximum, should be 6 months, which would translate to a desire for you to get the experience of a different job in the meantime.

But that won’t happen to you! You’re going to ace it.

Next: Evaluating Your Offer

Published Feb 24, 2019

Are you sure this wasn't written by AI?