by David Xiang
I’m not saying that tech-driven companies are the best way to go; I’ve had some amazing experiences and gone through tremendous personal growth working for “business” companies. Do not underestimate the power of finance, marketing, sales, or any other non-technical discipline. As a developer, there are countless challenges to solve in any company, and cross-disciplinary skills can give you a serious leg up against other coding purists.
At the end of the day, you have to ask yourself— is this company driven by a technical product or not? Remember, neither is better, they are just different, but the distinction must be clear! Be aware of the true nature of the beast you’re about to join.
Short-Term & Long-Term Goals
When joining a startup, pay careful attention to both its short and long-term goals. Understanding these goals isn’t easy, but you owe it to yourself—and the company—to try to fully understand them. Do they want to liquidate as fast as possible? Do they really want an IPO? How technical are the products going to be? How would the engineering team look in a year? In five years? Any honest startup will answer those questions if you ask.
Make sure you differentiate between healthy salesmanship and false promises.
If a startup needs someone to build its tech from the ground up, and you’ve been dying to develop code from ground zero, then it might be a match made in heaven. However, that opportunity would be a serious misalignment if you’re looking to chill on the beach by five o’clock every evening. If the company really needs to develop their Android application, then there’s no reason for you to be there if you want to get system-level experience. What does the company need and what do you want?
The needs of the company will be in constant flux. Small companies need developers for very different reasons than medium or large companies. Similarly, you are human, with your own set of dynamic needs. There will be a period in your life when you want to learn a specific platform, then another period when you want to do some architecture, and then another when you want to get into management. Match-making two moving targets is not a trivial task. No one’s expecting them to be in perfect harmony, but they’re going to have to move in the same general direction for both sides to have a chance of success.
As a reminder, be wary of excessive salesmanship when considering any employment. Startups have an uphill recruitment battle to fight, and it’s highly likely that you are being sold to. There’s no harm in a little salesmanship; you are a hot commodity and startups need to do whatever they can to get you on board. Make sure you differentiate between healthy salesmanship and false promises.
Have an honest conversation with any potential employer to understand their short and long-term goals. Be careful—don’t take what they say at face value. Instead, listen to what you’re being offered and allow yourself to form your own opinions about their goals. Then match those goals with your personal objectives until you’re ready to make a decision.
Engineering Team Growth
It’s imperative to get a sense of the engineering team’s current state and its plan for growth in the coming years. Is this a team that is going to stay super lean, or is it about to explode? If the team remains tiny, you will take on massive responsibilities and have to fulfill every technical role under the sun. If the team is about to blow up, prepare yourself for chaos and growing pains.
Ask yourself—does the company even need the engineering team to grow? Refer back to the concept of tech company versus non-tech company. Based on that differentiation, a company’s basic technical needs will be different. Those basic needs will correlate to the team requirements of an engineering department. It could range from a few highly paid developers to a fully staffed crew. The current and future growth of engineering will have a direct impact on your experience—pay attention to this.
What Needs to be Built? Does it Fit Your Goals?
What does the startup need to build? Align the answer to this question with your technical goals. If you really hate developing web applications, then there is no reason for you to consider working at that new social network startup. If you want to do one hundred percent JavaScript, then there is no reason for you to consider working at that new network security startup.
The easiest, fastest, and most time-efficient way to push out your technical goals is to align them with the genuine requirements of the startup.
Understanding what tech the startup needs built is the most convenient—and most accurate—way to get a feel for your potential day-to-day. Throughout our entire careers, we will constantly set technical goals for ourselves. If you join Google, you’ll probably be fulfilling these goals through your side-projects. However, the story is different with startups. The easiest, fastest, and most time-efficient way to push out your technical goals is to align them with the genuine requirements of the startup.
Conclusion
The decision to join a small company is significantly more personal than the decision to join a big company. The Facebooks of the world provide the highly tangible, lucrative benefits; you get a brand, you get a big paycheck, you get real stock, and you get a fancy office with dessert carts. The decision to join the tiny startup will never be so clear. If you’re considering it—take, your, time.
35: Who Do We Need To Hire? [Daily Life]
Hiring is a challenging and never-ending aspect of the software industry. It’s painful and tiring for the applicants; it’s time-consuming and expensive for the employers. Both parties are futilely trying to find the perfect match in a system with a million changing variables. A match today inevitably turns into a parting of ways tomorrow. Companies change, people grow, requirements shift, and all we can do is appreciate the shared time while it lasts.
Whether you’re a CEO looking to hire your first set of software developers, or you’re a programmer looking for an environment switch, it’s crucial to understand the context of a software hire. Hiring is laborious and omnipresent, but its end goal is simple and static—get everyone on the bus, get them into the right seats, and get the bus to the next stop.
Companies change, people grow, requirements shift, and all we can do is appreciate the shared time while it lasts.
The most obvious matching criteria is your technical skill. Another easy one might be the personality match or the culture match. These things are basic and I won’t discuss them here. What I do want to talk about, though, is the context of the hire. What is the circumstance of the company? Who do they need? What do they need to get done? Does the role they’re hiring for match what you want to do?
We Need an Expert in XYZ
This is the most relatable situation for any developer. You get matched with positions based on your expertise, and it’s more or less a one-to-one connection. This is the startup that needs to start their iOS app, so they recruit an iOS specialist. This is the healthcare company that needs a data scientist to parse through their growing warehouse. This is the scaling finance startup that needs a dedicated security professional.
The circumstance for an expertise hire is cut and dried. The company knows what it needs, so it knows who to hire—simple. However, simple does not mean easy. You’d be surprised how often people aren’t sure what their companies even need in the first place. Companies can only hire established experts after they create established roles. Smaller companies need flexible technologists; an expertise hire too early is almost always the wrong move.
We Need Someone to Execute Everything
The jack-of-all-trades generalist is a requirement for the budding startup; they need something built, as fast as possible, with as few people as possible. This is getting your MVP off the ground to start your company. This is joining up with your MBA friend to help prototype his or her idea. This is joining the five-person team, so you can end their reliance on Excel and WordPress.
If you find yourself in this role, it can be exhilarating, because you will be designing everything, learning everything, and controlling everything.
The pre
mise of this role is execution. The company is too young to have concrete expertise roles like Site Reliability Engineer (SRE) or Quality Assurance (QA). You can forget about management and real career feedback cycles. They need code written and they need a developer to do it.
If you find yourself in this role, it can be exhilarating, because you will be designing everything, learning everything, and controlling everything. You will get a taste of the whole gamut of software from scaling, to security, to product, to internal tools, to workflow. You’ll write more lines of code than you’ve ever written in your life. If you’ve been in a silo—only working with one language or one platform—then a jack-of-all-trades role can be surprisingly eye-opening. This role is optimized for learning, impact, and sprinting. It is not optimized for longevity, compensation, or chilling.
We Need Someone for R&D
Some roles are designed for the academic and research-minded. These roles are exploratory and are built on the premise of patience, discovery, and innovation. The company chooses to spend extra capital on engineering something that has no immediate return on investment.
These roles come with few deadlines and offer the freedom to choose what you work on. If you are a technical purist, don’t care for deadlines, and enjoy interacting solely with other engineers, then this role is a great fit. If you love working on product, appreciate cross-department interactions, and like to see your code get into the hands of customers, then be sure to avoid R&D.
You see these roles in both huge corporations and startups. Every company values R&D differently. Visionaries put it high on their priority list, while operational types punt it to the back burner. Big players need to keep innovating to stay ahead of the curve; thus, an R&D budget is a smart and reasonable investment. Startups— depending on founder style—either use their capital to find the next one-hit wonder, or opt to focus their cash on improving known, day-to-day tasks. Companies started by engineers will generally value R&D higher than their business-minded counterparts.
We Need to Grow and Fill Out
Every company runs on its own timeline. A new business is born every second of the day, IBM is alive and well, and then there’s everything in between. There are periods on these timelines where companies prioritize growth, aiming to up the employee headcount, expand into new markets, and, most importantly, increase the value of the business.
During a growth phase, companies need resources and bandwidth to fulfill their promises. This is when you see new faces every other day around the office. Hiring is on full throttle, structure is formed, and outside consultants come in to formally train you about Agile development. During these times, growing engineering departments will open up tons of software positions from site reliability, to QA, to infrastructure, to product. If you’re a specialist, this might be your time to shine. Companies know what they want and will start hiring more for expertise and less for generality.
These times are exciting for both the company and the developers. It’s not the wild-wild-west anymore, and you can finally put your skills to good use. All work counts as gold during growth; you won’t have to worry about Big Brother axing your project or being assigned to maintain legacy code. Even though growth periods can be exhilarating, remember that it’s still only temporary. The fancy project you’re building from the ground up will eventually turn into tedious upkeep for you or another developer.
We Need Someone to Manage
Hand in hand with growth comes management. These days, management roles should not be considered the only way people can climb the software career ladder; companies value technologists just as much as they value their managing counterparts—sometimes even more. The true builders always have the option to build; there is no longer an obligation or expectation to eventually become the boss.
…companies value technologists just as much as they value their managing counterparts— sometimes even more.
Management is not a very sexy job. Nevertheless, it needs doing. No matter how cool or relaxed the advertised company culture is, a large group of people requires layers of accountability. If any prospective employer touts a flat structure where everyone is equal, be sure to run away as fast as possible. Google tried this and failed miserably.
A manager’s job is just like any other and comes with its own set of tasks—hiring, firing, writing performance reviews, dealing with drama. Keeping in mind that management is the not the only way to advance your career, ask potential employers about each track and what it means. How much work does it take before you can make the decision to fork? What’s the compensation difference between the different tracks? How is decision-making split between a principal engineer and a director? Don’t be afraid to ask such questions; they show that you value your future. Any self-respecting engineering department will give you honest answers.
We Need Someone to Maintain the Code
Last, but not least, we have maintenance hires. Unfortunately, this is the least sexy-sounding hiring context, but it’s also important. Never underestimate how long a codebase can exist. Developers come and go, but the code will live on. It’s not uncommon to see a file header that dates back to the ‘90s. Inevitably, companies must deal with churn and hire new developers who can keep their systems operational.
These positions are not optimized for ambitious coders trying to change the world. These positions are optimized for people looking to chill and get home for dinner by six o’clock. These jobs are not about their novel technical opportunities. Before you accept a job like this, make sure there is some worthwhile benefit—serious financial upside, networking opportunities, brand-building. These positions are usually very easy to spot. Make sure you know what you’re getting into.
36: Nothing In The Grand Scheme Of Things [Daily Life]
Everything in your life takes up brain space. If it’s not the day job, it’s the side-project or it’s the height of the surf this weekend. Shaolin monks and meditative types are able to keep their heads empty, but the rest of us mortals are a jumbled bag of thoughts and emotions. The activities we spend the most hours on correlate directly with our highest mental preoccupation. When such activities have the power to dominate our thoughts, it’s easy for us to blow the little things out of proportion—that drama you’re having at work isn’t really a big deal in the grand scheme of things.
…whatever ordeal you’re going through, it will just become another story in a couple of years—it isn’t that big deal a deal
In college, I was in constant competition with my peers on a personal quest to become technically competent. In my various jobs, frustrations with my managers and silent struggles for rank with my colleagues preoccupied my thoughts on a daily basis. Work stress invaded my weekends. I’d complain to my parents, friends and anyone else who would lend me an ear.
If I’ve learned one thing from all of this, it’s that whatever ordeal you’re going through, it will just become another story in a couple of years—it isn’t that big deal a deal. Nevertheless, what might now appear trivial was, at the time, enough to fill me with anxiety. This is something we all go through.
The stress of any situation usually traces back to the same root cause—your interaction with other humans. You will never, ever get along with everyone. There’s no use in trying and, frankly, it’s a completely unreasonable expectation. At the core of your mini-dramas, there is a human struggle. You will complain when someone takes credit for your code. You will be frustrated with your manager’s micromanagement. You’ll be upset when your founders decide to pivot the company. You’ll be angry with another developer just because you feel like it. Whatever it is, it’s taking up space in your brain, it’s using your energy, and you’re blowing it out of proportion.
Every single moment we experience is a fleeting one; you can’t hold onto it. All moments will pass, the joyful and the sad, and then we die. It sounds morbid, but it’s true. We are here on earth for only a short period time; we should strive to build and enjoy a simple lif
e, and then we will be done. Nothing lasts forever.
Do not confuse my sentiment with a to-hell-with-it-all one. Life is not about being indifferent. You must stay hungry, welcome competition, and strive to progress. The caveat is that we must not become overly attached to the outcome. A friend once told me that between the ages of twenty-eight and thirty-one, he was blindly consumed with the desire to be a VP of Engineering. That position had to be his next step. Every job application hinged on the title, and he lost many hours of sleep over it. Blind attachment sacrifices our emotional state; it’s not a healthy way of living.
There have been times when I’ve become so fed up with work that I’ve find myself complaining incessantly to friends, colleagues, and family. These thoughts took up huge quantities of my energy for weeks at a time. I would think about work on the subway, at the gym, in the shower. I was overly attached to an outcome, and had lost all focus in my regular life. It’s during those moments that you have step back and remember that whatever the problem is, it is nothing in the grand scheme of things.
Do good work, don’t become overly attached to the outcome, and keep your progression going.
I know that a lot of software developers out there are going through their own stressful times. I know this is easy for me to write, when I know nothing about your situation. If you are going through such times, always remember that this moment is temporary; it’ll be replaced by more bad times and more good times. Do good work, don’t become overly attached to the outcome, and keep your progression going.
37: Styles And Mediums [Learning]
Everyone learns in different ways. Some absorb knowledge visually, others need to get their hands dirty in the code, and a select few drown themselves in literature. Your preferred style might be the result of genetics, or it could just be how your third-grade teacher nurtured your juvenile brain.