Do I really want to work at a tech company?

If you’ve been on Blind or any other work chat platform, then you’ve heard the acronym “FAANG.” It stands for Facebook Apple AmazoN Google and it represents what are supposed to be the top-tier companies in terms of talent and compensation. Of course there are many other companies that have stellar reputations and also pay well. Netflix is a great example of that. In general, though, FAANG is supposed to represent the top employers. The best workplace you could possibly enter as an engineer.

Is that true?

To say these companies are influential in the tech space is like saying black holes tend to move stuff around. When Amazon starts pushing for serverless application development, I can guarantee you that a couple months from now a developer at Mutual Of Generic Insurance is going to have his director leaning over his cube wall asking if they can do it, too.

Nowhere do we see this influence present itself more than in the hiring process. Entire books have been written which aid software engineers in their quest for employment, which centers around the real-life quiz show called the coding interview. In theory, it’s sound. These FAANG companies hire the best and brightest. If other companies want the same results, they need to follow suit.

On the Engineer’s side of things, the FAANG companies then become a type of gold standard in their various niche. Google is famous, for example, for beautiful campuses and providing chef-catered meals free of charge. I’ve been there. Everything you’ve heard is true and it really is that awesome. Amazon has a reputation for paying a little less attention to frills, but compensating well instead.

No matter where your inclinations lie, one of these companies is supposedly the place to be. Engineers will practice for months at at time to get their foot in the door of one of these companies. I know I did. Why wouldn’t they? Getting to work with the best and the brightest and being well paid for it, too. Who wouldn’t want that?

Well, maybe you. That’s who.

I’d like to give an honest account of my experience working at both enterprise development shops and working for technology companies. As a disclaimer, these are huge companies and experience can vary vastly depending on the products you work on, who you work for, etc. My goal is to provide people with a little more information before they commit to that new job.

Tech Company Claims

You’ll work with the most talented engineers in the world.

Tech companies have some very intelligent people working for them. After all, they did survive hours of interrogation about data structures, algorithms, and possibly system design. To be blunt, the downside of working with world-class talent are the world-class egos that come with it.

I wouldn’t describe the working environment of tech companies as collaborative, I’d characterize it as combative. Every decision you make will be scrutinized by your peers. Every code review will have at least one drawn out argument about something as trivial as variable names. Every meeting will be dominated by those with the loudest voices and the least concern for the opinion and expertise of others.

Some people thrive in these environments. They suit up and jump in. Others do not. Despite the popular opinion in tech companies that this is somehow beneficial to quality products, my experience has been otherwise. Regardless, ask yourself if you can realistically handle this on a day-to-day basis.

They are committed to their employees and will compensate you better than anyone else.

Commitment is something these companies use as a marketing statement as much any other employer does. Recruiters and managers like to talk about the passion their people have for their product, or how they’re like a family, but the fact is that if the share price is on the line your job will be on the chopping block faster than you can say “right sizing.” That’s universal to all large companies in the U.S.

Compensation is far better at tech companies than it is at enterprise development shops, in my experience. The health plans will be better. Your base pay will be higher. They will offer Restricted Stock Units and sign on bonuses. If we’re all being honest about why we do what we do (to make money) this is a prime motivator to come work for one.

You will be working in a true meritocracy.

To be fair, I think that some people truly believe this. I don’t. For one, I’m not sure how a meritocracy of ideas is possible in an objective sense. Someone, somewhere has to make the choice of what ideas are best. Even if it’s a group of someones the criteria is ultimately up to people who can be influenced by more than objective data.

Many tech companies want their decision making processes to be objective and data-driven. To an extent, this is true. Decision makers will actively look for this information when green lighting any new projects. However, the claim that the best ideas always win is simply not true.

As the old saying goes, the figures don’t lie, but liars always figure. Like most companies, tech companies often fall into the same traps of relying on how information is presented and who is presenting it. I have personally witnessed rational, fact-based ideas get sidelined simply because the engineer involved didn’t have the public speaking skills necessary to win over their audience.

That being said, tech companies at least try to be data driven and proactive, whereas enterprise dev shops tend to make decisions solely on budget concerns and networking.

You are going to be working a lot of hours.

Oddly, this isn’t always the case. From what I’ve seen it varies greatly by what product you support and the attitude of your management. If I had to average it all out though, I would say that it’s about even. No kidding.

What I’ve seen is that at enterprise dev shops you often spend unnecessary hours pulled into supporting applications that are running on an increasingly precarious stack of scripts and band-aid code because there’s no room in the budget to spend time on code quality refactors.

On the other hand, at tech companies you tend to have more stable products, but will regularly get pulled into death marches in order to meet deadlines for launching new features and products.

It’s a bit of “six of one, half a dozen of another” situation. While you’ll be spending time on different problems, you’re still going to working through your mother-in-law’s birthday party at some point.

It is incredibly cutthroat.

This is absolutely true. However, it doesn’t let some enterprise dev shops off the hook, either. Performance evaluation tools such as stacked ranking which are still in use by many large, non-tech companies basically guarantee that networking will be more important than your actual achievements.

Remember what I said early about world-class egos? This is part of the problem at tech companies. Debates get hot, everyone will believe they alone are better than their peers, and competition for promotions will get fierce. But you’re on a team right? It’s not like any your fellow engineers are going to take your manager out to lunch and slip in some comments about how concerned they are about your project, right?

Big promotions bring big money. When money is on the line, anything seems to go. An unfortunate corollary to this is that many tech companies will push engineers out if they don’t advance quickly enough. Taken together this leads to a fairly toxic environment.

Enterprise Development Claims

You will have a better work-life balance.

Completely untrue. As I wrote above, you’ll find that working as a developer for NotMe Shoes can demand just as much of your time as Google did. At which point you may really start missing the free catered lunches.

Which isn’t to say that there aren’t jobs which will require less of your time. There absolutely are, but they tend to be less “technical” which means you won’t be coding as much (or at all) and may find your skills in danger of atrophying.

Companies love to say they care about your work life balance and mental health. They don’t. They never have, and never will.

Work on stable projects instead of vapor-ware and POCs.

I’ve worked on new and exciting projects in my enterprise dev time that didn’t make it to see the light of day (budget, it always comes down to budget) so I can tell you that this happens there, too. But it does happen less often.

That being said, I’ve found this is true. If you’re a DBA for BigBoy Pharmaceuticals, that team probably isn’t getting decommissioned any time soon. I once had a leader who told me that if you’re after job security, your best bet is to work on a product that is core to the company needs. You’ll find a lot of these core teams at non-tech companies.

You won’t have to work as hard (no one says this directly).

Not true. It’s just a matter of what you spend your work hours doing.

At a tech company you may spend hours of your day analyzing application performance, peer-reviewing code, or requirement gathering with your product team. At an enterprise shop, you may swap some of those hours for meetings with senior leaders and contractors, or simply filling out TPS reports. But you definitely won’t be sitting around idle. For some engineers, this sort of non-tech work is soul crushing and they run screaming from it.

No one with any real skill is going to be working at Mutual of Generic Insurance Company.

To prove all doves are not white, you only need to find one black dove. In that sense, this is demonstrably untrue. However, the spirit of comments like this is really the idea that anyone worth their salt would be at a tech company making them Benjamins.

This is also untrue. Here’s what I have found. There are many smart people working for non-tech companies like Coffee Giant, Inc. Some simply like their jobs. Maybe they have a personality that doesn’t mesh well with the ultra-competitive nature of the tech companies and they know it. Maybe they have a family and don’t want to live in the Bay or Seattle where the cost living is frankly, fucking stupid. There are reasons.

Here’s the caveat. Yes, you will occasionally get a coworker who doesn’t pull their weight as well as others. That’s life. My experience has been that this isn’t too different from what you’ll deal with at tech companies, though. It just happens for different reasons. At an enterprise dev shop you may get a coworker who doesn’t do well because they are incapable of doing better. At a tech company, you may get a coworker who doesn’t contribute as much because they feel the work is beneath them or is being done ‘wrong’ and they want to spend time debating it rather than working their fucking user-story. Overall, I feel the slack an average engineer will have to pick up is about the same in both cases.

Another point to consider which is definitely a negative on the enterprise side: Reliance on contracted developers. This is a whole article in itself, but the gist of it is that you will never work with more unqualified programmers than the ones your VP just brought in from some contract agency because they were cheap and throwing labor at a problem always solves it, right? In this sense, the above claim is actually true.

You will be drowning in red tape.

Yes. God, yes. So much yes.

You will have reports for your reports. Preplanning meetings for your planning meetings. Timesheets which must completed to a precision that German watchmakers would call unnecessary. I can tell you horror stories about one-line code changes that literally had to wait for a month to deploy for no other reason that “that was the process.” You will be lost in a labyrinth of ticketing systems run by teams in undisclosed locations, and woe be to those who do not know the secret codes and speak the words of conjuration necessary to find their requests approved.

Weary travelers you have been warned.

Overall

Like so much in life, the best place for you to be depends entirely on you. Do you thrive on debate or do you prefer a quieter life? Is money everything to you? Are you okay living in a high-cost of living area?

What I’d like to impress is that in my experience, no one type of employer is objectively better than the other. They all have flaws. Don’t let anyone tell you different.

No job is going to be perfect. But, there’s no reason to make our lives harder than they need to be by shoehorning ourselves into jobs that don’t really suit us. I hope that some of my insight is helpful to someone, somewhere who is looking at making a career change or is coming out of school and looking at their options.

Get a new job.

Listen, there are tons of blogs and articles out there with clickbaity titles promising you “Ten easy steps to survive a workaholic boss!” But I’m here to tell you that they’re all bullshit. You’re options are to: A) Get a new job at different company, or, B) Get a new job at the same company.

The point of this post isn’t to give you coping strategies, it’s to reassure you of what you already suspect – that old chestnut told to the family and friends of addicts is true. You can’t change other people. When those people are in charge of your career, it’s time to jump ship (or at least transfer to a different part of the crew).

Here are some assumptions: You, like me, are decidedly not a workaholic. If you are, you wouldn’t give a single shit about this advice, and probably curse those of us who do as “weak” or somehow less dedicated than you are. Of course you are correct. Workaholics are the best employees and managers. Please move on.

Now that we can speak freely, you may be wondering why my advice in this area is so black and white, when I’m normally a guy who sees things in many shades and colors. The short answer is that my opinion is borne of experience, having been supervised by workaholics many times in the past. I want to explain why I feel so strongly about this.

First, let’s talk about what a workaholic boss is. Not textbook definitions or anything, forget the psychology for now. Here are some signs that your manager lives, eats, and shits work, and expects you to do the same:

• Messages/calls at all hours of the day and night
• Does not respect weekends or planned vacations
• Views a regular workday as the bare minimum
• Every unit of work constitutes an emergency
• Consistently underestimates work and over-commits their team
• Lack of respect for personal space
• Disparages employees who can’t do unplanned weekend work due to previous plans

If you’ve found yourself nodding, or having flashbacks, while reading this list, then you know who you work for. I won’t go into detailed explanations of each bullet. If you read and feel it, then you know what I’m talking about.

Not every workaholic is a dickhead or a soulless monster. In fact, some of the worst offenders can be very personable. In a way, this is even more dangerous, as you find your life slowly being consumed by your employer. I know that sounds a bit dramatic, but hear me out for a minute.

Stop what you’re doing and take three deep breaths. Look around you and acknowledge a simple fact. You will never get this moment back. Time, once past, does not come again. You will never be as young as you are in this moment. Many of us in this field are young, or young-ish. I am middle-aged (shudder) and I can tell you for a fact that each year will fly by faster than the one before it. My friends have been dying off since I was a teenager, as have my family. You will never get this time back. You will never get your loved ones back once they are gone.

Don’t waste your precious fucking life on a goddamned job.

The company you work for does not care about you. They don’t. The larger the company, the truer this statement is. If you work for a small, ten-person startup, you and your team may genuinely care about each other. But as your company grows, new leadership will come, and they will not care. If you work for a mid-sized company with great benefits and an awesome culture, have no doubt that as the company expands, those benefits will get whittled away as the board of directors nickel and dime their way to a better share price. I don’t care where you work. You are an asset. You are a number. Treat your employment like the business arrangement it is. You employer sure as hell will.

Your boss is a workaholic for reasons known only to them. You won’t change their mind. Any advice you find on this subject will be more geared toward how you can better deal with them. Sure, if you’re stuck where you are for whatever reason, then coping is your best shot. If you’re not glued to your chair? GTFO. What I found is that we, the employees of workaholics, get caught in a sunk-cost fallacy of sorts. We’ve put so much work into the product and spent so much time with our team, that even though we grumble about getting our resumes ready when we’re sucked into (yet another) death march to meet an impossible deadline, we still don’t leave. Why?

We care about our work. We don’t want to be seen as disloyal. That’s what it usually boils down to.

You can take pride in your work, go above and beyond, and do right by your team without becoming an automaton. You can do all of these things and still get off of work at a decent time and enjoy your weekends, even planning a vacation every now and again. You can. The curse of being employed by a workaholic is that these goals are made to seem mutually exclusive. In fact, I would argue that a person who you are paying to think (an engineer) is better suited to their job when well-rested and emotionally stable.

Your job is not your life. Nor should it be. Do your best. Be proud of what you produce. But, don’t waste your precious fucking life on a goddamned job.

Cheeky title aside, this post is about a topic that weighs heavily on me, both as a person who does occasionally look for a new job, and as a senior developer who routinely interviews prospective coworkers.

I’ve been a part of many interview loops across several organizations (as a candidate and interviewer), and I can say one thing for certain: We can do better.

This isn’t to downplay how devilishly tricky it is come up with an interview process that uniformly, across the board, will always flush out the best talent. It’s a bitch. And if companies like Google, Facebook, and Netflix still don’t feel like they’ve got it completely right, that should highlight just how difficult it is.

Gaining a developer who is technically gifted, gets along great with the team, and communicates effectively is like striking gold. In fact, I think getting a hundred percent hit on all of those qualities is basically impossible. To borrow from an overused visual aid (this author is stealing from Datastax’s DB consistency graph), it’s almost as though we have a triangle with three points, each representing one of the following qualities: Technical Skills, Culture Fit, Communication and Soft Skills. Every one of us lands somewhere in this triangle, but by virtue of its shape, we can never quite reach the maximum potential of all three.

You may not agree with that, but, hang with me, because I think this is part of the reason why hiring is so difficult. We enter into the hiring process saying we want “the best” candidate without defining what that means, or, without seriously considering what that means in context of the vacancies we’re trying to fill.

For example, if you already have a team of super-genius coders with strong personalities who disagree constantly with each other, do you really want to add another person just like this to the mix? Or do you need an engineer with excellent soft skills to bridge the gaps and get the project moving forward again?

I want to share an anecdote, with identities and situations changed for my protection.

Once upon a time, a growing product team needed more engineering talent. The team had an engineer who had went through an exhaustive architectural review process with his senior leadership, and it was time to write some code. What the situation truly called for was a couple of mid-level developers with good technical skills, solid experience, and great teamwork. People who could work together on implementing the architecture together, with direction from the senior engineers.

What the hiring process provided, however, was another two senior-level engineers, described by those in the interview loop as “Rockstars.” Engineer A spent most of his time arguing with others about the approved architecture rather than writing code. Engineer B was more interested in getting into a rest-and-vest situation, constantly looking outside of his product team for work which he could claim was stealing his time from actual development.

This isn’t to say that A and B were bad engineers. They simply weren’t right for the roles they were put in. A may have been well-suited to work on a greenfield project where he would have more say in the design. B may have been better in an architecture or consulting role at an enterprise dev shop. The end result was a lot of wasted time and money for two hires who should have been helping propel the product over the finish line, but actually dragged it down and caused further delays.

So what went wrong? This is the question we should be asking ourselves when these situations occur, and occur they do. Asking this of myself repeatedly has led to some insights, which I hope would prove useful to other engineering teams.

Given that needs will vary based on role, my observations are that the following practices tend do more harm than good:

• Spray and Pray Hiring
• Inconsistent Standards Among Interviewers
• Skipping Interviewer Training
• Lack of Focus or Goal for Vacancies
• Groupthink
• Creating a Clone Army

Spray and Pray

To borrow a term from my time in the Army, Spray and Pray was a euphemism for laying down suppressive fire. Or, shooting toward the enemy, not caring if you hit anything, just to keep them from moving. In the best case, it let your team advance. In the worst, it kept things at a standstill.

The hiring equivalent to indiscriminately dumping rounds downrange is job advertisements that don’t actually map up to a specific role, coupled with a cookie-cutter interview loop. We are looking for a generic engineer, and we will submit you through all of the generic engineer interview processes. Can you identify the complexity of this algorithm? Can you solve this coding test? You’re in.

This hiring methodology takes none of the specific skills of the candidate into consideration. It’s a tempting approach, especially from an HR perspective, as it makes the process well-documented, defensible, and reproducible.

An antidote to this is to introduce interviews as part of your loop which are designed to flush out the qualities you need for the role. If a candidate got through the technical screening just fine and you need a great communicator, why not focus on that for an hour instead of seeing how well they can solve (yet another) HackerRank challenge. Ask the behavioral questions, give them hypotheticals, ask them to explain a difficult topic.

Inconsistent Standards Among Interviewers

This overlaps a bit with skipping training, because some of these issues could be weeded out with training. Some.

Inconsistencies abound during interview loops. It’s to be expected, really, that we all value different qualities in a candidate. The important thing is to be clear about what you are looking out for, and your grading standards. So at the end of the loop, when everyone involved is on that final assessment call, we can be clear about how each interviewer made their decision.

An example of this would be how we administer coding tests. I’ve worked with engineers who cared only about the final outcome of the coding test. Did their solution work, or not? I, however, disagree with this approach, and feel the exercise is more about seeing how a person thinks rather than how quickly they can hack together a solution to FizzBuzz. Maybe they only solved it quickly because they’d done the problem before. Maybe they only struggled because they were nervous and missed a step, but their approach was basically solid. We need to pay attention to these things.

Skipping Interviewer Training

How many of us have started a new position and within a month found ourselves already conducting interviews? I’m guessing most of us. It’s nuts, right? Sure, I suppose there are interviewing fundamentals that transfer across companies; the legal stuff, mostly. But how are you supposed to fairly and accurately evaluate a candidate according to the company standard, when you don’t even know what that standard is?

A friend of mine from college told me about how after starting his first job as a senior-level engineer, he was put in this situation. His manager sent him a link to the HR interview training documents. Most of which were outdated, and none had anything specific to say about how a technical interview loop should be conducted. When he asked his manager for guidance, he was told to use his best judgement. Full stop. As you can imagine, their hiring process was a mess, where no one could seem to agree on anything, and management continually found themselves staffed with new engineers who didn’t fit in well with the team.

Groupthink

It takes a strong personality to stand up to another strong personality. Also, the motivation to do so. It’s this second part that fails over time.

At a previous job, I noticed a trend emerging at the end of each interview loop. One or two of the most outspoken managers would provide their assessment of a candidate, often speaking for much longer than their allotted time. At the end of their pontification, the rest of the votes would almost unanimously fall in line with their decision. Even if I knew for a fact other interviewers had felt differently coming in to the meeting, they’d change their vote to match the loudest voice in the room.

Why? It was something I was even guilty of a time or two. Why did I change my vote? Why did others change theirs?

After one of the candidates I really liked didn’t make the cut (and I was the lone voice speaking up for them) I decided to do a little digging. I talked to a friend of mine who I knew was also going to vote for the candidate before the meeting. “Why did you change your mind?” I asked him.

“There’s no point in arguing with that guy,” he said.

And so it goes. As in so many aspects of life, the strong personalities who refuse to give ground will find a way to brow-beat dissenting opinions into submission. Not by the strength of their arguments, but by sheer persistence.

Creating a Clone Army

Another common trap is the tendency some people have to want replicas of themselves to join the team. In a way, I get it. We all want to work with other people who share our opinions and laugh at the same jokes, but, in reality there really is strength in diverse viewpoints and skillsets.

A team of engineers with diverse skillsets and favorite focus areas will only strengthen your product by increasing the overall breadth and depth of the team’s combined experience. If you’ve got a five-person team who all specialize in Rest API design, versus a five-person team consisting of people who respectively specialize in Rest API design, multi-threading, data-modeling, microservice frameworks, and architecture – which team is going to get a better product out faster?

I once sat as co-pilot on an interview where our team’s director grilled a candidate for an hour about threads and locks. It wasn’t a helpful interview strategy, but the director stuck with it simply because that was his wheelhouse and he wanted to be an expert. But what use would it have been to hire a developer after only testing them on one area of knowledge? Our primary product wasn’t even a multi-threaded application. His default tactic resulted in hires that had the same area of expertise as him. It wasn’t helpful.

In Summary

Like many complex issues, there’s no silver bullet here. If experience is any guide, however, hiring gets a lot more effective when we take the time to honestly evaluate what we’re doing an why, while keeping a sharp on who it is we need to fill that empty desk. I hope that some of these observations will prove useful to someone out there.

In a previous job, I was part of a campus recruiting team. What that meant was that on a regular basis the company recruiters would reach out to me and ask for my help at some campus event or convention. Meet and greet the students about to graduate, assess their skills from a brief convo, take resumes, and sometimes hold on-site interviews. My dev manager at the time would grumble about losing me for half a day, but ultimately it looked good on the team if we offered people up for these kinds of things, so it was a normal part of my responsibilities.

Surprisingly, I noticed a question from the candidates that popped up more commonly than others: “What’s it like?”

Not, what was it like working at the specific company I was representing, but the career as a whole. What’s it like to be a software developer/engineer? What do you actually do all day? What’s the office like? How stressful is it? When did you actually get to contribute code? How much were you expected to know out of the gate?

These are all good questions. I found that answering them one by one usually didn’t provide much satisfaction to the people asking them. What I realized is that they were actually looking for a more holistic description of the early stages of a career in software. They were nervous, unsure of themselves and how they’d perform doing this job that they just spent four years trying to earn. In essence, they were me just a few years prior. Another commonality I noticed with most of the people asking is that they were starting out much like I did – blind to the industry. No friends or family who currently worked for tech companies, no internships, etc. It was all bewilderingly new.

Answering that holistic question isn’t exactly easy, because there are so many variables. But, I’ll give it a whack here, just like I did for those candidates.

Getting Hired

This is often the trickiest part to generalize. How hiring is conducted at the dev shop in an insurance company versus how Google hires its engineers is night and day. There are some common threads though, so here are few important takeaways.

Prepare, Prepare, Prepare

I wish I would’ve known just how much this matters when I graduated. Listen, I know you’ve been doing nothing but taking classes and coding assignments for the past four years. I get it. But that doesn’t mean you’re prepared to complete a coding interview well enough to get hired over other qualified graduates. It’s like this, if you were to compete as a sprinter in a track and field competition, you wouldn’t say, “Oh, I’ve been doing distance running for years, so I’m good.” You wouldn’t take that attitude because it would set you up for failure. Sprinting and distance running are similar in some respects, but the differences become more pronounced as the competition becomes fiercer. It’s the same concept here. Just because you got an A in your Algorithms class doesn’t mean you’ll be ready to nail a whiteboard coding problem.

This isn’t meant to be a post about coding interview prep. In brief, I’d say to start by checking out resources like Gayle Lackmann McDowell’s Cracking the Coding Interview. Take it seriously. Prepare for the interview like you’d prepare for a final.

Soft Skills Do Matter

By nature, I’m an introvert. Over the years I’ve worked hard to break out of my shell and put myself “out there.” Frankly, it’s fucking exhausting. But, I do it. And if you want to make a good show of it, you’ll have to as well.

Your ability to code, to be an engineer, is important, no doubt. But don’t underestimate how important you present yourself is during the hiring process. I’m not saying this to make you nervous, or to tell you that you need to be someone you’re not. What I’m saying is that this first impression with your interviewers will be your one and only chance to show them why they should pick you over other candidates. And here’s a secret from the other side of the interview table – it’s not always the person with the best tech skills that gets the offer.

You’ll hear a term bandied about these days: Culture Fit. What people really mean when they say this is, “Would I want to work with this person?” Because most of the time, the people interviewing you are going to be working right alongside you through feature development, bugfixes, and late-night death marches. For my money, if it’s a choice between a competent dev who seems easy to work with versus a super-genius who rubs everyone the wrong way, I’m going to go with the easygoing dev every single time.

That may sound strange when we’ve all had this image presented to us that the tech world is dominated by stubborn geniuses. My experience as a dev and a tech lead, however, is that a dev with a bad personality is going to reduce the productivity of a team far more than they enhance it. Pointless arguments, the need to always be right, the drain on morale, lack of collaboration, these things kill a team’s throughput and cohesiveness.

If you know that you have a tendency to be a bit of dickhead, my advice is to work on it. Even if you don’t give a flip about your teammates or the company’s product, think about your career. I once had boss who said to me, “You can be well liked, or great at your job. One of the other will keep you employed. Do both, and the sky’s the limit for you.”

Unfortunately, It’s Not a Meritocracy

This is a little bit of a downer, but I feel the need to say it, because it can affect a person’s morale when they first get out there and look for a job. Being the best and the brightest doesn’t guarantee you a fair shake at job. I’m just being a realist. If the last open position came between you and a Senior Vice President’s kid, guess who’s getting the shaft? Sorry. I wish it wasn’t like that. But I’ve seen it too many times to pretend otherwise. Nepotism, favoritism, whatever name you want to give to the homey-hook-up, it’s alive and well.

I say this because I don’t want you to lose heart if your job search takes longer than those new graduates who are already well connected. You can and will make it in. Trust yourself and keep at it.

Know the Market

This bit is important. When I graduated, the economy was terrible. Most non-tech companies had outsourced almost all of their development work to off-shore companies. Tech companies had slowed hiring and raised the bar of entry very high. At the time, Google wouldn’t even talk to a new grad unless they had a Ph.D. or maybe a Masters. For a young applicant looking for work, the pickins, they were slim, and most of had to take what we could get rather than the jobs we had hoped for.

Knowing the market when you’re job hunting is just as important as when you’re house hunting. With real estate, the trend of market forces leaning in favor of buyers or sellers drastically affects home value. It’s the same thing in the job market. If the demand for developers is high, you will have more options for employment and you can negotiate better compensation. You can afford to keep your options open a little longer and go for the job of dreams.

If it’s turned the other way, as it was for me, you’ll need to adjust your expectations in the reverse. You may have to take a lower salary, a less appealing position, or work for a company you’d rather not. We have to roll with the times, but being aware of market forces allows you to ride the current as best as possible. The goal is to get the best possible job without overplaying your hand and not getting any offers at all.

Communicating Experience (even if you think you have none)

We’ve all seen the ridiculous job advertisements: Wanted – entry level developer. Requirements – three years experience.

It’s so frustrating to see that when you’re looking for your first job. Take a breath, and let’s walk through this, because it’s really not as bad as it sounds.

Most job advertisements are not written by engineers or engineering managers. They’re written by folks in human resources offices, who often have a lot of legal requirements to contend with. That’s why they can be a little confusing and obtuse.

I can’t speak for every company, but at every company I’ve worked for, the HR folks screening applications and resumes will count your years at school as experience. So if you see an ad with that kind of poor wording, take heart. You most likely still qualify.

The follow up I heard once I told prospective candidates this bit was, “But what if I really don’t have any real experience? All I’ve been is a student. I haven’t had any internships or anything.”

That’s okay. My guess is that you’ve got more experience than you realize. This sort of goes back to soft skills. How would you best present what you have done as real experience? Think about the projects you’ve worked on in college. That huge team project where you and your teammates learned how to write a compiler, for example. What were the pain points, what did it teach you? These don’t even have to be technical lessons that you learned. What did being a team leader teach out about leadership? Did you have a teammate who didn’t pull their weight (of course you did, we all did) and how did you deal with it?

When you think about your time in college in terms of lessons learned rather than classes taken, you’ll see that you did gain a lot of valuable experience.

When The Dream Job is Just a Dream

This is a bit of a hard pill to swallow, but you might not get the job you’ve been dreaming about these past four years. For one reason or another you didn’t get it. Maybe they weren’t hiring new grads. Maybe your GPA was too low to get an interview. Maybe you had an interview and it just didn’t go well. These things happen.

Most of life is, in the words of a Colonel I once worked for, “Taking chicken shit and making chicken salad.” Disappointments happen. The important thing is to not give up, because things can always get better.

When I graduated, I didn’t get the tech job I wanted. Hell, I didn’t even get a job at a tech company. I landed a dev gig for a lowball salary at a non-tech company, and many of my classmates didn’t even get that. A lot of them just went back for their Masters and hoped the market would get better. Well, it did.

The silver lining here is that you don’t get just one chance to get a job at Apple, Google, or at HipGuyStartUp. If your GPA wasn’t great, don’t worry. Take the best offer you can and work hard. After you’ve got real work experience no one will even ask about your GPA. Just take it off your resume. If you didn’t do well on your interview, or if DreamCompany.com wasn’t hiring, follow the same advice. Work hard, learn everything you can at your less-than-ideal job. Make the most of it. Who knows, it may turn out better than you think. It did for me. While working for that non-tech company I met a lot of great people, and my enthusiasm and hard work opened up opportunities to work on new technologies that the company was piloting. In turn, that helped me move my career forward when it was time to move on.

Starting Your New Job

There’s a lot of trepidation about starting a new gig. I’m always a bundle of nerves when starting a new job, even more so when it was my first job out of college. Here are a few points that may help alleviate some of that stress.

No one expects you to be perfect. Unless your manager and senior devs are absolute butt nuggets, no one is going to expect you to be able to recite obscure algorithms off the top of your head, or start day one writing a new feature. A good team will make sure you get settled in, that you know who the senior devs are, that you know who to turn to for what, and they’ll start getting you familiar with the code base and how the team operates. The members of your new team should have a good idea of your skill level and should work with you accordingly. That’s not to say you won’t be pushed to learn and do more – expect that. Just, probably not on day one.

The length of time that it takes before your code is making it into production will vary based on company, team, and application. Facebook is famous for making devs commit code to production on day one. However, if you’ve been hired at a non-tech company to work on an incredibly complex and sensitive app that could lose the company big sums of money should it malfunction, you’ll probably be given a longer ramp up period. In short, it varies, but the expectation should be communicated during the hiring process. If it’s not, ask. That’s actually a pretty astute question to throw out to your interviewers.

First jobs in a new career field can be intimidating. But remember that they hired you for a reason. Ditch the Impostor Syndrome and come to work with an open mind and a willingness to learn.

When It’s Time to Move On

Tech has always had a high turnover. And one day, your first job will be just that – the first job of many. These days, with demand for devs being higher than the ready supply, it’s not uncommon for people to change jobs every year or two. There’s no blanket advice on when it’s time to move on. That’s a personal decision that everyone has to make. Some people get itchy feet after a year on the same team no matter where they work. Other guys have done thirty years working on the same Cobol app and have no plans on going anywhere.

Here’s my general advice about moving and when it’s probably time to go.

If you find that the work is no longer challenging and you’re often bored. This happens. You’ve been on the same team, working on the same product of a couple of years. You know the codebase back and forth. New features aren’t challenging you or teaching you new skills. Debugging is trivial. You’re in a cycle of break and fix, and it’s mind-numbing. Probably time to find a new job.

If you’re ready for a move up and your current team or company isn’t offering advancement. Surprisingly, with all the work companies do to recruit talent, many don’t seem too worried about retaining it. It’s not uncommon for a company to provide ‘entry level’ compensation to devs right out of college, then resist bringing them up to industry-standard pay after they’ve proven themselves ready for a promotion in a year or two. This baffles me. If a dev likes being there, and they’ve done well, why wouldn’t you pay them what they’re worth? Alas, if you hear excuses as to why your employer can’t pay you what you’re worth, that’s a good sign that it’s time to move on.

If you are generally unhappy. Do you dread going in to the office? Does coming to work require you to sit in the car and psyche yourself up for a few minutes? Have you started viewing the office as a prison? Terrible managers, lackluster facilities, awful commutes, these things matter and add up over time. Look, if you have the option to be happier somewhere else, then take it. You spend eight of your waking hours (at least) each day at your job. Don’t make them miserable hours.

The opportunity of your dreams is now available. Have you been applying to Google for years only to finally get hired and placed? Do you finally have enough experience under your belt to land that role at Netflix? Then go for it! Don’t hold yourself back.

Overall

Tech jobs, when you boil it down, are like most other jobs. You go to work, you do the best you can, eventually you leave for something new. The hiring process is a bit grueling, and the personalities are interesting, but the basic elements are the same as other industries. It’s not perfect. The jobs are desirable, currently, because the demand for our skillsets is outstripping the supply. The won’t always be the case, as it wasn’t in 2008, or in 2001. Doing well in any profession requires a person to try their best, never stop learning, and be a team player. Do that, and you’ll find yourself in a good place.