Forem: Tim Hwang

Early stage companies shouldn't hire juniors (yet)

Tim Hwang — Mon, 31 May 2021 02:43:29 +0000

People I talk to tend to be surprised (and often personally offended) when I tell them that my company doesn't interview junior engineers. It's an understandable reaction; a blanket policy of not hiring juniors implies certain negative things. It can imply arrogance: I think I'm so smart and talented that junior candidates simply can't keep up. Or it can imply poor value assessments: I don't think juniors are worth training. Or it can imply selfishness: I think juniors are worth training, but it's expensive; I'll let some other sap eat the cost of training them, and then poach them.

On one hand, I don't decide hiring strategy at my company, so chill! On the other hand, however, I must admit that I think this is a sensible policy that's worth justifying. To do so, I need to add several qualifiers: we don't interview junior engineers at present because we are a small growth-focused company, and I don't think small, growth-focused companies should hire juniors.

(Note that the main question this post attempts to answer is "is hiring junior engineers beneficial for early stage companies?" It's not attempting to answer the related questions "is hiring junior engineers beneficial for junior engineers?" or "is hiring junior engineers the right thing to do, even if it's not personally beneficial?")

1. Risk and time

Small, growth-focused companies are in a cutthroat race against time. The company is not yet profitable and is burning money in R&D and customer acquisition. This generally means building as fast as humanly possible, prostrating oneself at the feet of customers, and pivoting so much your product roadmap looks like an Etch-A-Sketch. In such an environment, I can't see how hiring a junior engineer and dedicating several months worth of resources to get them to net zero productivity is an effective use of resources.

The problem isn't one of expense, or even one of rate of return. Junior engineers are cheaper to hire than seniors, and proportionally benefit far more from training. Hiring and training juniors has an incredibly high rate of return. Rather, the problem is one of risk, and one of time to return. Juniors are inherently higher variance due to having less of a work history or references that can be evaluated, and young companies are drowning in risk already. Additionally, the lifeline of young companies is measured in months, not in years. For these companies, every day and every dollar is spent in order to get the next, longer lifeline (venture funding, hockey stick growth, etc.) before everyone goes bankrupt and moves back home with their parents. A junior engineer may be ready to be a star player after 3 months of training and learning, but there may no longer be a team to play on at that point.

In poker, short stacked players have no choice but to tighten their ranges and play low variance hands. Early stage companies are in the same boat: regardless of how big a payoff hiring junior engineers may have (or how altruistic it may be), these companies simply lack the resources for it to be an attractive option.

2. Hire fast, fire fast

If the problem is that hiring juniors requires more resources than early stage companies have, a solution could be to reduce the amount of resources needed. The "hire fast and fire fast" strategy is one popular approach. In this strategy, juniors are given the bare minimum resources (maybe an onboarding guide, some code labs, and a scattered list of online resources) needed and told to figure it out -- and if they don't, out they go.

This is similar to how large mega-corps hire juniors: at Facebook, Google, and the like, new hires go through weeks or even months of orientation and onboarding boot camp, and emerge ready to hit the ground running. Our strategy is basically the same as the mega-corps, only without the time, money, and resources, and with an atmosphere less like college welcome week and more like the Hunger Games (unless said mega-corp is Amazon, in which case they really are basically the same).

I have to admit that this seems like the most cost-effective way for small companies to evaluate junior candidates: the level of risk is capped, and the negative impact of hires that don't work out is minimized. The only sticking point is that it's evil, and a reputation for being evil tends to be bad for hiring. While this strategy works out in the company's favor, it is predatory from the perspective of the new hires.

(Some may argue that a predatory relationship is better than no relationship, which is the argument used by companies offering unpaid work or work paid via "exposure." I'm sure the hire/fire fast strategy can be tweaked to be more equitable, but I haven't yet found any implementation that's compelling enough. Bad early career experiences can be crippling, and I'd rather stay away unless I am sure the experience would be great for junior engineers. There are enough companies out there that hire anyone with a pulse and ruthlessly cull the herd.)

3. Growth potential

There's a belief that engineers from large companies tend to be overspecialized, and that engineers from small companies are more independent. I've found this belief to be entirely inconsistent with my experiences. Over the years, I've had the opportunity to work with mid-level engineers from large companies and mid-level engineers from small ones. In general, the ones from large companies felt years ahead in experience: they were the ones who had a large repository of patterns and architectures to draw from, who knew how to effectively work cross-functionally, who could scale databases, and who could do domain modeling effectively.

Even if you're willing to bet on your mentorship capabilities and commit the resources to train up juniors, doing so may not lead to the best long-term growth for juniors. Pattern recognition and analyzing existing systems are two important ways in which junior engineers learn. Engineers witness more successes and more failures at large companies than at small ones; this evidence of what works at scale and what doesn't is powerful insulation against a cargo cult mentality. When it comes to systems, startups generally aren't know for being shining bastions of best practices and stable architectures; things change a lot in the pursuit of product-market fit, and products are often made to be more or less throwaway.

It's not impossible for juniors to thrive at small companies, but the rate of growth at a larger company will likely be much higher. I believe the converse of this article's title is also true: if given the choice, juniors shouldn't join early stage companies. (Of course, the options available to junior engineers is inherently limited. It's probably sensible for prospective juniors to value their long term growth potential lower than their short term ability to pay rent.)

4. When should companies start hiring juniors?

To me, the question of hiring juniors is not "if", but "when." I believe that early stage companies should not hire juniors; at the same time, I believe that companies that hire juniors are doomed in the long term. At a certain scale, having a steady supply of junior talent is critical to a company's continued survival: there simply are not enough senior engineers to go around. (Companies like Netflix are the exception, where sky high compensation and a compelling engineering brand are used to continue attracting senior talent.) Whenever taking a stance, it's helpful to identify the boundary conditions under which the stance will change.

So where is the inflection point? There isn't a universal answer. Early stage startups generally don't think in the long term, but there are indicators of success (or, more conservatively, "signals of a reasonable expectation of continued existence") that may influence the decision of whether or not to hire juniors. Milestones like hitting 100 people, or reaching a certain valuation target, or raising a certain amount of money may all be such inflection points around which hiring policy should be revisited.

Growing as an engineer

Tim Hwang — Sun, 20 Dec 2020 15:45:41 +0000

Congrats! You've settled in at your first job. You've made it past the initial wave of impostor syndrome and have some idea of what you're doing and what you're good at. You might've even received a promotion or two. You're no longer wildly floundering every day and are able to at least flounder in the right direction. You might even be on your second or third job at this point. You actually feel like a real engineer now.

Now what?

It's common to feel a sensation of plateauing after an initial few years of hypergrowth. This is only natural: Growth comes from new information, and the supply of novelty provided by a job quickly dries up as the years pass by. Up to this point, simply engaging with your job was enough to provide steady improvement; now, you must actively seek new information to keep growing.

Before proceeding, I want to clarify one thing: being happy with where you are is perfectly fine. You might feel entirely comfortable with plateauing, and that doesn't make you any less of a person. If you're content and have job security, congrats - you've won. It's not worth it to burn yourself out trying to level up if you're not motivated to do so.

Develop an Eye for Quality

When trying to grow as an engineer, the very first step one must take is to develop an eye for quality. Strive to be able to recognize quality in any domain, even if you're unable to produce it yourself.

Why is this so important? Simply put, you can't get better if you don't know what better is. If you simply accumulate more information without filtering that information for quality, you're wasting your time.

Developing an eye for quality begins with active thinking. Analyze new information in both top-down and bottom-up manners. Aim to go beyond identifying if something is good and instead examine why it's good.

Top-down: Is this consistent with other things I know to be good? How does this information fit into my existing mental model of quality? Can I think of alternatives that'd be better?
Bottom-up: What makes this good? What's the rationale behind this line of thinking or approach? Is the premise of sound logic?

Building a mental model of quality isn't trivial. Below are strategies I've personally found to be effective. The ability to recognize quality is both a prerequisite and an outcome of these strategies. Aim to form a self-reinforcing cycle with a positive feedback loop.

Build an Information Stream

Don't underestimate passive learning. Digesting a well-written article every morning results in a cumulative knowledge gain that adds up over the years. Think of it as a quick mental workout.

Build a stream of content that's of higher quality than your current knowledge. Prune it over time to keep quality high. You don't want to internalize bad principles or ideas, and you don't want to take bad advice from people not worth listening to.

Don't overcurate your content stream for specific topics. Directed learning is good for focused growth, but too much direction cuts off new information whose existence you weren't aware of. Some degree of variance is good to avoid overfitting.

As always, engage critically with content. Don't blindly accept arguments. Understand why the author thinks the way they do, and always try to grasp the context behind the writing. Mortimer J. Adler's "How to Read a Book" was a common recommendation when I was in grad school, where the vast majority of one's work is reading.

Optimize for information retention and retrieval. Taking notes and writing summaries helps with digesting information and has value even if you never revisit the notes ever again. If you have a bad memory like me, leverage bookmarks and other tools to build a searchable knowledge base.

Find what medium works for you. I have a hard time maintaining attention with videos or podcasts, so my content stream is 100% textual and consists of newsletters, blogs, and aggregators. Yours will likely be different. Everyone absorbs content differently.

Active learning is great but requires a higher level of commitment. Finding uninterrupted time to follow a prescribed curriculum can be hard as a full-time worker. If your workplace offers learning time and/or credits, take advantage of it. If passive learning is a steady trickle, active learning is a firehose to the face.

Find a Mentor (Ideally Multiple)

An experienced mentor you can trust can act as a calibrator for your developing mental model of quality. It goes without saying that prospective mentors should themselves have a refined model of quality.

It can also be helpful to have mentors both inside and outside your workplace. For the one inside, get advice on your career goals, project goals, and work-specific tasks. For the one outside, talk about more general engineering topics, and get a detached view of your current work situation.

Use your mentors to unblock yourself. Don't fall into the trap of stunting your own growth out of fear of bothering others. Have regular meetings with them, and solicit feedback frequently. A similar trap is not asking questions because you feel you should be past that stage. If you don't ask for help, your mentors might assume you're doing fine, only to be disappointed when your work is subpar.

Don't blindly trust your mentors. Analyze their advice actively and critically, even when you've established their eye for quality. Try to identify any biases they might have, and use those as a lens through which you interpret their advice. Find the path of reasoning they took to arrive at their conclusion; learning to reason about classes of problems is far more valuable than any individual answer.

Find well-balanced mentors. If you can't, find multiple mentors with a diversity of opinion. "Spiky" mentors offer quality advice but only within a very narrow domain. This can result in your model of quality becoming overindexed in this domain. If your only mentor is an engineering supremacist who hates managers, you'll become an engineering supremacist who hates managers.

There isn't necessarily an ideal personality type for mentors. However, we can converge on it via process of elimination. Avoid the following personalities like the plague:

Hot-takers and hand-wavers: Surface-level thinkers whose models of quality overuse heuristics and aren't built on critical reasoning. They might seem knowledgeable due to being able to quickly form an opinion on anything; however, these opinions generally lack substance. They often care a bit too much about their Twitter follower count.
Cargo-culters and gold-platers: People whose model of quality overindexes on social proof and/or the latest and greatest tools and tech. They might seem like bleeding-edge technologists, but remember that the role of an engineer is to produce value, not shiny code.
Mules: Contrarians who are overly confident in their models of quality and view disagreement as flaws in other people's models rather than a potential flaw in their own. People who are right more often than they're wrong may start drinking their own Kool-Aid and miss the point when they start becoming wrong more often than they're right.
Architecture astronauts and purity zealots: People whose models of quality operate at the wrong level of abstraction. Architecture astronauts are too high, while purity zealots are too low. They may be valuable and productive experts in their domain, but having such narrow blinders isn't conducive to good mentorship.

Push Your Boundaries

The easiest way to learn quickly is to push your boundaries by working on things just outside your level of expertise. This will force you to make decisions you aren't used to making and to practice recognizing quality.

Be aware of your gaps, and constantly reevaluate yourself. A helpful exercise is to develop a framework of engineering skills and evaluate yourself based on this framework. A sample breakdown that isn't necessarily exhaustive might include:

Coding skill; pure programming ability
Domain modeling; system design; architecture
Ecosystem familiarity; knowledge of tools and libraries
Interpersonal interaction (building consensus, effective teamwork, etc.)
Project management (managing tasks, scoping, how to ship, etc.)

If working in a new domain, familiarize yourself with the high-level topics in this domain. Roadmaps like roadmap.sh can be a good starting point. Be aware of what you don't know; by knowing what's out there, you're more equipped to unblock yourself when a problem arises. Your toolbox may be empty, but you should know what tools you can acquire.

Practice your model by forming opinions. The act of judging if a certain thing is good or bad forces you to distill your model into rules and apply these rules to concrete things. Don't take mental shortcuts; ensure your logic is sound and you're not making tenuous leaps of logic. Being able to reason about quality shields you from cargo culting. Validate your opinions with more experienced people. Don't blindly take their advice; figure out why they do things a certain way and if it's good or bad.

Don't become overly reliant on asking specific questions (either to peers or on Stack Overflow). This will build fragmented islands of competence that might not ever become an integrated knowledge base. Additionally, solutions devoid of context bias your model of quality toward pattern matching rather than first principles. Read the docs to develop a foundation; then build knowledge on top of that.

Pace yourself. Continually working in an unfamiliar domain is stressful and risks burnout: You'll naturally be slower and may feel pressure to overwork to maintain your pace. One strategy is to alternate between growth tasks and competence tasks. This can prevent impostor syndrome while reminding yourself how productive you can be in this new area once you level up.

Minimize Feedback Loops

Growth occurs in a feedback loop of information encounter, synthesis, and application. The tighter this loop, the faster learning occurs. There are many operational tasks that lengthen feedback loops; identify them, and cull them.

Don't be bottlenecked by decision paralysis

Accept that you'll build things wrong many times. Bias toward quick feedback loops of iteration and evaluation, so you can pivot quickly without too much sunk cost. Identify what makes a minimally evaluatable product: enough work that lets you decide if you've made the correct decisions.

Don't be bottlenecked by brainless, repetitive tasks

Learn keyboard shortcuts for your tools instead of reaching for the mouse. Add aliases to your shell for repetitive commands and tools for repetitive workflows. Aim to operate at the speed of thought; execution should be aggressively optimized and automated.

Don't be bottlenecked by typing speed

If you're young, there's no reason not to have a best-case WPM lower than 60 or so (ideally, 80-100+). There's the idea that typing speed doesn't matter because one thinks far more than they type. I find this logic ridiculous: There will always be rote tasks where the only limiting factor is your typing speed. Additionally, being a master of keyboard shortcuts isn't an alternative; you can and should do both.

Don't be bottlenecked by code review

Segment your work into logical and understandable chunks. Craft your PRs to be as readable and as reviewable as possible. Respond to feedback promptly.

Don't be bottlenecked by your memory

Learn to document and take good notes. Every minute you spend relearning something you've learned in the past is a waste of time. Similarly, every minute you spend confirming some decision you forgot is a waste of both your time and someone else's time.

Shape Your Environment

You can't build a model of quality without a sufficiently large body of positive and negative signals. For most people, their source of signal will be their workplace. This is subject to diminishing returns; after three to five years, you've probably hit an inflection point of signal versus time. At this point, it can be worth seeking a role change. This can come from vertical movement (promotion), horizontal movement (role or team change), or changing jobs.

Roles can be incredibly different with just a few parameter tweaks. Some examples:

Small team versus big team
Public versus private company
Tech stack (both components of and what part you work on)
Cultural values
Processes, patterns, and norms

It's worth experiencing a diversity of these parameters early in your career. The faster you can collect information, the faster you can build a good model of quality.

Your new role should have some overlap with your old role. You don't want to return to the floundering stage, but you want enough novelty to spur new growth.

Some environments aren't suitable for learning and growth. You may be pushed to stay in your lane because there's too much pressure to ship for you to temporarily lower your productivity to learn. Try to shape your environment by explicitly asking for different types of tasks; if this is denied, it can be worth changing jobs if your goal is to optimize for self-growth.

It All Comes Back to Identifying Quality

Identifying quality is the common thread tying each of these principles together.

Information streams provide new data to feed into your model of quality. A good mentor can direct your budding model, pruning and shaping it during its critical period like a bonsai artist. Pushing boundaries lets you put your model to the test. Minimizing feedback loops makes the information encounter-synthesis-model update loop as tight as possible. Shaping your environment ensures a constant inflow of new ideas and practices. And having a more robust model of quality makes you better at doing each of these things.

A parting thought: Is this article you're reading right now quality? I'm self-aware enough to know that I myself have many biases, even if I'm unable to pinpoint them. My anecdotal experience has an outsize impact on my priors, which can lead me to dramatically different conclusions compared to others. Where are the tenuous leaps of logic in this article? Where are my biases showing? I'd love to hear from you in the responses below.

Lessons I've learned as a grad school dropout

Tim Hwang — Thu, 09 Apr 2020 20:25:19 +0000

I dropped out of grad school in December 2015 after two and a half grueling years. I left with practically nothing -- no first author publications, no degree, not even a single completed research project under my name. I hated my life so much that to me, losing a quarter of my twenties was a small price to pay for escape.

Roughly half a year later, I was starting my first day as a "real, professional software engineer." It's been almost four years since then, and I've seen some success in my new environment -- much, much more so than in academia, at least! The further I get from grad school, however, the more I'm able to objectively view my time there. In retrospect, it wasn't a waste at all: I've learned several invaluable things during my time in academia that continue to help me move forwards today.

Learning how to read

It didn't take me long to realize that for my entire life prior to grad school, I had never learned to properly read. While I don't consider myself to be particularly smart, I've always been a (comparatively) fast reader. I was skilled at identifying and extracting nuggets of important information from textbooks. This made me an efficient studier, so I did well on tests throughout school and college.

This model of learning quickly reached its limit in grad school. Research articles are incredibly information-dense such that for the most part, every sentence is important, and simply extracting nuggets is not enough. This is also quickly impressed into you by the fact that unlike in college, all papers have a page maximum instead of a page minimum. In addition, the sheer volume of reading that has to be done is several orders of magnitude higher than in college: if you are taking four courses, and each requires five articles per class, and each article is between 10 and 30 pages of minuscule text, you're basically consuming a textbook of highly compressed information a month. Reading is not a sprint, or a timed game of hide and seek. It is a slow, grueling, deliberate marathon. Once you are doing your own research, it's even worse: instead of having a handful of targeted articles prescribed to you, you have to trawl the entire ocean of prior research for the right articles.

When I became a junior engineer, I was stunned by the resistance many seemed to have against reading documentation. "It's too long. It takes too much time to find the information I need. I don't want to waste time going in circles." It was common to see people reaching for a more senior engineer the moment a roadblock was encountered (or worse, settling for a clearly insufficient solution). Even at that time, I strongly believed that the role of a junior wasn't to be as productive as possible or to produce the cleanest work possible, it was simply to learn as much as possible, as quickly as possible. I think I read the React documentation in its entirety at least once a month in my first six months. This was enough to set me apart from my peers and even some of my seniors in terms of subject matter expertise. So much information is readily available, with the only obstacle being volume.

To me, asking a senior and getting a single, targeted answer to a specific problem when a complete guidebook is readily available is akin to choosing a single nugget of insight over an untapped gold mine. The extra minutes or hours (or days, even) I'd spend wrangling with a problem on my own terms? A small price to pay.

Learning how to measure

I'll be frank. I remember very little from the thousands of pages I've read in grad school. I don't think I could give you five hypotheses, methods, and conclusions. I hardly even remember what classes I took. One thing I do remember is the endless debates with my advisor and lab mates about what to measure to support our hypotheses. It's important to measure the right thing.

My field (industrial and organizational psychology) was somewhat unique in its application of abstract psychological principles to real organizations. Unlike in, say, neuroscience, I/O psychologists don't tend to measure psychological phenomena directly. We don't measure stress by swabbing cheeks, or attention by attaching electrodes to people's scalps, or motivation by doing an MRI. This is simply intractable at the organizational scale. Instead, we are constrained to picking good proxy variables, or measurable variables that can act as sufficient substitutes for unmeasurable ones. (You could say that biological phenomena are ultimately proxy variables as well, despite there being fewer layers of indirection.) When planning a study, it was always a laborious back-and-forth to argue about what real-world outcomes mapped to what psychological principles, how this mapping could be established, and how to actually measure this.

There is a parallel in engineering management. While we can directly measure engineering results by setting monitoring infrastructure, logging, and health checks, any attempt to do the same for productivity and motivation must use a proxy variable. Complicating the issue further is the fact that prior findings in psychological and management science often don't apply well to engineering organizations (especially young ones). The solutions for an organization are often dependent on the unique constraints and resources available to that organization. There is simply too much individual difference in startups. (Though, for the record, I think the higher level the finding, the more generally applicable it is. Conclusions about motivation, stress, and burnout are more universal than conclusions about leadership, performance measurement, and organizational change.)

My paltry 2.5 years studying organization psychology are nowhere near enough to have answers for the management challenges engineering organizations are facing. But they are more than enough to help me realize that these problems are anything but trivial, that anyone who claims to have a one-size-fits-all solution to this challenge is either misguided or has an agenda, that the effectiveness of managers is organization dependent, and that the manager that fits your organization is worth their weight in gold. It's hard as hell to know what to measure, and the answer can be different for every organization. But by knowing how to measure, we can slowly get to the what to measure that is unique to us.

Learning how to be content

The last is the most personal. Complaining around the water cooler or breakfast area is one of the most common tropes in office culture. It was especially prevalent at my first job (and sometimes went on until it was nearly lunchtime), and I've lost many hours of my life listening to people airing out their grievances about anything and everything, from the (lack of) leadership to the dwindling office amenities to the stagnant wages to the workload. They complained about how their old colleague was living it up at that big company in the Bay, and oh, how nice it must be.

And the whole, time, a single thought would resonate through my mind. FUCK OFF!!! No matter how bad my job got (and it got fairly toxic at the end), it never got anywhere near how insanely difficult life in grad school was! I loathed living with four roommates. I loathed $1.39/lb chicken thigh from Walmart. I loathed seeing my friends with jobs enjoying their early twenties, trading their cheap hobbies like basketball for expensive ones like snowboarding. I loathed being seen as some kind of noble 21st-century ascetic, foregoing a comfortable life in the pursuit of knowledge. I loathed it all, and threw my academic life in the garbage the instant I had the chance.

What did I trade it for? Certainly not for a job in a gleaming tower where they give out RSUs like candy. I don't have nap pods, and I don't have steak and sushi flown into the office overnight cross country for lunch. People haven't ever heard of the companies I've worked for. But you know what? As a candidate with zero professional engineering experience, I was getting offers that were 500% of my grad student stipend. Workload? As an engineer, you're considered a workaholic if you work on weekends; in grad school, take weekends off and you die. Perks? Okay, the health insurance is less than stellar compared to what students get, but otherwise they're incomparable.

This isn't to discredit the individual struggles tech workers might face, or to say that the academic lifestyle is normal and not utterly unsustainable. However, to me it's incredibly important to maintain a sense of perspective. The five most valuable companies in the US are tech companies, and they're not shy about showing it. In the struggle to keep up with the Bezoses, it's easy to forget how easy tech workers have it overall. My wife is still in grad school and I live in a college town, so much of my friend group is still tied to academia in one way or another. I see flashes of the struggles I left behind, and it often fills me with guilt seeing how easy my life is in comparison. And it's not pity: ultimately, it's a fear of going back. What I have now, with all its flaws and day-to-day frustrations, is enough.

It's enough.