Here, in no particular order, are some things I learned in my career so far as a software developer. Really wish I’d known these before graduating. Hopefully it will help someone else!

Recruiters

The field is currently dominated by recruiters and staffing agencies. Applying directly for roles, especially with larger companies, often gets you nowhere. On the other hand, uploading your resume on popular job sites (LinkedIn is king) will open the floodgates. Keeping track of all the recruiters you work with seems like a good idea, but it will quickly turn into a full time job.

Keep a Spreadsheet

Keep a spreadsheet with the following columns: Company Name, Address, Job Name, Contract (Yes / No), Requisition Number (if you can get it), Rate / Salary, Recruiter Name, Date Of Submission, Interview Dates, and Notes. Don’t add a new row unless you’ve actually been submitted for a specific job. (Recruiters often refer to this as “being presented” to the hiring manager.) This will keep the spreadsheet from exploding, which in turn will make you less likely to give up on it. (If a recruiter isn’t able to give you a requisition number for a role, then at the very least get the exact job title and hiring manager.)

Keeping a spreadsheet will also save you from being submitted multiple times for the same job, which will absolutely disqualify you from the running.

The Good, the Bad, and the Ugly

Speaking of recruiters, try to stick to local ones. I realize there are exceptions, but most out-of-town recruiters are amateur one-person operations that don’t exactly have your best interests in mind. Try to establish relationships with staffing agencies instead of chasing down individual job leads. Go out to coffee with recruiters. Certainly have a phone call with them if they are out of town. You will be able to tell right away if they’re for real.

I can’t tell you how many times I’ve had a recruiter tell me they are not a used car salesperson. This is exactly what they are. They will promise you the world one day, and then drop you for weeks. Most will eventually come back around, but keep your expectations in check—they’re in this for the money just as much as you are, and they’re juggling as many developers as you are jobs.

The Job Description

Most recruiters only have a surface understanding of coding languages and frameworks. Be patient with them. When in doubt, go to the job description. In the end, your resume is what should define the ground rules of the interview.

Speaking of which, never agree to be submitted for a role until you receive a job description for that role. JDs usually contain technical specifics that the recruiter may or may not understand. If a particular job description doesn’t seem like a good fit, the recruiter may explain that the hiring manager knows this and simply hasn’t had time to correct or update it.

Remember, recruiters are incentivized to get you hired. They won’t knowingly steer you in a bad direction. (The key here is knowingly.) If you wind up in a situation like the one described above, just be sure to bring it up during the interview. (“I noticed you’re looking for developers with skill X, which I don’t have yet”, etc.) This type of thing is usually easily smoothed over if the hiring manager knows what they’re doing.

Your Resume

I like to include a section at the top of my resume that outlines the tools and languages I know, divided up into categories of expertise:

• Strong: Agile, Java, JUnit, Mockito, REST / micro-services, Maven, Gradle, Spring, GIT
• Moderate: SQL, Hibernate, JavaScript, JQuery, Jenkins, Groovy
• Room to grow: Dev-Ops, Cloud, Docker, Angular, React

I’ll then list the specific tools and frameworks I used at the bottom of each job description, so the hiring manager can clearly see exactly where I learned and used those skills listed at the top of my resume.

The Clients

Most staffing agencies won’t reveal who their client is up front. Sometimes they don’t even know where their client’s offices are. Be prepared for this, and don’t be shy to ask. Many will tell you who their client is once they establish a rapport. This can make targeting a particular geographic area difficult, so tell your recruiter early on where you live and how far you’re willing to commute for a job, or whether you prefer to work remote.

Offers

Never, ever tell a recruiter if you’ve received an offer that you haven’t yet accepted, let alone how much and from whom. Most recruiters will keep this information to themselves, but I learned the hard way that this isn’t always the case. If pressed, simply say, “I haven’t accepted any offers at this point.” (Notice it’s accepted and not received.) Recruiters aren’t naive; they know you’re likely working leads that they don’t know about, and you’re within your rights to be coy about those leads.

Don’t even mention if you’re close to an offer. This can scare off skittish hiring managers. Play your cards close to the chest.

Once you’ve actually accepted an offer, then of course tell the world! Your recruiters will want to know that they can take you off their radar for now.

---

The Interview

Never discuss salary during an interview. If pressed, simply refer to the current market rate for a developer with your level of experience. Hiring managers know what that number is. (If you don’t know this, you can gauge it by asking various recruiters what they think you’re worth, taking the average, and subtracting 10%.)

Never ask a client about overtime, working remote, PTO, bonuses, etc—use the recruiter for those kinds of questions.

Do your homework. Don’t just go to the client’s website. Go to Wikipedia, Google them, search news articles, and so on. Find out as much as you can. This will save you from applying for companies to which you might have moral objections, companies drowning in bad press, or companies in the middle of a merger or acquisition (usually a very bad sign).

Coding Exercises

Many hiring managers will ask you to perform a coding exercise as part of the interview process. This is a very common practice, but by no means universal, and often takes different forms. I’ve made the personal decision not to pursue job leads that require 3rd-party tech screenings because I find that I crack easily under pressure, and anyway it doesn’t accurately reflect the coding experience. Most coders don’t think at 400 MPH while they work. In fact, writing code as fast as you can tends to lead to poorly written code, and I don’t want to work on a team that has poorly written code.

In these situations I tell the recruiter that I’m more than happy to whiteboard a coding exercise with the hiring team during the interview. That way we can work out the problem together, and they can see how I think. (I’m careful to always think out loud while doing this.) This takes away the pressure to write code that compiles and passes all tests within minutes, a ridiculous bar to set in any circumstance. If a hiring manager wants to see code of mine that compiles and passes all tests, I’ll refer them to my most recent GitHub project.

You’ll have to decide where you stand on this. Some devs thrive on coding exercises; I’m just not one of them. I do recommend this book if you want to become a coding exercise jujitsu master.

The Office Vibe

Pay close attention to the facial expressions and body language of the people you meet when you go in for an interview. If everyone looks miserable (including the HR rep who walks you from the front desk to the conference room), you might want to reconsider.

The Scope of Your Expertise

Clearly outline your area of expertise during interviews. Be excited to learn new things, but ask if the hiring manager is willing to invest time and money to train you if needed. Some hiring managers don’t have a firm grip on which coding frameworks are “akin to” others, and assume that once we know one we must know all. Gently correct them if they get this wrong.

Grill your future employer on the kind of work you’ll be doing. Don’t accept hand waving or generalizations—insist on specifics. What are the specifics of the tech stack? What kind of application is it? What’s an example of a recent story they’ve played? Drill the engineers on this—hard. What are the best things about maintaining the apps on their team? What are the worst? What particular skills are essential to get the work done?

---

Compensation

Stick to Your Target

Only tell the recruiter your target salary or rate, never the hiring manager. (This holds true for external and internal company recruiters.) Never give a salary range. It’s my experience that if you do that, the offer will come in at the bottom of that range. Figure out an actual target number, be brave, and stick to it.

Fuck Bonuses

Completely disregard bonuses when considering an offer. Bonus money isn’t real money. It’s taxed at a higher rate, subject to company and team performance, and often comes much, much later than you expect. If your target salary is $(X)k and the offer comes in at $(X – 5)k plus a 5% annual bonus, you’re getting screwed. Stick to your target salary.

Escalating Salaries

There is something akin to a compensation staircase in the software world. It levels off after about a decade, but for the first few years it tends to go something like this:

• developers with 0-2 years of experience fetch a salary of about (X)k,
• developers with 3-5 years of experience fetch a salary of about (X + 15)k;
• developers with 5-8 years of experience fetch a salary of about (X + 30)k;
• and so on.

That’s an insane incentive structure, but it’s the reality of the tech world at the moment. The point is that every few years you’re going to be woefully underpaid, and there will be an army of recruiters dying to tell you just this. Be prepared to switch jobs every few years until you level off. (A very important caveat: more money does not necessarily mean a better job. If you love your job, like really love it, then it might not make sense to leave it for an additional $10k a year. There are a lot of horrible jobs out there.)

Hourly / Annual Conversions

There are roughly 2080 working hours in a year, but be careful when converting from an annual salary with benefits to an hourly contract rate. Always divide an annual salary with benefits by 1800 instead of 2080 when converting to hourly. Remember, you’ll need to pay for your own healthcare, holidays, and personal time off. Contrariwise, multiply an hourly wage by 1800 to see what it might translate to an annual salary with benefits. #LearnFromMyFail

---

Languages and Frameworks

Know that if you stick to legacy languages you will probably wind up working on legacy applications. As of 2016 this is starting to include Java, but certainly there are a few new Java projects out there. Be sure to ask during interviews how old the tech stack is. If it’s more than 10 years old (certainly more than 15), you should be prepared for nearly vertical learning curves and dead zones that no one knows how to maintain.

On the flip side, startups and companies that have only been around for a few years might have bleeding edge code to burn, but the success rates for companies like this are pretty abysmal even when the economy isn’t in a tech bubble. Don’t dive into a situation like this unless you’re young and energetic, extremely passionate about what the company does, and willing to work around the clock to help it succeed.

Version Control

Teams do use Subversion and other VC tools, but GIT is the Coke to everyone else’s Pepsi. Get familiar with the basics of GIT command line arguments. And by the way, use the command line whenever you can. If you have an option to use either a UI plugin or the terminal, use the terminal.

---

Testing

Unit, integration, functional (manual and automated), acceptance, smoke, and end-to-end. Become a master of the first two, read up on the others. Familiarize yourself with test path coverage tools. Most IDEs have them built-in.

Introduce yourself to the world of mocking and stubbing. Read up on Mockito, and try a few of the more common exercises at home. The learning curve for mocking is steep but short, and it’ll save you hours of work in the future.

---

Agile vs Waterfall

By now most companies are either using Agile or some form of it. Companies in old-school industries like finance and insurance are usually Waterfall with a thin Agile shell. Read up on these two methodologies, but spend a bit more time reading up on Agile and Scrum. Know the ceremonies and how all the mechanics work together.

Don’t freak out if you’re given stories with empty or very sparse requirements. Sadly it’s a very common practice. It’s actually an invitation to sit down with the B.A. and clarify the acceptance criteria.

If I get stuck on a story, I leave a comment on that story explaining why I’m stuck and what I’m doing to get unstuck. Then every day I’ll come back and leave another comment until I get unstuck, and what I did to escalate the situation. I’ll also bring this up in the daily standups. Yes, this is ass coverage, but no one likes an uncovered ass when the music stops.

---

“Business Knowledge”

If you find you have no idea how to actually run part of an application, the Q.A. team is a great resource for workflows and test data. This is all they do every day, so they know where all the bodies are hidden, so to speak.

Wiki or Confluence pages are great. All teams have them, but they’re usually pretty sprawling and badly organized. Ask other devs which ones they actually use, and be wary of ones that are more than a year old. Once you find the good ones, read them!

I keep a personal wiki. I write down stuff I get tired of looking up over and over again. If I get stuck on something non-story-related (like getting some tool or platform to work), I’ll document my journey and show how I got unstuck. If it feels relevant to the rest of the team, I’ll put it on the wiki too.

Most new developers are given another developer to shadow. My advice is to seek out the most recent addition to the team. That person is going to be a font of useful knowledge for you!

---

Groking

Yes, to grok is a real thing. It usually takes me a while to understand a piece of code that I didn’t write. I have to be alone with it for a while. I’ll run it, test it, break it, stare at it, poke at it. Some people can do this much faster. Don’t be alarmed if this comes slowly to you too. It’s OK to take a couple of hours and just stare at a piece of code by yourself until the lights come on.

(This, by the way, is one of the main reasons why I don’t do timed, 3rd-party coding exercises. Even Einstein once asked someone to explain a new concept to him slowly because he “understood slowly”. This should not be penalized!)

---

Meetings / Time Management

Easily two-thirds of the software developer’s work life is spent either in meetings or on Slack. When this starts to take over your life — and it will — don’t hesitate to block lunch and “focusing“ meetings on your calendar. No one will fault you for trying to do the work you’ve signed up to do.

Speaking of which, don’t volunteer to work more than 40 hours a week unless it’s for a special occasion. You probably won’t impress anyone, and you’ll give the impression that you’re able to do more than you actually can in a 40 hour week. Plus you’ll burn out like super fast.