This post has a lot of great career tips including how to select companies to apply to, what to do in an interview if you don’t know the answer to a question, and how to challenge yourself in a new job. This piece of advice in particular resonated with me:
Show how you think
Most interview questions are there to see how you think. So show that! Explain your thought process, draw diagrams, write out the intermediary code, explain pitfalls in your approach, etc! Be vocal, and ask clarifying questions. That’s part of being a good developer after all!
When I was hiring, especially for newer developers, I really wanted to hear how people thought through a problem. That process is important in two ways beyond actually solving the problem. The first is that it shows how you handle something tough that you haven’t encountered before (which happens almost every day on the job). It also shows an interviewer how you communicate. Since a lot of the challenge of building software is communication, learning how potential team members do it is crucial.
Sometimes when you are thinking about a new job or shifting to a new position in a company, it can feel overwhelming. What if I make the wrong choice? At least, I’ve often felt that way.
Every choice you make has effects. When you choose to study ruby, you can’t also study python (opportunity cost!). When you work at a company, you will learn how that company works, but not about how other companies work.
I sometimes have FOMO (fear of missing out) when I commit to one path. “What would have happened if I had gone down another path?” I wonder.
That’s OK. I think it’s human. But you still have to make a choice.
I remember talking to a friend once about making decisions. She said that she likes to make a decision as late as possible. I think this is a good practice. Gather the data you need and can get without asymetric effort (that is, the larger the issue is, the more effort you should put in–I should invest more effort into learning about joining a new company than I should into learning a new project within the same company, for example). Make the decision as late as you can, because you’ll learn more as time goes on.
However.
It’s also important to realize that few decisions are permanent, especially as a new developer in your career. You’ll have flexibility in terms of geography, type of company, type of job, size of company, business domain. Some shifts may be easier because of your history and the aforementioned effects (shifting from being a web developer to being a backend engineer), some may be harder (changing from a web developer into an embedded systems engineer), some may be well nigh impossible (changing from a web developer into a compiler developer), but some change will be available to you.
What this means to me is that decisions which seem crucial, critical, life-changing, are, but that if you make an incorrect decision you can change. And that, for me, takes some of the pressure off.
Sincerely,
Dan
PS, as Kendall pointed out, there are some decisions that are essentially permanent. But most career decisions aren’t.
In my experience, four types of companies use software. Software is as prevalent as accounting, so every company uses it in some way.
Those that sell software to help build software, software product companies. Examples from my career: Oracle.
Those that sell software, often called product companies. Examples from my career: The Food Corridor, Katasi.
Those that sell hours or knowledge of developers and other software professionals (PMs, designers, etc). Examples from my career: XOR, Culture Foundry.
Those that sell anything else and use software to help. Basically almost every other business. Examples from my career: 8z, Phoenix Enterprises.
As a new software developer consider where to seek employment, they each have strengths and weaknesses. It’s worth talking about these so you can find a company that aligns with where you want to go (remember, every place has its warts).
Software product companies
Pluses:
You are the end user, so having user empathy is easy.
Software developers are highly valued within the organization.
Lots of focus on building out higher leverage software processes.
When successful, these companies have great gross margins and can afford good pay and benefits.
Minuses:
Developers often start companies like this, so there’s a lot of competition.
Jobs are desirable, so may have a long interview process with a lot of hoops.
Product companies
Pluses:
You can go deep into a particular business domain.
Software developers are key components of such a company’s success, and are treated like it.
They often have recurring revenue and a business model that allows for good pay and benefits.
Minuses:
Can be harder to get hired than in other types of companies because jobs are more desirable.
May be boring to be in same domain for long periods of time.
May use older technology depending on the age of the company. Legacy systems make money!
Consulting
You often skim domains, so you can get some variety of experience in different types of businesses.
Always new projects to be on, often means new technology to evaluate and learn.
An hour worked is often an hour billed, so your efforts are directly related to revenue.
If you are looking to go off on your own, these consulting businesses are easy to start (no overhead, no investment in building a product, you just need a laptop and an internet connection and someone willing to hire you).
Minuses:
As an employee, you need to realize that there is no real exit strategy for the founder(s). Which is fine as long as the founder is still interested in running the business.
There is limited recurring revenue, which means that the business goes through cycles of grow -> shrink -> grow -> shrink.
Lots of lots of effort in finding new projects and clients.
Because of the sales cycle, it is hard to specialize as a consulting company, sometimes you take projects because you have to pay bills.
Can have tight deadlines and lower profitability, which affects your experience as a developer.
The rest
Pluses:
Often have stable businesses.
Software quality and process tends to lower in non software focused companies, making it easier to outperform competition.
Software quality could be competitive advantage.
You’ll have the chance to learn about and work in a non software business domain.
Minuses
Developers won’t be as highly valued at some other types of companies.
IT/software can be seen as an expense rather than a revenue generator, especially if not affiliated with revenue side of the business.
Each of these types of companies has different strengths and can be a good fit for you early in your career. Consider what excites you and what is available in your job market when you make the choice. It’s also worth reminding yourself that since as a new developer you’re judged on potential, any choice you make to go into one type of company or another isn’t permanent!
I remember one of the first times I spoke in public. I was talking about J2ME (which was a technology for building mobile apps, pre iphone) to the Boulder Java Users Group. I threw up some slides showing the flow of data across the system, and made a joke along the lines of “sorry if this is confusing, but at least it isn’t UML”. The audience all laughed, and I went on with my talk.
Public speaking is a great way to do a number of things for you as a developer.
Raise your profile in your company and in the community. Standing in front of a crowd and talking about a topic will get you noticed. Even if it is a crowd of 10 at your local meetup.
Teach you how to educate people. The way to help someone understand something is not intuitive. Speaking gives you a chance to practice it, and that will help you in your work life, since a large part of development depends on helping other people understand what you mean.
Force you to really understand your topic. Trust me, the pressure of being up in front of a group of people will cause you to dive deeper than you otherwise would have. (Kinda like writing an ebook.)
Let you learn something new. Related to the above point, you can learn something new when you are presenting. This can either be ancillary to the topic you are talking about, or, in some cases, can be the topic of your talk.
Some tips for getting started:
Find something you are interested in. Brainstorm ideas around that. Think about cross sections: “Using javascript in marketing” or “what do SQL and devops have in common”. Both technical skills like javascript, SQL or design and “soft” skills like interviewing and communication can be good topics.
Join a meetup. Go a few times as a regular member, learn who the organizers are. Then go to the organizer and say “I’m a new developer, but I’d love to speak sometime. Do you have any slots open?” (You can also join Toastmasters.)
When you get a chance to talk, practice it multiple times, at least once in front of someone. Remember that you are likely the most expert person in the room. If possible, start off with a joke or self deprecating remark, and ask for audience participation. More tips.
Look for local conferences. Then, look for Calls for Proposals (“CFPs”) at such conferences. Submit. Don’t spend too much time polishing a submission. Submit any proposal to multiple conferences. Papercall is good for that. (I confess, I’m not an expert at this process, so this is more based on advice I’ve read.)
When you go to conferences or meetups, walk up to speakers and ask how they got started. I’d suggest avoiding the superstars. Regular speakers will still have useful advice, but fewer folks surrounding them.
By the way, it is terrifying, but many things are the first time you do it. I mean, do you remember learning to ride a bike?
Public speaking is a great way to stretch yourself, learn new skills and meet new people. Highly recommended.
I’ve written before about my belief in blogging as a way to sharpen your thoughts and give examples of your expertise. Here’s a post along the same lines. From the post:
People always try to find someone they can trust. You can go through a series of interviews and hope that they will figure out you are a great colleague, or you can write about your approaches and let a wider audience know that.
If you have a deep expertise in some technology, you can demonstrate it by writing deep and thoughtful blog posts.
If this technology is in demand, you will definitely get some opportunities coming your way!
And
Your views expressed publicly can be a good conversation starter.
This may come handy in any professional social context: interviews, meetups, conferences. It’s a different level on conversation when you get approached because someone likes your views.
The author then goes on to talk about specific, measurable ways that his blogging has helped his career.
You will encounter good managers and bad managers in your career. I’ve found that one common thread for all managers is that they are busy. Busy with meetings, busy with coordination with other teams or parts of the business, busy putting out fires, busy with helping team members. Busy busy busy.
They also will likely be responsible for your career. Promotions, compensation increases, title changes. A good manager will want you to be challenged and grow and learn.
However.
The only person who really cares about your career is you.
You can help your manager help you by helping them know what you do. Sometimes this feels like an undue burden. Surely your manager can keep track of what you’ve accomplished on their team. And some do know some of the stuff you’ve done, some time.
But what you want is to help them know everything that you’ve done that you’re proud of. This helps them understand what a great team member you are, and also gives them ammunition to fight for resources (money, projects) that you deserve.
One place to put this information is in your LinkedIn profile (more about my opinion on LinkedIn). Of course, make sure you don’t reveal any company secrets (projects, launches, technologies) in this.
Another alternative is an internal brag document. Julia Evans has written a great post on writing one. This outlines one way you can help your manager (and yourself) keep track of all the great work you’ve done. It can be far more detailed since it is internal and not limited in length.
It’s not just limited to project accomplishments. You can build a bigger story. From the post:
In addition to just listing accomplishments, in your brag document you can write the narrative explaining the big picture of your work. Have you been really focused on security? On building your product skills & having really good relationships with your users? On building a strong culture of code review on the team?
I haven’t written one of these (although you could consider my blog somewhat of a brag document, I suppose. Yet another reason to start a blog). But having some kind of record of your accomplishments that you can share with your manager will help them help you.
I remember the first full time coding job I had. I was able to work on a great team, on interesting problems. I was able to get into the “flow” that is such a magical state. I was paid well. I had free snacks.
I remember going into my manager’s office and chatting with him. He seemed a bit stressed. He was constantly interrupted. He had lots of meetings. He seemed to want to code, but didn’t have time for it.
Me being the naive young optimist, I asked him once why he wasn’t coding. Why would he leave a really fun job for management?
He looked at me with a knowing smile and said something like “one day, you’ll understand”.
I don’t code for a living now. Oh, sure, I write some code. And it still gets me into flow. And I still enjoy it.
But the honest truth is that when I am coding, I have the leverage of one person. As I grow older, I grow more impatient to effect change in the world. The best way to effect change is to have more leverage. Some options for higher leverage:
writing
project management
product management
speaking
mentoring
leading a team
managing
teaching
architecting
consulting
Most of these involve communicating about coding (or other technical systems), but coding is not the primary work output. Instead, the emphasis is on knowledge or alignment of a team.
Now there are also code specific ways to get more leverage. Two that I can think of.
work on really big systems that have a lot of users (FAANG companies, or something similar).
work on open source libraries or projects that have a lot of users
If either of those floats your boat, then pursue that. I don’t like the first because I don’t really enjoy the bureaucracy and politics of big companies. I am not a fan of the second because I don’t really enjoy working for free.
By the way, no one says you have to have leverage. I’ve just seen that happen again and again across many companies and many individuals. Part of that might be the crowd I run with, but part of it might be that more leverage typically means more pay.
Your career is long. My guess is that one day you won’t want to code for a living. Enjoy it now, but keep your head up and think about what other areas, focusing on communication or team alignment, might eventually be of interest to you. Learn about those areas. Meet people who are currently doing them, and ask questions.
This post from Charity about the choices you face as an engineer, and the challenges of technical management, is wonderful. As a new developer, you’re probably a few years away from thinking about that (but perhaps not. If you join a startup rocketship, it’s possible you’ll be managing people in months). But you have to manage your own career, and moving into management is one of the main career paths for a developer. (I’d say the others include: starting a business, becoming a senior developer, or becoming a consultant.)
Charity talks about how management is an entirely new skillset, and how being a technical leader plus a manager is a great way to get amazing things done. She also covers the negatives of “climbing the ladder” to ever more senior leadership. Charity doesn’t mince words:
Your job [as a newly minted technical manager] is to leverage that technical expertise to grow your engineers into great senior engineers and tech leads themselves. Your job is not to hog the glory and squat on the hard problems yourself, it’s to empower and challenge and guide your team. Don’t suck up all the oxygen: you’ll stunt the growth of your team.
…
I mean, there’s a reason we don’t lure good people managers away from Starbucks to run engineering teams. It’s the intersection and juxtaposition of skill sets that gives engineering managers such outsize impact.
…
One warning: Your company may be great, but it doesn’t exist for your benefit. You and only you can decide what your needs are and advocate for them. Remember that next time your boss tries to guilt you into staying on as manager because you’re so badly needed, when you can feel your skills getting rusty and your effectiveness dwindling. You owe it to yourself to figure out what makes you happy and build a portfolio of experiences that liberate you to do what you love. Don’t sacrifice your happiness at the altar of any company. There are always other companies.
I don’t tell you this now, new developer, because I want to scare you away from management. I’m an engineering manager right now and it’s a wonderful place to be. You have autonomy, you can help fix problems you see in your organization, and you get to recruit and help grow people into the best developers that they can be. But just be aware that when you get to a certain level, it’s a one way path away from some of the most fun parts of software development–building things, solving hard technical problems, and being a doer.
Right now, it’s Q1 2019. And there’s a lot of advice you’ll find out here on the internet. Much of it is good, some of it is bad, but the important thing to note is that these are all points of view from people. From that person to be specific. This letter is no different, this is just my view on what matters. Take it or leave it. In fact, that’s the first point I want to make.
2019 tech is full of voices. Social media, popular blogs, and news sites amplify voices and feelings. This is an awesome thing, but remember that loud views aren’t necessarily right.
What I mean, is that you’ll find points of view on everything. Developers have always loved flame wars, and pointless battles (vi vs emacs, tabs vs spaces). Now it’s “Javascript developers aren’t real engineers”, or “If you can’t code a binary search, you’re a bad engineer.”
Find yourself in all these voices. It’s not easy, and it will take time. But work on what you value, and develop your skills to who you want to be. It’s ok if you want to work by yourself on speeding up a search by .01 milliseconds. It’s equally ok if you want to ship a single page app with a brilliant user experience. Listen to the voices when they help, and ignore them when they don’t.
To help find yourself, focus on finding customers that value what you do. Most of the time, these customers are the people in the company you’re working for. But if you want to do algorithms, find people who will value that work. If you want to work on networks, find companies who need that.
It sounds obvious, but it’s an easy thing to miss when you’re looking for a job, and when you’re evaluating comp, culture, benefits, and offices. It’s also really hard to gauge from the outside of a company.
On that note, remember that the 2019 tech industry isn’t how it will always be. Right now, the job market is stellar. I mean really stellar. In most big cities, you can find a job doing just about anything you want, most of the time within a few days.
This won’t always be the case. It wasn’t years ago, and everything comes in cycles. That’s the 2nd point. Be willing to do things you didn’t think you wanted to. I worked on embedded systems when I started my career. I got into web technology not because I cared about it, but because it helped me get a job in a city I wanted to live. Turned out to a prescient choice, and opened up tons of opportunities I wouldn’t have had otherwise.
The tech choices come in cycles, but so does demand. I said before that the job market is stellar. But some of us old timers have been through the downturns. When you’re unemployed for 6 months because literally no one is hiring. When your choice is between a 50% pay cut, or a 100% pay cut. Be wise, be smart. It’s a great time to be in tech, but plan ahead for the times that are tough.
Finally, my last point is to remember that there is a world outside of tech. It’s hard when you’re in it to see that. When tech was smaller, and more insular, it was easier to remember that this is a job.
But now, tech is everywhere. Apps are everywhere. The internet is everywhere. More people are writing code, building companies, and figuring things out. But, tech is not the entirety of life. Get outside of the tech zone, and connect with people who aren’t in it. It will change how you think, and how you develop code. And it provides a much needed break from the echo chamber that is tech.
Good luck, and have fun!
Rishi
Rishi Malik is the founder of Backstop.it, a company focused on making cybersecurity easy for companies to implement.
This is a guest blog post from Rick Manelius. Enjoy.
Dear new developer,
Can you name all 50 US states? How about their capitals? Every city in the US? Every town? Could you list the GPS coordinates of every coffee shop?
Of course, you can’t, wouldn’t, and don’t. It would be absurd to spend the time and effort to memorize such a vast amount of information that you can Google within seconds. Yet developers often fall into the trap of over preparing and learning a myriad of facts and syntax trivia for a new programming language or framework before diving in and getting their hands dirty.
A personal example: When I landed my first contract as a web developer, I recommended Drupal for the client’s project. However, I was deathly afraid of not being able to address any questions that might come up. To satisfy my “need to know it all” before I put forth an initial proposal, I purchased have a dozen ebooks and read the more popular ones cover to cover several times. Meanwhile, I was only dabbling in writing code by following the tutorials. Unfortunately, this was about as effective as trying to learn a foreign language without a practice partner. The information was forgotten almost as soon as I learned it.
I contrast this with how quickly my experience and skills grew when I started to give myself the permission to play, to test, to tinker, and to interact with the community through IRC and the issue queue. It was there that I would run into a blocker and use those eBooks as a useful resource because I had a specific purpose in mind. Moreover, when I couldn’t find my answer there or with Google, I could lean on others that were actively learning, growing, and sharing along their career trajectory.
Years later, I discovered this humbling infographic titled Becoming a Web Developer in 2017. I love this because it highlights the absurdity in trying to learn everything about everything in the web dev ecosystem. While all sites eventually roll up to HTML, CSS, and JavaScript, the number of underlying technologies used to support them is visually overwhelming.
A select infographic from The Web Developer Roadmap 2017
Each of the boxes represents a different subject matter. Each of these subject matters has additional, hidden complexity. Also, within that, there might be subsystems that maybe only a few core maintainers of that specific project would understand. Each box may take a day or a week to learn the basics, but perhaps months to years to master.
Trying to do that for every topic becomes an overwhelming investment of time for increasingly diminishing returns. It’s equivalent to learning the GPS coordinates of every coffee shop in the US.
To make matters worse, this infographic only represents the hard skills necessary to produce and maintain the software and its supporting infrastructure. It says nothing about the soft skills of how to participate and grow a high-performance team, how to make solid architectural choices, how open source governance works, how to handle change and release management, how to apply different project management methodologies, etc.
Before I overwhelm you any further…
…there is hope.
You don’t need to know it all. In fact, some of the most successful developers I’ve come to know are skilled searchers and askers. They may not know the information, but they know where it could be. They know how to parse documentation to find the salient details they need to accomplish the task at hand. They have a network of colleagues in other specializations that they can lean on for help. They are confident in asking even basic questions (gasp) in public, because while it may seem obvious for many, there is always at least 1 other person who has the same question.
Let’s look at the medical profession for inspiration. While they all go to school for 6-12 years to gain a base level proficiency, they can then either stick to general practice or hone in on a dizzying array of specialties. When we get sick, we start by going to our primary care doctor. Their goal is to identify and solve the problem there, or narrow down the answer space and refer you to a specialist. Unfortunately, even the specialists don’t always know what the issue is. This is why people sometimes need 2nd or 3rd opinions.
The good news is that in software we don’t need to go to a school for a decade to get started with experimentation or specialization. We are one tutorial and terminal prompt away from trying a new language or checking out a new library and testing it in a local sandbox where little to no damage can be done. There is so much power in this! And it’s also where it can be overwhelming given the 28 million public code repositories on GitHub alone.
Adopt a Hive Mind Approach
We live in a golden age of sharing and collaboration. Developers from all around the world ask and answer questions on Stack Overflow. They write tutorials and howtos on their blogs or Medium. In any given city, there may be anywhere from 1 to 20 tech Meetups a week. There are podcasts, Reddit channels, newsletter aggregators, and active conversations on Twitter.
By asking, discussing, and sharing openly in one or more of these venues, you are adopting a hive mind approach. You are both able to contribute to and receive ideas, perspectives, and solutions. It’s hard to overstate the importance of this strategy and mindset. In my experience, it’s many times more valuable than reading the 3rd or 4th ebook on a given subject (although these are often a useful reference). Beyond just discovering technical solutions, interactions with other developers often result in friendships that can last well beyond the burning framework question you had when you first met them.
So my advice (take it or leave it) is to abandon the lone wolf, know-it-all approach to software development. Instead, learn to contribute to and draw from the collective skills, talents, and experience from our fantastic community that is literally all around you IF you are willing to connect with them.
Final point. I stayed isolated for years until I broke into the Drupal community. Once I did, my career rapidly transformed. I wrote about that here.
So get out there! And good luck!
– Rick
Rick Manelius is an MIT engineer turned web developer turned startup CXO (operations, product, and technology). You can connect and learn more on his personal blog and his LinkedIn profile.
