“Why can’t I get a job in tech???”

The Question

I get this question a lot from people just starting out in this industry, more so now with the rise of coding bootcamps and the glorification of being a developer, our infatuation with startups and entrepreneurism, and the rise of nerd culture. It seems there are more aspiring developers than ever before, which is good because there’s a global shortage in software engineers that seems to be growing. Unfortunately, companies are still having trouble filling their software engineering roles because everybody wants to hire the best software engineers, but the best software engineers only want to work for the best companies. This could be the topic of a future post, but you see the dilemma.

Here’s an anonymized question I just received in my LinkedIn inbox:

“Hey Karim,

My name is Percy and I was hoping to get some advice on the first steps in this industry. I am a full stack developer but I am having a heck of a time landing a job because I have not accumulated enough experience. What steps could I take to overcome this hurdle?

Thanks, Percy”

My Story

Before I dole out my advice, I think it might be helpful to hear my story so you know where I’m coming from.

After having been in this business (software) since 2004, I’m now considered a veteran. I’m a senior software engineer and I’ve been managing teams of engineers since 2011. I literally have multiple recruiters reach out to me every day trying to sell me on some new job opportunity.

But it wasn’t always like this; it took a lot of work.

I graduated from UCSB in 2003 with a computer science degree, but I never did any internships over the Summer like the smart kids. I worked at the beach, as an ocean lifeguard, and went surfing every day. I didn’t build anything cool in my spare time like I should have. I just worked out and partied … or wait, maybe that was worth it. I did have a lot of fun …

Anyway, my point is that (besides earning a CS degree) I was woefully unprepared for the job market. The unfortunate reality is that a CS degree just doesn’t prepare for the real world of professional software development. I went on dozens of interviews for software engineering positions and got rejected again and again. Interestingly, the place I usually failed was in the interview. Nobody ever coached me on how to pass a software engineering interview. For those of you haven’t experienced it; it’s brutal. You have to get up in front of your interviewers and solve puzzles or write code on a whiteboard. You basically have to prove you’re smart enough to work at X company. This process has evolved slightly in the past 10 years, but it is still a stressful endeavor and I still get nervous at interviews. Heck, I even get a little nervous interviewing people.

Through all those failures, however, I never gave up. Instead I tried to learn something from every failed interview, and I started building websites … first for myself, and then for friends, and then I decided I’d start a web dev shop, and I built a website for that, and then took on more clients. They never paid very much, and some I did for free … but I was building shit, and I was learning.

Eventually, I landed my first job in tech, working for Electronic Arts as a Language Integration Technician. My job was to take assets in foreign languages, put them into video games at various stages, play through them, and make sure everything looked and felt okay. It was basically a glorified QA job.

 

The Answer

Here’s my (abridged) answer to Percy and future devs who are struggling in this market:

“Hey Percy, it’s always tough to break into the industry, especially if you didn’t do internships during school. I made the same mistake, but don’t lose hope. You’re doing all the right things, working on side projects and keeping your education up.

Are you getting interviews? or not at all? If you’re getting interviews, you probably just need to focus on your interview prep and get better at that. If you’re not, I recommend reaching out to recruiters and utilizing them to help you. Your interests are aligned; you want a job and recruiters get paid if you get a job.

Also, don’t be too proud to apply for QA jobs. It’s a way to get your foot in the door and I guarantee as long as you kick ass and show initiative, you will get promoted into that development job that you want. That’s what I did.

Also, if you haven’t already, don’t hesitate to apply for just front-end or just backend roles. I personally feel the full-stack developer is a bit of a myth, at least a good one anyway. If you really want to do full stack, your only options are probably small startups. Any mature software engineering organization knows they need their engineers to specialize in one area to get the most productivity and highest quality code out of them. Best of luck!”

Scaling an Engineering Team Effectively

When should I hire more resources?

I’ve started diving deeper into mentorship, both within Coffee Meets Bagel, and in the engineering community . At Coffee Meets Bagel, this is natural, as I have a team of around 20 engineers reporting up to me. All the engineers who report directly to me are leads or managers, so most of my mentorship within Coffee Meets Bagel is about how to effectively lead engineering teams, manage chaos, form relationships, provide mentorship, foster career growth, and operate efficiently.

Outside of my day job, I’ve started mentoring more high-level engineering leaders as well, and one of the common themes that has come up is, “How do I scale my engineering team effectively?” In this post, we’re going to specifically cover the topic of when to hire more resources, when to promote ICs to managers, and when to bring in a manager from outside.

It’s an important question at a startup especially because you want to move fast, but resources are limited. You should never hire more resources just because your company has plenty of resources or because your CEO wants to grow. There should always be some rationale behind it, and it should ideally always be a metric-based, analytical decision.

The most important types of questions you should be asking are:

  • Is the engineering team able to meet the product roadmap?
  • Are they able to meet the product roadmap with an acceptable level of quality?
  • Are they able to meet all demands of the marketing team and other key stakeholders in the business?

Clearly, if the engineering team can’t meet these demands, then there’s obviously a need to hire more resources and you should prioritize hiring where there’s the biggest bottleneck.┬áIn addition, I think you need to be constantly asking yourself:

“Are we able to meet the demands of all of our internal stakeholders while still maintaining a stable, performant system, AND not accumulating technical debt?”

In fact, I think the most important sign that an engineering team is healthy and adequately staffed is when they are making progress in paying off any technical debt that does already exist.

“How can I be analytical about this?”

If you’re not already, you should be working towards some system where you’re tracking velocity of each engineering team per sprint over time. I could write an entire post on best practices here, but the merits are undeniable, I think. By tracking velocity over time, you can get a pretty accurate view of how your engineering team is performing and it can give you early and hard evidence of warning-signs of potential under-performance. Also, by tracking velocity over time, you’ll start to get a very good idea of what your team’s capacity is per sprint. Then, based on that capacity, you should be able to give your product and marketing teams better estimates on when and if you can meet their roadmaps with your current resources. You also will have hard evidence you can take to your CEO if you have to ask for more resources.

I recommend defining some split percentage-wise between non-engineering work (like new feature development or feature updates) vs. engineering work (like re-factors, re-architectures, or just bug fixing / cleaning up tech debt). And this split should be dynamic. It should be an ongoing conversation between the engineering lead and the product lead. If engineering is in a decent state and there’s a large product backlog, we can devote more points in a given sprint to product features. On the other hand, if there are a lot of bugs or stability issues, maybe we need to devote more resources to engineering.

 

When do you need a manager?

Hopefully this will be obvious to you, but you can only have so many ICs reporting to you whilst be an effective manager and mentor for them AND be effective in all other facets of your job, whatever that may be. Managing people is hard. It requires frequent one on ones, ensuring there are career paths for your people, ensuring you have interesting and challenging work for your people, keeping them motivated and engaged at work, and getting buy in for your vision. For every additional person that reports to you, you’ll need to devote at least a couple of hours of your week to that person.

I think many of us are stubborn and have a false sense of hubris in believing that we’re such good managers that we can juggle the challenges of managing a dozen people AND still be able to think at a strategical level about the company’s priorities. We also find it hard to believe that somebody else could come in (or be promoted) and be more effective at managing all these people than ourselves.

You have to examine yourself closely. When you start to feel like the work of managing so many people is taking away from your ability to think big-picture, then it’s probably time to hire (or promote) a manager. Another indicator could be that if you just don’t feel like there are enough hours in the day to execute on big initiatives while paying attention to the necessary finer details, maybe it’s time to hire a manager to pay attention to some smaller details so that you don’t burn yourself out.

 

When to promote a manager from within

It’s a tough thing to do when deciding whether to promote one of your ICs into a managerial position or to bring in someone experienced from the outside. There are benefits and risks to both.

The benefit to promoting from within is that you are fostering career growth at your company, which is going to help your long-term retention of employees. Employees in all positions want to feel like there is some upward career-mobility for them. In addition, the person you’re promoting already knows your company’s domain and you know they fit into your company culture already. The risk of promoting from within is of course that the person may not be ready or mature enough for a leadership role and they haven’t yet developed the mastery of their domain that will be necessary to take your company to the next level.

The benefit to bringing in a manager from outside is that you can make sure you’re bringing in somebody with a track-record of success doing the thing you’re hiring them to do. If you have a good interview process, you can be reasonably sure they will come in and do a good job. The risk, of course, is that they don’t fit in well to your existing company culture.

Look for initiative, desire, mentorship, and respect

Initiative is the number one quality that I look for when making the decision on whether to promote somebody into a management position. I think it’s a huge indicator that the person will continuously improve their team’s processes and continually push the business forward, and I probably won’t have to micro-manage this person at all. I can trust they will do the right things for the success of their team and the company without me even asking. So, if you’re thinking about promoting someone from within, I’d want to see a demonstrated history of taking initiative.

Desire should go without saying. The person in question should have expressed some desire at some point to take on more leadership, to take on more ownership, and mentor their teams.

And they should be already exhibiting mentorship qualities to the other members of their teams. They should be going out of their way to aid their teammates. Their teammates should look to them as a valuable resource and subject matter expertise in their discipline.

And finally, respect. I’d never promote someone from within unless they already had the respect of all the other members on the team.

I think if you’ve got these four qualities (initiative, desire, mentorship, and respect), you’ve got a winning formula for your next successful manager or team lead.

 

When to bring in a manager from outside

I believe there are only a few good reasons to bring in a manager from outside:

  1. There’s nobody good internally
    If you have nobody on your team already who meets the above criteria, I wouldn’t risk it; just hire somebody from outside.
  2. It’s an area you’re weak in
    This takes an honest assessment of your skills. If you’re weak an area, and especially if either #1 or #3 applies, I’d take a good look at the benefits of bringing in a master.
  3. The team is young and/or inexperienced
    Even if you have somebody internally who demonstrates all the characteristics of someone you should promote into a leadership role, if that person and the entire team is just very inexperienced, it may be worth it to bring in someone with experience who can guide the team through the inevitable challenges.