(Some Of) The Things They Don’t Teach You About Software Engineering In College

1x-1

 

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.

Thing #1

The field is currently dominated by recruiters and staffing agencies. Applying directly for roles (especially with larger companies) will usually get you nowhere. On the other hand, uploading your resume on popular job sites 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.

What you can do instead is keep a spreadsheet in your phone with the following columns: Company Name, Job Name, Requisition Number (if you can get it), Recruiter Name, Date Of Submission, and Notes. Don’t add a new row unless you’ve actually been submitted for a specific job—this will keep the spreadsheet from exploding, which in turn will make you less likely to give up on it.

The only columns that truly matter are the Company Name, Date, and Requisition #. This will save you the headache of multiple submissions, which will sometimes disqualify you from the running. It’s especially helpful for large companies that vacuum up developers in a local market—they often have a dozen or more staffing agencies and recruiters working for them, and it’s unrealistic to think you can keep track of it all.

So hang on to those req #s when you get submitted. If a recruiter doesn’t want to give you one, then politely decline to be submitted. (It can be difficult and awkward to get a recruiter to tell you once you’ve already been presented to their client.) If pressed, tell them you don’t wait to risk multiple submissions in case another recruiter wants to submit you to the same company somewhere down the road, which I can’t tell you how often this happens. They may offer a guarantee that no one else has the req under discussion, which may be acceptable.

Thing #2:

Speaking of recruiters, try to stick to local ones. I realize there are exceptions, but 9 out of 10 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 are for real.

Thing #3:

I can’t tell you how many times I’ve had a recruiter tell me he or she is not a used car salesperson. This is exactly what they are. They will promise you the world one day, and drop you the next. 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.

Be especially wary of roles that don’t don’t look like a good fit—I’ve had more than a few recruiters submit me for roles that they insist aren’t limited to any one particular job description, then finding myself in the embarrassing situation of an in-person interview for which I have no business applying. Don’t let them force a square peg into a round hole.

Thing #4:

Never discuss salary with a recruiter’s client. If pressed, give them a range, or simply tell them the current market range for a developer with your level of experience is acceptable.

Never ask a client about overtime, working from home, PTO, bonuses, etc—use the recruiter for these.

And of course, do your homework. Don’t just go to the client’s website (they are often useless piles of garbage that contain fancy CSS and a novel’s worth of industry buzzwords). Go to Wikipedia, Google them, search news articles. Find out as much as you can. This will save you from applying for companies to which you might have moral objections, or companies drowning in bad press.

Thing #5:

Recruiters don’t know code. They know some buzzwords, but that’s about it. I once had a recruiter ask me what kind of Java I worked on. When pressed, he said he meant “front end Java or back end Java”. (There is no such thing as the former.) Be patient with them—when in doubt, go back to the job description.

Speaking of which, never agree to be submitted for a role until you receive a comprehensive job description. These usually contain technical specifics that the recruiter may or may not understand.

Thing #6:

Many staffing agencies won’t tell you 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 once they get you on the phone and realize you’re not a crazy person. This can make targeting a particular geographic area difficult.

Most of the recruiters I’ve worked with have been more than happy to help me target a particular area or suburb, but many job boards don’t give a single clue as to who their clients are. This requires a phone conversation. Rapid-firing your resume at a job aggregator like ZipRecruiter can be frustrating because most of the time you’ll be applying for roles you’ve already applied for (or worse turned down), giving recruiters a bad impression.

Thing #7:

Refreshing your uploaded resume on most job websites like Dice and Monster will put your name back on the top of everyone’s desk. Don’t abuse this, but know about it. Helps to kick up some activity if things get dormant after a while.

Thing #8:

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 up front how old the application is during an interview. If it’s more than 10 years old (certainly more than 15), you should be prepared for nearly vertical learning curves. This is not always the case, but it certainly can be. Imagine the dozens of developers who’ve come and gone over those 10 or 15 years, all with their own ideas about coding standards and code reuse. After a decade an application will start to become insanely difficult to maintain. (Imagine too many ornaments on a Christmas tree.) Again, not always the case, but sometimes.

If you do wind up in a situation like this, don’t let your manager or team lead throw you around to different areas of the code every iteration—try to stick to one area and get to know it well. No one can expect to be a generalist right out of the gate. If they do, start looking for a different job—the last thing you want is to perpetually be at the bottom of the learning curve.

Thing #9:

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

Thing #10:

Once you’re hired, spend every minute of your downtime researching the application you’re working on. Don’t expect anyone to hold your hand and show you every detailed nuance of how it works. Find the documentation, and read as much as you can. Ask a senior developer or team lead to give you a list of concepts and technologies you must absolutely understand in order to successfully work on the application. Chances are very good you’re going to get tossed into a section of the application that deals with some hairy and difficult-to-conceptualize code, and you want to be ready for it.

Thing #11:

There is something akin to a compensation staircase for new graduates. It goes something like this: developers with 0-2 years of experience fetch a salary in the range of X. Developers with 3-5 years of experience fetch a salary of about X + 15k. 5-8 years gets X + 30k, and so on. This depends on what market you’re in, but the point is that every couple of years you’re going to be underpaid. I guess this is supposed to level off somewhere around year 8, but I don’t have any hard data or experience to back this up. Be prepared to switch jobs every couple of years.

Thing #12:

Always divide a potential salary by 1800 instead of 2080 when trying to convert an annual salary to an hourly one for W2 contract work—you’ll need to pay for your own healthcare and time off. (Contrariwise, multiply an hourly wage by 1800 to see what it might translate to on an annual basis.) Learn from my fail.

Thing #13:

Buy a suit and always wear it to in-person interviews. (Casual is fine for meeting the recruiter, but try to keep it at least semi-classy.) The life of a software developer might be a cushy one, but you don’t want something as stupid as showing up in ripped jeans and a tshirt that reads DON’T BRO ME UNTIL YOU KNOW ME to keep you from getting that dream job.

Thing #14:

Many hiring managers will ask you to perform a coding exercise as part of the interview process. This is common, but can also be a bit of a trap—especially if you’re not given the chance to defend your code. Good code, as strange as this may sound, can be incredibly subjective. I honestly don’t understand why hiring managers can’t just trust that you wouldn’t have been able to get through college, an internship, and your first few jobs without at least having a basic grip on the core concepts of software engineering, yet somehow this practice persists.

I recommend you don’t apply for jobs that require these. Instead, open a GitHub account and push a coding exercise to it. Make one up if you have to. Put your GitHub URL on your resume, and refer hiring managers to it if they want to see how you code and how you think. This may not be acceptable to all, but it might also weed out ridiculous practices like giving you two hours to implement a complex set of requirements to “see how far you get”. I once had a hiring manager ask me to write a program that plays hands of blackjack from scratch in two hours. Of course I only got a few hundred lines of code in, and was told by email that I “failed” the test, with absolutely no explanation. (In that case I believe I dodged a bullet.)

Some hiring managers will try to “stress test” you. I suspect this means they have a high-stress environment, and you want to ask yourself if you want a slice of that particular pie. If you politely decline to do one of these homework assignments, offer instead to come in and whiteboard your ideas with the team. This will give them a chance to see how you approach a problem, and what kinds of questions you ask. It’s my opinion that this gives potential employers way more of a window into your skill set than scrutinizing your code from afar like a bored king.

Also: Get this book.

Thing #15:

Pay close attention to the facial expressions and body language of the people you meet when you go in for an in-person interview. If everyone looks miserable (including the HR rep who walks you from the front desk to the conference room), you might want to tell your recruiter that you’d like to pass.

Thing #16:

Grill your future employer on the kind of work you’ll be doing. Don’t accept hand waving or generalizations—insist on specifics. Exactly what kind of code base is it, what kind of application is it, what do they expect you to do once you’re onboarded and oriented? Hiring managers like to waffle on this question, usually because they’re not too close to the code.

Drill the engineers on this. Hard. You might find out, for example, that you’ll be required to learn some proprietary or outdated language to do your work, in which case you should run for the hills. (Do you really want to spend a month taking classes on how to write mainframe code? Will that ever come in handy for future roles? I suppose maybe if you’re in banking. But you get the idea.)

It’s also very important that you also ask how the QA, BA, and UX teams interact. A huge red flag is if these are all done by the same people. Make sure there is a dedicated QA team and a dedicated UX team—engineers designing user experience and testing their own code gets you websites like the one your grandmother used to try to get you to visit in the late ‘90s. I’m not kidding about this—I used to work for a company that made software that was so impossible to understand from the user perspective, that they actually hired trainers to fly out to the client sites and teach the end users how to use the product. This is the exact opposite of what companies like Google and Apple do. Make sure you won’t be expected to test or design UX—it’s a sign of horribly incompetent management. Coders should code and that’s it. (One possible exception would be younger companies, but then you’re back in a situation where you’re probably working around the clock.)

Thing #17:

Never tell a recruiter if you’ve received an offer, let alone how much and from whom. Most recruiters will keep this information to themselves, but I recently discovered the hard way that this isn’t always necessarily so. If pressed, simply say, “I haven’t accepted any offers at this point.” Notice the phrase is accepted offers and not received offers. If pressed again, repeat it. “I haven’t accepted any offers at this point.” You will get pressed again. Keep repeating this. Practice saying it in the mirror. This is your business and no one else’s. Once you actually accept an offer, then of course tell the world.

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s