I don't think specializing would hurt your chances to land a job at a startup, and could help. However, if you don't have basic generalist skills then you are hurting your chances to succeed.

For context I think there's a difference between 

- The skills you need to succeed at a job
- The skills you need to get the job

At a startup, most of the time you need a wide array of skills to succeed. And generally with hiring, they tend to care more about generalists. But this isn't always the case for getting hired. We all know there can often be a large delta between what is screened for in hiring and what is actually done on the job. For example, you get hired as a frontend web dev at a small startup, but then they pivot to an app and now you now have to mobile development instead. But in this example, someone who specialized in frontend web dev would have a better chance at getting the job, but if they don't have experience in mobile (or can't pick it up quickly), then they will struggle at the job. Plus, startups often need people to hit the ground running so having experience in a specific stack is better as they don't have the time for slower onboarding. So generalist is good enough, but generalist + specialist is ideal.

The nice thing is that from my experience startups often have less technically demanding then large tech companies. So, being mildly proficient in a domain should be sufficient to do the work required to succeed. So, my general process to maximize my chances at a startup would be

1. Have a basic skills in all parts of the stack so you can succeed
2. Be able to put on your resume concerete experience in multiple stacks. So for example, experience as a fullstack engineer or experience with backend in one position and frontend in another. For lower level positions, you might be able to get away with having interesting side projects to fill in the generalist gap.
3. Specialize as you wish to increase chances in a specific position category.

Finishing step 2 should be plenty to get you a job in a startup, step 3 just improves your chances in some positions. The main difficulty here is it's harder to specialize in step 3 when at a startup since the work involves wide breadth, but with the right position or a good ability to advocate for projects this can be achieved.

The good news is that this process aligns well with the process for getting into Big Tech if you ever want to pivot as

- Having basic skills across domains helps improve you as an engineer
- You can still land a role after competing step 2
- Step three increases your chances at startups and big tech

However, depending on the role you may want to have two versions of resume. One that leads more towards generalist and another leads towards specific expertise. 

Also another thing to keep in mind is that these things are often variable based on company culture, the companies economic situation, specific team, region, etc. So although this general pattern of generalist at startup and specialist at Big Tech may statistically significant, there will be counter examples in each category. So best determine this from information about a specific company vs whether or not it's FAANG or not.

Mid-Level Software Engineer at Series B Startup

Josh Lindsay

Assuming you mean objective measures of code quality that effect the business, and not personal preferences or dogma of the week. \
\
I think that it can be difficult to get a sense of code quality in interviews for a variety of reasons:

1. The person doing the interviewers may not be the person qualified (in terms of context, skills, or both) to gauge quality.
2. Just as the candidate tends to put the best first forward, so does the interviewer. That means they may be reluctant to say negative things, especially about the codebase, or they may focus on only citing the high quality aspects and not the low quality aspects.

If you're applying to a very large company, you can probably get some sense from posts on Blind and talking to people on Taro (although it is often team dependant). However, I will be assuming this information isn't available online. \
\
So, **I think your best chance is trying to tease out some other qualities that tend to correlate with high code quality during interviews.** Some factors that come to mind are:

 1. **Voluntary dev employee turnover**: If the codebase is worse it is more likely for engineers to leave, so asking about the percentage of engineers that voluntarily leave. If it's significantly higher vs lower compared other companies you have a good indicator there.
 2. **CI/CD processes**: If they have good test coverage in-code, integration tests, and end-to-end tests, simple and reliable deployment process, etc. it is more likely the code is high quality. So, ask what processes they have, code coverage, etc.
 3. **QA processes**: If they invest in QA, they are likely to invest in high quality code as well. So, ask about the ratio of QA to devs and if the QA team is mostly manual, automation engineers, etc. If the dev team is also responsible for QA, ask what percentage of time the dev team usually devotes to the QA tasks.
 4. **Delta between deadlines and when products ship**: A product may ship fast because the team duct tapes things together, or it may ship fast because the codebase is easy to work with. So, I don't think time to launch is a good metric, but there ability to plan for a launch may be. So ask about how often they ship things and how often the successful launch is close to the estimated launch.
 5. **Monitoring**: Similare to CI/CD. If they invest in good monitoring, it is likely they invest in quality code as well.
 6. **Bugs**: If there are a lot of regressions it is likely the overall codebase is low quality, and if there is a lot of bugs from new features it is likely deadlines or planning is lacklustre. So, ask about how much time is spent during regular work on bugs, how much time is spent cleaning up new features, and how big the bug backlog is.
 7. **Interviewing process**: There's the saying, how you done one thing is how you do everything. If the interview process is disorganized, ineffective, etc. there's a good chance other parts of the company are, like codebase.
 8. **Staffing**: If a company has a surplus of engineers relative to the work, it's easier to devote time to good code quality. So if they have a lot of engineers relative to the product complexity, recently got funding, have a product that prints money, etc, they have the time to keep a codebase cleaner. Companies tend to brag about this sort of thing, so you should be able to get information on this without asking.
 9. **Engineer Skill**: Higher quality engineers to produce higher quality code. So stalk some future coworkers to see their experience on LinkedIn, GitHub, etc to see if they are high quality. This especially the case for the leaders, so it would be good to find out if the CTO, immediate managers, etc. have a technical background.
10. **Size of customer base**: It's easier to cut corners of quality if you have less customers, since things like bugs and security vulnerabilities have a much smaller negative impact. So, ask about how many users there are for the specific product and how scaling is handled.
11. **Company culture:** What values a company totes, how they gauge employee performance, what the leaders are like, and what they prioritize is a good way to see what they care about. This is most subjective but I think the best way to immediately find companies with low code quality based on profiling. Is the CEO posting non-sense AI hype on Twitter? Is employee screen-recording software mandatory? Are performance metrics of employees a top priority?

The list isn't exhaustive, but you can use your experience to think of what other factors correlate with high code quality and think of questions to ask to get this information. You can also get some of this information checking out Glassdoor reviews, employee and ex-employee LinkedIn info, and company resources like blogs, twitter posts, etc. However, many of the metrics only loosely correlate (I can think of good arguments against any of the factors I listed), and peoples answers can always be incorrect, so at best you can make an educated guess.

David gave great practical advice for handling the situation, contextualizing the likelihood, and dealing with immediate anxiety. So, I will speak to the overarching and somewhat permanent anxiety portion as me and my partner deal with the same anxiety.

What helps with me is looking with a very long term view as then I get to take solace in reality, optimism, and positive statistics. It is most likely (as shown by many stats) that your salary will increase as you age. If they are your spouse, it is likely they will be with you forever, through all the problems. So, looking at the period of a lifetime, both of your being laid off is a small insignificant blip. Not to stay your anxiety isn't valid or proportional to the situation, but your emotions are likely calibrated to the short term, focusing on actively calibrating it to the long term helps reduce the feeling of anxiety the more often you make the effort.

If the worst happens and you both are laid off, you have a small period of no income. You either burn through some savings if you have it, or take on a little debt. You take a job you aren't as interested and live a modest life for a short period. Then, the market picks back up, you get new jobs and you rebuild savings with a higher income. So, the worst possible situation is a small portion of your life with less in the bank and less satisfying work that averages out with little long-term effects. You get the opportunity to learn how to deal with difficult situations and problems with your partner. This skill alone will have more long-term benefits than the financial cost of being underemployed. If this worst happens and it really hurts your mental health, you get a clear signal to invest more in your support network, coping skills, and overall mental health. Those skills as well will pay more long-term dividends that a little extra money would.

Thanks for sharing your worries, there are many of us and reading about someone else's experiences always helps. Just know the worst is unlikely, and even if it happens things will be fine.

This is an obvious answer, but I think it summarizes the complexity well: the highest amount you can charge and still get work.

So, if you charge 1.5x and have more business than you deal with, charge more. If you charge 1x and don't get any, and you have already improved things like marketing, networking, etc, you will have to charge less.

One thing to keep in mind is that if you are very efficient, charging by the hour hurts your profitability. I know you said you are looking at long term contract roles, but usually investing in those gives you much worse revenue compared to project based contract work or regular employment. Jobs at startups are inflated by outside investment, and FAANG jobs are inflated by their leverage as money printing machines with their core businesses. It is much harder for you to compensate for that as a contractor. So instead, you would probably be better off investing that time in improving your regular salary with interview prep, networking, investing time for internal promotions, etc.

However, this isn't the case for project based work and you don't charge by the hour. For example, if you are a 10x developer and charge your hourly rate, you are giving them a 90% discount. If you do project based, that's not the case. In other industries like construction, this is seen as "piece work". It's better to switch to this as quickly as you can since you capture more of the value you generate. For example, if you charge what would take a normal developer 100 hours, but complete it in 20, you are making 5x more. The customer isn't hurt by this at all, since they are still getting the market value. You are just getting the extra value from your productivity. Or, you can charge the cost of 80 hours, when it would take a regular developer 100, and you still capture most of the increase in efficiency but still give the customer a good deal.

However, in practice this ends up being less satisfying. For one, there is tons of competition as you have to compete with developers who don't have access to us FAANG salaries but may be just as productive if not better. Chasing profitability ends up diverting you towards CRUD apps and small websites which are not technically satisfying. Most start off with a smaller network of customer base so they have to charge less to get their foot in the door.

If you want larger complex projects with many stakeholders and working alongside a team, then long term contracts are better for this. However, at that point, it's usually better to invest in your corporate career.

What's most important really depends on:

1. What are the company problems that need to be solved
2. What the company recognizes as important problems

Oftentimes these are the same, but sometimes they are not. I would argue 1 is better to pursue as it actually makes the company better. However, if you're more focused on internal promotions and recognition, 2 is better for the short to medium term.

If you are going to pursue an important problem that aren't getting the recognition they deserve, you should advocate for it so it enters category 2. For example, if you believe that a lack of internal tooling is causing devs to be less productive and bugs to me more apparent, you need to contextualize that for the business. You would want to show the extra cost to development time, the cost of fixing bugs, and have a concrete number for that. Also, have a concrete number for the opportunity cost, and then show the cost and impact of your proposed solution. If you're persuasive and have good management, this means you will be able to work on something you care about, is recognized by the company as important, and actually helps the company.

There may already be tons of things in category 2 you can work on. For example, if conversion is a problem your product is having, you can work on improving the, user experience, analytics, building/implementing a/b testing frameworks, etc. You can show how important your project is with obvious metrics like improved conversion rate. Decreasing cost and increasing revenue are always low hanging fruit, but there may be more interesting problems like hiring processes, dev processes, etc.

If you're having trouble finding important problems, it's good to talk to other teams, looking at overall company goals, and hearing from department heads or skip managers are great places for inspiration. People in your company who have been promoted quickly will have some more tangible advice and experience for your org. Keep in mind that these often don't align with your regular daily tasks unless you are already working at a cross team level like Staff, Principal, etc. So, try not to just look at your immediate team's needs, as that will lead you to solve problems in your team's subdomain and not larger more impactful problems.

Some easy things to look at to gauge how important a project is are:

1. How many people or teams it effects
2. How long the positive benefits will impact the org
3. How many people will need to work on it for it to be successful
4. The highest level of stakeholder who will have visibility

Hope this helps. One thing to keep in mind is that I have more experience with medium sized companies or ones that prioritize autonomy and independence. I assume since you are at Amazon there is complex structure and politics (call it stakeholder management if you prefer) that you will have to navigate. Someone here with more FAANG experience would be better advising you how to make this advice actionable given your specific large company.

My side project was instrumental in getting my first three jobs, despite it being non-commercial. However, now that I have more experience I will be leaving it off my resume. Side projects are good at establishing passion, initiative, technical experience, and helps with culture fit.

Early in your career, you're more likely to have gaps in any one of these dimensions. A somewhat technically complicated project that solves a problem is great at filling in these gaps. So, if you have a dimension lacking, like coding experience, a personal project can be a great supplement. However, since you mention you are a manager, you may not have any deficiencies in these. Or, the deficiencies are not big enough to warrant the investment into a complicated project.

However, this is just speaking on the perceived value to employers. Projects also have the value of learning hard and soft skills, can be extremely fun, etc. So whether or not the project is worthwhile for its intrinsic benefits is a personal choice. But, if one of the main motivations is for your CV, it would be good to draft your CV with and without this project to see if the benefits are worth the investment.

I agree with Lee. Depending on your culture and the bandwidth of the tech lead, I think it's much more important to use this opportunity to start establishing a great personal relationship.

Reason being is the practical stuff like how best to succeed, org structure, dev processes etc will be answered organically as you start to ramp up, work with others, look at the code etc. 30 minutes of talking about work related things with the tech lead won't have a large impact on how well of efficient your onboarding goes.

However, 30 minutes establishing a good personal connection will. There are tons of opportunities to learn about the code, but not many to connect with your tech lead. The earlier you establish a great personal connection, the earlier you can benefit from the better connection. This will manifest with benefits like
1. More patience with any onboarding troubles
2. More personal investment of the tech lead in your success 
3. Reduce your resistance in reaching out when you need help
4. A headstart in building an even better connection

There's not really a script in building a good relationship. But easy tactics are 
1. being genuinely interested in them as a person and ask questions about themselves and things they are interested in
2. Finding points of connection like hobbies, experiences, etc.
3. Be vulnerable when socially appropriate
4. Being some most likely much needed positive and enthusiastic energy (I don't think you will have a problem with this given your question)

Obviously, if your tech lead is all business or overworked this will be more difficult. However, you won't know that until you try connecting first.

I had the same experience at my workplace. There were no tests, minimal outdated docs, devs with many tasks, etc. Startups are chaotic and the code and processes will reflect that.

I found a sink or swim approach to be best. Find a bug that's being ignored, and work on fixing it. It will force you to bounce around the codebase, get context for business logic, talk to devs that are in the git blame, etc. Plus, you're providing value to the company while you learn.

The silver lining is all these poor processes give you the opportunity to make a massive impact. During onboarding, if you find the dev environment difficult, improve it while you learn to set it up so future devs can benefit. If docs are missing from something you are working on, add them. If you find tests are missing, add them as you learn the codebase. It forces you to solidify your understanding of the business logic and architecture while providing more value.

With a 9 to 6 schedule and a commute, it's asking a lot of yourself to do extra when you get home. Not saying it's not do-able, but due to the constraints I don't think a 'good balance' would be possible. Especially if you want to have some other hobbies or a social life. If that's a tradeoff you're willing to take early in your career, as many of us did, it will be beneficial career wise. However, I would advise you to be suspicious of any intuition you have that this will be "a good balance".

A good compromise to reclaim some of your free time would be to do as much learning as you can at work. So, get as competent as you can as quickly as you can at your regular responsibilities. Then, you will have the freedom to carve out an hour or two of your working time to read blogs, play around with new tech stacks, leetcode, etc. You shouldn't work on any project that could make money at work, but other than that you should maximize your self learning during your working hours.

A way to do this without taking away time from your employer is to take on learning projects at work. So anytime you can work with a new tech stack, deep dive into a tricky bug, etc, you should. That way you don't have to steal time away from your regular duties or free time as you will be getting the learning "for free" from your regular work. You're just taking the initiative to make your regular work as maximally educational as possible.

Building in public is great for this, so posting demos, status updates, user interviews, etc. on public  People get value from seeing how build things I get practice pitching/posting, and you grow a user base as you build instead of having to get it all at the end.

A welcoming community for this is indie hackers, <https://www.indiehackers.com/>. They have tons for great resources and an active community, so you can post updates there (there's a whole section and culture around it). Also, the community is super supportive so you automatically have some people willing to check out your product.

The best way is always talking to users early and often. So, if you have outreach to people in your relevant vertical who are interested in the idea, they give you useful feedback early and have incentive to try out your product.

The fact that you're bored is a good sign, that means you're probably competent in your role.

So, it's probably time to tackle harder problems. Expanding your role to handle more aggressive refactors, be involved in more of the product design process, building internal / developer tools, and mentoring others are all great problems and domains to learn more and add some positive stress.

If you have a good manager, let them know and they will be happy to give you harder work. If your manager is not as helpful, then you get to talk to coworkers and other teams to identify problems yourself and take away time from your regular responsibilities to work on these. If your bored and can manage expectations, it will be easy for you to manage your ambitious learning and your regular day to day.

Leading by example is great here. Start communicating in the way you think it should be done. But remember to keep in mind that there are many valid ways of communication, and what is "better" should be driven by noticable benefits like productivity, enjoyable work, improved product, less long tail negative impact, etc.

If you're communication is better and beneficial, others will notice this when they work with you and have their work be more joyful and productive. They will remember this, and try to do the same.

If your commutation method is not better, and they are opting for a more scattered, context driven and agile approach, you will notice this when the time you put into 'better" communication doesn't provide meaningful benefit.

Either way it's a win-win. If your method is better you will have improved your organizations processes and established yourself as a leader. If it's not better, you learn more about different styles of communication and establish yourself as an ambitious team member who cares.

This isn't always necessarily a bad thing, it depends on your company culture. I would say unless you have good evidence, give the new manager a try. If it ends up being a bad fit, transfer teams, but don't do so until you're sure that the current manager is poor and the alternatives are good.

From my experience, if it's a manager without experience, you get more autonomy. They have less experience, often less expectations, and rely on you more to take charge. This is a great opportunity to better advocate for work you want to do and push back on things like timelines and priorities you think are detrimental to your work and organizational goals. It is also easier to stand out since other team members may not be able to make use of the opportunity as much as you are.

However, if the manager is purely HR related and doesn't overlap with your actual work and priorities, then my point is less relevant.

I feel you, I had that issue with my first remote job. You can definitely build meaningful relationships, I have, but it will take some effort and vulnerability. I don't know if it's necessarily the default with remote work, but it's way easier to fall into comfortable disconnected patterns, especially with the focused work of developers.

It's easy for interactions to be transactional when they're about work. A code review is way less personal than raving about your favorite tv show or venting about a frustration in your life. I found making an effort to be fun, kind, and human makes it easy for others to return the favor.

One way to break the ice of vulnerability is with public praise. Either in a public slack channel or decent sized meeting, give a coworker a shoutout for something helpful they do. I remember almost every time someone has given me a genuine compliment and it makes it much easier for me to connect with them on a personal level.

A few things I found useful

1. Schedule a half an hour one one with someone and make the goal not to mention work.
2. Use liberal memes and jokes when interacting with coworkers in private chats.
3. Share your suffering. If your stuck debugging some niche issue for a few hours or are putting out a fire, involve someone else. Patching a prod database in a pair programming session builds way more trust and connection than a async code review.

If you try to make an effort, other people will reciprocate. So just find a way that to reach out that makes you the least uncomfortable.