FAQs for a Software Engineering Hiring Manager

Technical Interviews have evolved a lot since the early I transitioned from being a Software Engineer to an Engineering Manager. Particularly in the post-Covid era, there's been a greater emphasis on the person, which I think is an important and welcome change.

Over the decade of interviewing hundreds of coders, I've also had the pleasure of working with various bootcamps, colleges, and hundreds of individual job seekers on LinkedIn. Across all the changes over the past years, across the various locations and mediums, something remained consistent throughout: The questions I get asked. 

With that in mind, I thought - why not make a FAQ from my perspective as a hiring manager?

While this is my perspective, it's based off years of observation and supporting data. But that being said, advice is not fact. You may disagree with certain points, and that's OK. Opinions we disagree with allow us to better understand our own views. At best, I hope these responses help you land your dream job. At worst, I hope they'll help you form your own ideas on how to approach your career.

Here are some the full set of questions. Click on one to jump to the response below.

On Resumes

  1. How should I build my resume?
  2. Should I have a Career Summary/Objective?
  3. What should I list in my professional experience?
  4. I don't have relevant professional experience, should I list non-relevant experience?
  5. Should I list projects?
  6. What should I include when listing projects?
  7. What if I don't have any projects?
  8. What should I list under my education?
  9. What if my degree/certification has nothing to do with coding?
  10. Should I list my GPA?
  11. Should I list my references, or state "References available upon request?"
  12. Why do I need to quantify things on my resume? What does that mean? How can I "quantify things" if I don't know the numbers? 
  13. How many pages should my resume I have?
  14. Can I have more than one resume?
  15. What links should I include on my resume, and should I have the URL or actual linked text?
  16. Should I go with a modern design, or a traditional one? One or 2 columns? Colors or B&W?
  17. Do I need to build an ATS-compliant resume?
  18. Should I lie on my resume, or embellish my experience?
On Applying & Job Hunting
  1. Should I include a cover letter?
  2. Should I apply to multiple roles at the same place?
  3. Should I apply for a different role under the same manager?
  4. Should I follow-up if I've not heard back?
  5. Should I connect with the hiring manager on LinkedIn before the interview?
  6. Should I connect with the hiring manager on LinkedIn after the interview?
  7. How should I track places I've applied to?
  8. How can I tell if I'm being ghosted / Why aren't people getting back to me?
  9. How can I increase my odds of being noticed/being seen?
  10. Should I work with a recruiter?
  11. ATS resumes, LinkedIn Quick Apply, Recruiters... it's all very stressful. Why is it so overwhelming?
  12. Should I pursue a role that's different from my objective?

On Companies

  1. Should I consider a start up?
  2. What challenges exist in a small company, medium company, large company?
  3. Am I missing out on anything by being fully remote?
  4. Someone pitched me an idea and can't pay me but will be a reference to me. Should I pursue it?

On Managers

On Resumes

  1. How should I build my resume?
    There's a lot to cover on this one topic, which I've covered in few other resources which I'll list below. But in the interest of brevity, here's my tl;dr:

    Build the resume for a busy hiring manager. The resume isn't your life story. It's a pamphlet that lists your skills, but also expresses your unique value and thinking. It should highlight your accomplishments and outcomes rather than tell a chronological biography. Build it with the knowledge that hiring managers will only spend 2-3 minutes looking at it. Try to keep it to 1-2 pages. Prioritize the information around relevancy:
    1. Your name
    2. Email & Phone
    3. LinkedIn
    4. List your tech stacks, languages, along with your years' experience (don't rate your skills.)
    5. Summarize any other relevant areas of experience: Agile, Team Lead, etc.
    6. Professional experience (if it exists). List the technologies used, list your impact & outcomes.
    7. Projects (take the same approach as Professional Experience.)
    8. Education (if you specialized in any specific areas like ML, Data Science, call out some of your courses)
    9. References (only if there's someone particularly notable - a former manager, a team lead, etc.)

    Ditch the headshots, the professional summaries, the career objectives, buzzwords, and two column resumes (those just de-prioritize information by breaking up the hierarchy.)

    For more, check out my:

    Back to top

  2. Should I have a Career Summary/Objective?
    Yes and no - they can be redundant and take up a lot of room. Plus, they're often filled with fluff. That being said, I have a Summary at the top of my resume - however, I've removed the jargon/buzz-word fluff. Instead, I use my Summary as an actual summary. I do all the heavy lifting: I do the math and state then length of my career, and then I break it down into the key areas that have defined my career.

    As an example, pulled straight from my resume:

    10+ years in leadership, with 5 years managing multiple 20-person teams with an additional 9 offshore, augmented with additional consultants. Owned 7 enterprise products including multiple $10M+/year SaaS solutions delivered to >100 clients.

    Of course, if you're starting off, it could look a little more like:

    Built 5 projects, including 3 full-stack projects and 4 cloud-based applications. 2+ years experience leading and training team of 5.
    That last statement may be about your time at the local pizza place - but the challenges of leadership and managing are universal. It's still relevant experience.

    Lastly, when it comes to your objectives/goals, that's something you should think through in anticipation of being asked in an interview.

    Back to top

  3. What should I list in my professional experience?
    Beyond just the company name, your title and the dates you were there, it's helpful to cover any tech stacks and methodologies you used in the role. That way, in an interview, the interviewer can ask you relevant questions around your projects.

    After that, it's about outcomes & impact. That's what you want to communicate. It's not worth stating the obvious aspects of your role. Most people will assume you did the basics. If you were there to code, you likely coded and you likely fixed bugs. Dig deeper than that and, importantly, keep it relevant to the role you're pursuing. If you're shifting into more of an Architect role, focus on your architectural contributions - no matter how minimal.

    Some will suggest including a brief statement about what the company/business unit did, so you can set the context. That's good advice if you have the space. Alternatively, you can work it into your outcome statements.

    Point form over full statements. It may sound pointed, less personal - but remember to think of your resume as a pamphlet, not a biography.

    Lastly: Quantify things. Numbers help keep your impact statements factual instead of subjective. They are measurable, they are meaningful. Go with the numbers that are objectively the best (dollars, timeframes, users, etc.) but if those are hard to determine, go with benchmarks: lead time, cycle time, performance time, speed/memory usage/disk usage, etc.

    For example:

    Encom International Jan 2020-Oct 2021
    Jr. Web Developer Anytown, USA
    Technologies & Methodologies: React, MySQL, Kanban
    • Delivered 8 major features on enterprise level Master Control product for large enterprise corporation.
    • Worked with 5 person team for product with over 1,000 companies.
    • Owned 1 experimental feature, delivered prototype and presented to Product Manager. 
    • Averaged 20 major bugs per month, with an average lead time of 10 days and cycle time of 8 days. 

    Back to top

  4. I don't have relevant professional experience, should I list non-relevant experience?
    It can be trickier when you don't have any relevant experience - and you'll face this when you're starting out. In these cases, reprioritize your information: List your projects first, and follow it with your non-relevant professional experience. However,  as you do this, make the effort to generalize your experience and tie it back to what you're pursuing.

    For example, maybe you spent 3 years as a team lead at a pizza place. Just because it's not "relevant experience" doesn't mean it's     irrelevant. You've dealt with customers, aggressive timelines, resourcing, training, and more. Focus on those aspects, but don't sell it too hard either. It's important to strike the right balance.

    Back to top
  5. Should I list projects?
    Yes! Projects are always great to see - especially in the case where you're light on relevant professional experience. Projects are a valuable form of experience, especially if you can speak to them as if they were professional projects: How did you manage timelines, what were the challenges, and what impact did it have?

    If you have too many projects to list and you're struggling to think of what projects to go with, I'd prioritize as follows:

    1. Large open-source projects to which you are an active contributor
    2. Personal projects that could stand alone as products
    3. Smaller projects that let you experiment and stretch your skills
    4. Small-to-medium projects (open-source or otherwise) for which you are a contributor
    5. Course/School projects

    Course-work should be the very last thing you should consider. Assignments are designed for you - and while they challenge you around specific areas, they also don't represent work you've done of your own volition. Hiring managers like getting acquainted with job candidates through the projects they pursue. If you've not pursued projects beyond what was assigned, it doesn't look very promising.

    In other words: If all you have is course work, it may be worth considering building some projects over listing course work in your resume.

    Back to top

  6. What should I include when listing projects?
    Take the same approach as with professional experience: list the tech stack, methodologies, followed by a bulleted point-form list of impact and outcome statements focused on quantifiable and measurable impacts.

    Provide a link if it's live, to the AppStore, or to the GitHub. 

    Lastly, hit on any role you took on beyond just writing the code. Did you project manage? Did you serve as Product Manager? Did you market it? Produce videos? Share it!

    Back to top
     
  7. What if I don't have any projects?
    Projects are proportional to experience. If you have plenty of experience then only list projects that were particularly notable, and only if they demonstrate a skillset you can't easily highlight in your professional experience.

    However, if you have no experience, then projects really matter. Without experience and projects, you're relying on the hiring manager making a huge leap of faith. When it comes to a decision between you and someone else who has a few projects, the hiring manager will likely go with someone who is showcasing their projects.

    Build a small project first - there's lots of resources & ideas out there. Alternatively, partner up with an established project and contribute. Once you've made enough progress, list it on your resume and start your job search (knowing you probably won't get a ton of attention.)

    As you complete more projects, make greater contributions, add those to your resume. Eventually you'll hit an inflection point where you have a enough projects listed to gain the confidence of a hiring manager. I wouldn't give up on the projects though - keep at it until you've landed your 3rd role, or you're at the 3-4 year mark of your career.

    Back to top

  8. What should I list under my education?
    Depending on where you are and what you've done, you can go with very little to a similar approach to your Professional Experience. If you have a few years of relevant professional experience it's already begun to outweigh your education - whether it's a bootcamp, or Comp Sci degree from MIT. Experience trumps all - but in the absence of experience, education is valuable.

    If you don't have much professional experience, list your degree/certification along your major/focus. Next list notable projects/assignments and again focus on the impact: what challenges did you encounter, what contributions did you make. Did you take an agile approach to those projects? Were you the scrum master? That's worth listing.

    Don't bother with the GPA, credits, hours, or course codes - but list other majors or minors.

    Back to top

  9. What if my degree/certification has nothing to do with coding?
    The honest answer is a CS degree is the preferred option - but it's not the end of the world if you don't have one. My own degree was a double major in Physics & Philosophy, with a Math minor. I faced challenges I probably wouldn't have had I had a CS degree. Over the years, a CS degree has been less of a hard-requirement - and bootcamps have proven the value of their certifications. But there's still no denying depth of understanding someone with a CS will have. 

    But if you don't have the CS degree, it's still worth listing what you pursued. There's still a lot of value in any kind of degree or certification and that hard work is worth touting. The key is, as always, highlight the right things: Outcomes and impact.
    Regardless of your path, you know what it means to handle multiple priorities. You've likely managed multiple deliverables, and had to deliver them on time. You've probably delt with ambiguous requirements. Maybe you worked in team settings and had to work around those challenges. Maybe you even worked a job or two while pursuing your degree.

    Lastly, if you don't have the CS degree - and still don't have professional experience - your Projects are all the more important to list.

    Back to top

  10. Should I list my GPA?
    No. Even if it's a 4.0, I wouldn't suggest it.

    The online application may ask for it. Your interviewer may ask what you had. Those are the appropriate times to share.

    As much as I stress providing outcomes, and impact, your GPA is a strange one. Having witnessed certain schools that will hand out 4.0s and straight As, I've put less stock in it. Even in the best cases, it has the tinge of being somewhat braggartly. 

    You should be proud of your academic achievements - and the GPA is an academic score. The GPA doesn't measure professional impact. Instead of focusing on the 4.0, focus on those outcomes and impact that got you the 4.0 - quantify those statements.

    For example, instead of:

    BSc in Computer Sciences from the University of Smartness - 4.0

    Try something like:

    BSc in Computer Sciences from the University of Smartness
    Senior Project optimized computer vision library to accurately identify models beyond 90% baseline. Results were published in department's academic journal.

    That's a contrived example, I'll admit. And what if you weren't some genius that completely redefined the world of Computer Science? Here's another example:

    BA in Fine Arts from the College of Creatives
    Created 5 new and unique sculptures for Senior Project that were put on display at a local gallery, including one 20+ person project I lead. Project was constrained by budget, marketed project and recruited participants in 3 weeks to complete project under budget and on time. 

    I can't stress it enough: outcomes, and impacts.

    Back to top

  11. Should I list my references, or state "References available upon request?"
    I wouldn't bother (and I don't bother on my own.) If references are needed, they'll be requested of you. Save the space.

    The exception is if you have a meaningful reference. Not a professor, not a friend, or even a former colleague. Only people who were hierarchically above you: a former team lead, a former manager, a former director.

    Not only are those people valuable references, but it also shows you're not the bridge-burning type.

    Back to top

  12. Why do I need to quantify things on my resume? What does that mean? How can I "quantify things" if I don't know the numbers? 
    If you're reading this in order, you'll have read that I earlier wrote: Quantify things. Numbers help keep your impact statements factual instead of subjective. They are measurable, they are meaningful. Go with the numbers that are objectively the best (dollars, timeframes, users, etc.) but if those are hard to determine, go with benchmarks: lead time, cycle time, performance time, speed/memory usage/disk usage, etc.
    Sometimes numbers are a part of the work we do: We're optimizing an area of the code base, and we want to know how well we've done - so we benchmark; Those are impactful numbers.

    But what if we don't know the numbers - what if we can't easily say how much revenue was earned because of our bug fix? What if we only have anecdotal evidence?

    In the professional world, you'll run into these types of problems every day. For example, what if you're trying to make a case about building a feature for a subset of users for whom you have no real data? You'd need to make inferences. These types of problems are known as Fermi Problems and it's a skill worth developing. Get better at measuring the unmeasurable.

    Make inferences: Maybe your company won't share revenue with you, and maybe you can't share confidential information - but you can find public information: Google Play will tell you that the $1.99 app you've worked on has had 500,000 downloads. Your feature may only be used by 10% of those users - so you've had a $100k impact.

    If you can't make inferences, look to measure your impact in other ways. Maybe the bug fix you released last week has resulted in an average of 30 less Service Desk tickets last week.

    Or extrapolate meaningful numbers from less meaningful numbers: Maybe you cut build times by 10 seconds. And your team of 20 builds 100 times each week. Maybe you can guess everyone's salary to be an average of $100,000/year. Knowing all that, you can now roughly quantify your impact.

    The point is the numbers are out there. Providing them not only shows the impact of your work but, importantly, that you're thinking about the impact of your work.
    Coders love accuracy, and while you should try to be as accurate as possible, that's not the goal. You're giving a scale, a sense of magnitude, a measure. Even if the number is seemingly low, it's still valuable because you're turning a subjective statement ("I made things faster") into an objective one ("I increased speeds by 2%").
    Numbers matter.

    Back to top

  13. How many pages should my resume I have?
    My personal opinion? 1 page. The general consensus I've had after surveying many other hiring managers? 1-2. The reality? 3 is probably fine too.

    My resume has ranged from 1-3 pages, and while I think 1 page will stand out the most and really help you distill your message, it's totally fine if you have more than 1 page.

    Whether you have 1 page, 2 or 3, the key is focus. When you're limited to 1 page EVERY. WORD. MATTERS. You'll be forced to summarize and cut out extra words. When you end up having is a surprisingly concise but very focused message.

    Back to top

  14. Can I have more than one resume?
    OK - so this is not a question I've ever been asked. I've added it as a rhetorical question, because no one says you must just have one. It's a good reminder - to have multiple resumes tailored to different pursuits and companies. You can have as many as it take - just make sure you track and organize them well, so you always apply with the most suitable resume.

    Back to top

  15. What links should I include on my resume, and should I have the URL or actual linked text?
    You should have your LinkedIn URL, GitHub and your Portfolio (assuming you have one, and you should... see below for more on portfolios...).

    I didn't really see the importance of including LinkedIn on resumes and never included it on mine. After surveying a bunch of hiring managers, I realized it was an oversight and I should include it going forward. It's a digital footprint and people like to see it.

    But instead of listing it as a hyperlink, provide the URL. People still print resumes. People still pass them around. People will sometimes load them into their own software and the link doesn't get parsed correctly. You don't need the full URL (skip the "https://www") and do your best to make the links as human-friendly as possible.

    Back to top

  16. Should I go with a modern design, or a traditional one? One or 2 columns? Colors or B&W?
    While the general consensus is no one is going to fault you for your resume design, there's preference for B&W traditional designs with 1 column.

    1 column is linear and, as I mentioned earlier, it prioritizes information in a hierarchical way. 2 columns ask the hiring manager to jump around - from the left column to the right. It's harder to track and retain.

    Colors aren't terrible, but make sure it can be printed in B&W and still be legible.

    My personal opinion: Go with an elegant and traditional black and white layout, but then showcase your personality with your LinkedIn, GitHub and Portfolio.

    Back to top

  17. Do I need to build an ATS-compliant resume?
    This one is a tricky one. Some places will have you believe that you 100%, absolutely, no doubt about it, need to have an ATS compliant resume.

    I think it really comes down to a few things:
    1. Where are you applying?
    2. How are you applying?
    3. What stage of your career are you in?

    If you're entry-level and having to blindly apply to hundreds of places, then having an ATS-compliant resume will probably help your odds in getting seen. But if you're being tactical about where and how you apply, you probably don't need to worry about it.

    It's true that a single entry-level coding job will get more than 200+ applicants - and that's at small companies. Bigger companies can be in the thousands. Sadly, the odds are not in your favor, and being ATS compliant will only increase those odds by so much.

    If you have the time, then it's worth making it compliant - but it's also not something to stress out about. In fact, I think there's better approaches to increasing your odds of getting seen.

    Back to top

  18. Should I lie on my resume, or embellish my experience?

    While the answer is obviously no, the concern I have is for the hundreds of coworkers & friends that I know are selling themselves short.

    Obviously, no honest person ever wants credit for someone else's success. But, if you're a naturally humble person, you're probably undervaluing the role you played in that person's success.

    Anyone who is part of a team, department, business unit, organization can never be independently successful. Success is a team effort - and everyone deserves the credit.

    When I think of my own successful projects - I was trained by my seniors, enabled by my leadership, supported by my direct reports, and strengthened by my peers. And I know I played a similar role for others.

    You shouldn't lie on your resume. But you absolutely should recognize your contributions towards success. Showcase it on resume, highlight it in an interview, share it on LinkedIn.

    And you might say: "But wait... yes, I helped, but I didn't do it all. I didn't have the experience to make those decisions. I can't make it look like it was all me."

    1. No one will think it was all you.
    2. You shouldn't pretend it was "all you."
    3. The experience you lacked is the experience you've now gained.
    4. The person in charge of decisions learned the same way as you. 

    It's as much your success as it was anyone else's on the team.

    The value of that experience is part of what makes it valuable. Celebrate it.


    Back to top

On Portfolios

  1. Do I really need a portfolio/websites?
    It really depends - but I'm hugely in favor of them. Resumes show me your professional side. Portfolios show case your personality, your interests. They give hiring managers a different sense of who you are, and how you are looking to grow.

    Of course, not everyone needs one - or has the desire to build one. I know many successful coders who don't have a portfolio/website and never needed one. In fact, most of the developers I know don't have one. And if that's the case, why do I push for them?

    The simple answer is it's an odds game. Tech Hiring is a wild world right now - there's lots of demand, lots of candidates, it's ultra-competitive but people are also struggling to find jobs. A portfolio isn't going to guarantee you land a job, but it gives you a meaningful edge over other candidates provided you do it right.
    Your portfolio doesn't have to be a huge undertaking - and because the benefits far outweigh the costs, I think building them makes a ton of sense.
    Because portfolios are personal, I think people get overwhelmed by "the art of the possible" - and then they never actually produce anything.

    If you build your portfolio iteratively, starting small, and only expanding as needed and as you have the time, it's a great way to establish yourself.

    For more, here are some resources on how to build yourself a killer portfolio:
    Back to top

  2. What do I even put on my portfolio?
    First off, know your audience. Your portfolio isn't for your friends, your family - your real audience is the hiring manager. You want to focus your content such that it's easy to consume - so focus on how you lay things out. Think of it as your resume + creativity. Add some style to it but make it usable.

    I'm a big fan of quick visuals that help someone get an impression of what you can do - so whether it's listing your languages, listing your years of experience with each, listing your projects, make it visual, interactive, but don't add any "friction" to it either. By that I mean, slow slideshows that require me to sit and wait for things to fade in and out is not a good approach. List it all so I can see it, consume it, and move on.

    Another thing is: give it some life. Don't make it look like you built it years ago and forgot about it - add some dynamic elements, so it's always looking fresh. Have it feed off your twitter, or just build a small integration into your blog, or just have a "micro-blog" that keeps people up to date on what you're working on.

    The main content is all around your projects. What have you built, what are you building. Include nice write ups that cover what you've learned, what challenged you, what you're proud of, what you'd do better. Impacts and Outcomes.

    This template I made is the bare minimum that you should list. It's all static, it has minimal design elements, but it really helps a hiring manager understand who you are:


    As you can see, the key things to list are:
    • The Tech Stack & Methodologies you know
    • A mini-bio
    • Important links - to your GitHub, your resume, your LinkedIn, 
    • Quick visuals that summarize your career
    • Projects, with the tech stack and links to GitHub
    • "Live" sections that you can easily update with what you're working on / reading (update these maybe once a month.)

    Like I said before, it should take you more than a weekend to build something like this and it'll help give your application that extra bit of edge.

    As you grow in your career, updating it becomes pretty trivial.

    Back to top

  3. Can't I just use GitHub?
    You can - yes. But don't just dump your projects on GitHub and call it a day. Build a proper GitHub landing page and use that as your portfolio.

    You can build it using GitHub Pages - just follow the same principles as I listed above.

    Back to top

  4. Should I get my own domain name?
    You don't need one - but having your own domain is like having your stationary. It's a nice touch.

    Back to top

  5. How personal should I get on my website? Should I share family photos? Recipes? A picture of my pet salamander?
    Share what you like - just ultimately know it's purpose. It's not meant to be a Facebook profile - but it's also not meant to be a LinkedIn profile either. Your audience would be a hiring manager. Help them get to know the social yet professional you.

    Back to top

  6. Should I worry about SEO, page ranks, etc.?
    No. That's over doing it. Keep your HTML clean - but don't stress over it either. 

    Back to top

  7. Should I include a downloadable resume / my email?
    That is ultimately up to you - but if you do include either, be weary of what information you make public. Maybe remove your phone number from your downloadable resume. Make sure your email provider will filter spam. 

    Alternatively, direct people to your LinkedIn or include a form where they can get in touch with you.

    Back to top

On GitHub

  1. What should my GitHub landing page look like?
    Write a simple ReadMe that mimics the content on your portfolio. Simple, clean and elegant. You're going to want to keep it up to date, so make sure you build it in such a way that it's minimal effort.

    Pin your projects and include important links to your portfolio/LinkedIn.

    You don't need to overdo it though. While there are some amazing ones out there, I think keeping it simple is the best approach (unless you are building this in lieu of a portfolio).

    For reference, here's my own GitHub landing page: GitHub - Alishah Novin 

    Back to top

  2. Do I need to really build out my project pages?
    Make sure you have a ReadMe file. You can do a lot with them - and I'd approach them as if you're writing it for other developers (secretly thinking about the hiring manager.) 

    In a professional setting you'll often need to explain what a product or feature does, how it should be used, what its limitations are, etc. This is your opportunity to showcase that to a hiring manager - so while you are writing it for other developers who will consume your project, remember your real audience is the hiring manager.

    Provide an overview, provide screenshots, provide a change log. Document things to show that you can communicate technical concepts.

    As another example, for reference, is my GitHub page for code / collision. Keep in mind, there are far better ones out there, but I built this page out to give a sense of what your bare minimum should look like.

    Do not just upload your project and call it a day.

    Back to top

  3. Do I need to worry about the quality of my code, or how much I've commented?
    Your code will be looked at, yes. People will look for comments and read them. They likely won't go into super detail, but you will want to make sure your code files are presentable.

    Treat it like you would a real project. Especially if you've improved an algorithm, make sure it appears in your commit comments.

    Hiring Managers probably won't sit there and dissect your code to make sure it's hyper-efficient - but they will look at it to get a sense of what you know/don't know.

    Be careful of over-engineering or writing over-complicated spaghetti code. In fact, try to reduce any code-smells.

    A great resource I like that helps you write super-presentable code is Refactoring and Design Patterns.

    Back to top

  4. Should I include my GitHub on my resume?
    Yes. As a URL not as linked text. Resumes get printed - and, so far as I know, you can't click a link on paper.

    Back to top

  5. Should I include my GitHub on my LinkedIn?
    Yes.

    Back to top

  6. Do I need to worry about how active my GitHub is?
    No. This is unnecessary pressure that we coders put on ourselves. We want the coveted wall of green. While having multiple daily commits is great, it's not going to guarantee you a job. Worry less about having a high frequency of commits, and instead worry more about having impactful commits: projects that show your evolution and growth as a developer. That may just be a few a month.

    On the flipside, make sure you don't have tons and tons of abandoned/unfinished projects. Have complete ideas - they can all be at various stages of completion, but don't have more than 2 projects that aren't at an MVP stage. Finish what you start. Sacrifice novelty for nuance.

    Back to top

  7. Should I include course projects?
    Coursework is only good in the absence of your own projects. Keep coursework visible until you have your own projects to stand on - then hide the assignments.

    Back to top

  8. Should I include all my projects?
    Only include those that are full and complete ideas - they don't have to be full products. I like to distinguish between projects and products. A "Product" is building full Twitter/Facebook clone. The size and scope of products can be so large you may never really complete it - and it won't serve you much good because it'll overwhelm the hiring manager.

    "Projects" are more discrete units of work. A library. An experiment.

    You should definitely share projects and include in your writeup what they were about - and what you tried to achieve.

    Include "Products" provided they're far enough along that they can stand on their own. If you never got beyond the log-in screen, then don't include it.

    I'll re-iterate (actually, I'm just copy & pasting): Make sure you don't have tons and tons of abandoned/unfinished projects. Have complete ideas - they can all be at various stages of completion, but don't have more than 2 projects that aren't at an MVP stage. Finish what you start. Sacrifice novelty for nuance.

    Back to top
On Applying & Job Hunting
  1. Should I include a cover letter?
    Only if it's asked for, or only if you have something compelling to say that is not immediately obvious in your resume. Maybe you have a direct connection with someone there. Maybe you're very familiar with one of the products. Maybe you achieved some kind of notable award or recognition that connects back to the company. Maybe you're uniquely suited for the specific role to which you're applying. Or maybe there's something in your resume you couldn't easily explain - a gap, a project.

    In other words: if you have nothing new to say, don't provide a cover letter. If you do write one keep it succinct.

    Back to top

  2. Should I apply to multiple roles at the same place?
    Large companies that have teams of internal recruiters won't mind. In fact, they'll often have portals that make it easy to do so. Even smaller companies won't care too much - but be mindful of what message you're sending.

    For example, at one smaller company I worked at I'd sometimes be hiring simultaneously for multiple roles that varied in their degree of technical skills needed. I'd hire for a coder, a QA person, a Technical Product Manager, etc. It can be confusing to see the same person apply to all those roles. At best it looks like the candidate is desperate, but at worst it looks like they are spamming (which happens a lot.)

    If you know enough about the company to know you are qualified for each role, address it head-on: in your cover letter (now you have a compelling reason!), in an email to the hiring manager, in your initial interview. 

    Of course, I say this when all the roles are significantly different such that they require a different set of skills. If all the roles are coding roles but for different products, different teams, or different languages there's no harm in applying to all the roles. 

    Back to top

  3. Should I apply for a different role under the same manager?
    This question assumes you already know the manager - or, alternatively maybe someone else told you about the role. In either case, it's a good idea to ask. There are different reasons why someone would prefer one approach over another and asking can give you insight into the hiring process. 

    Back to top

  4. Should I follow-up if I've not heard back?
    YES. Absolutely. Give it 24-48hrs. Be courteous, be forgiving, and don't be open-ended:

    "Hi Shawn,

    I really enjoyed our conversation the other day, and excited for the next steps! Of course, my timeline is flexible, but I'm curious if the team will be making their decision this week? If not, do you know when they're likely to make a decision?

    Alishah" 

    Back to top

  5. Should I connect with the hiring manager on LinkedIn before the interview?
    Look them up, get to know who they are, but hold off on the connection request.

    Back to top

  6. Should I connect with the hiring manager on LinkedIn after the interview?
    Ask them. There's no harm - but I'd also get a sense of how much they use the platform before doing so. If their profile and activity is pretty sparse, it doesn't make much sense to. If they're pretty active or look like you'd want to be connected to them even if you don't get the offer, then consider asking.

    Back to top

  7. How should I track places I've applied to?
    This is another one I've dropped in here. I've not been asked this question directly - but after learning how many people end up applying to 50+ places without ever tracking where they've applied, it's worth adding a fake question.

    There's a lot of great tools out there worth exploring - but even a simple spreadsheet will do just fine.

    Back to top

  8. How can I tell if I'm being ghosted? / Why aren't people getting back to me?
    Don't be afraid to follow up! You're likely not being ghosted. The sad truth is a lot of places are just bad at getting back to people on time. It's not intentional, and they should absolutely do a better job. I don't mean to offer these up as excuses, but there can often be a lot of things going on that have kept them from responding they're waiting on a decision/approval; they got pulled into an outage/major issue they're having to resolve; they've gotten sick; they're working on a project; they're hiring for multiple roles, and they're overloaded; they're unexpectedly had to take bereavement.

    While some of these are better excuses than others, the general point is you're not (always) being ignored. It's not personal.

    It's especially compounded when you're working through an internal or external recruiter who isn't directly responsible for the role. 

    Back to top

  9. How can I increase my odds of being noticed/being seen?
    This is a difficult one, because it can vary so much from location to location - and often times there's not much you can do.

    Let me start by emphasizing an obvious but easily overlooked point: it's less about getting attention and more about keeping attention when you do get it.

    So - first thing's first, focus on being the best candidate you can be - by that I mean, make sure your resume is great. Proofread it. Make sure you have a solid portfolio and a very comprehensive GitHub. Make sure your LinkedIn profile is polished and up to date.

    While that may seem obvious, let me explain the importance: most hiring managers will likely quickly sort resumes into one of 3 buckets: definitely interview, may interview, don't interview. If you don't fall into the 'definitely interview' it'll be a highly unlikely, you'll get a call. You want to make sure you fall into that first bucket.

    Of course, in the spirit of the question - let's say there's 300 applicants - how can you possibly get noticed to even fall into the definitely interview category?

    Timing is definitely important. Especially for roles with stiff competition, the sooner you apply the better. Second (and I can't stress this one enough) - if you know someone at the company, ideally on the team you'd work on, the better your odds.

    Companies love getting referrals from internal employees. So much so, they'll often give anywhere from $50-$1000 bonuses for referrals. Not only does a referral usually address some of the risk of hiring "an outsider," but getting a referral means the internal employee is investing themselves into the company. It's good for morale, it's good for cohesion. In short: companies will have a bias (conscious or otherwise) for referrals. They will ultimately make the best hire possible, but they're also more forgiving if they know someone has been referred.

    Often times, before a role gets posted, hiring managers will ask their team for referrals. In some cases, the job may never even get posted as a result.

    If you really want to get an edge - know people.
    Great advice, huh? "Know people." As unhelpful as those sounds, it's really not that bad. What I'm getting at is that all important idea of networking.
    If you make a point to build your network, especially in your local community, it'll really pay off. Connect with other coders, attend talks and events, get your name known. Work on building your technical reputation with those people. It doesn't take as much time as you may think, and it'll pay off in the long run.

    I glossed over something that I want to drill into a little further: build your technical reputation. There are some people that have built an amazing reputation with me despite my never having met them in person. We've messaged on LinkedIn, over Slack - or interacted on virtual meetups. And they always leave me a with a lasting impression of their progression. They tell me what they've been working on, what they're learning, the problems they've solved. If I've happened to give them advice or a suggestion, they'll often (not always) have something to say about it the next time I see them.

    These are people I've often first reached out to when I had a role that matched their tech stack. They're also the people I'll refer to others who are hiring.

    Also - get comfortable with non-technical people, especially in HR. This may require some extroversion, but the thing I love about people who work in HR is that many of them are highly EQ driven. They want to see people succeed; they want to see people grow. I've had so many people in HR make referrals in the past - they may not know always be able to assess technical ability but they're great at finding people who can help drive culture and build cohesion.

    All this requires time. Building a reputation and getting to know people is like any relationship/friendship. You can't enter into one with self-centered expectations. Yes, you may have a motive - but it's a long-term motive that is only realized with your genuine investment into the relationship. This approach may not get you a job in the first 6 months - but 2 years, 5 years on, it's the relationships that you've formed that will help you land the next one.

    Last point on this one: If you are currently working, or are in class, build relationships with your peers, and supervisors as well. As I said in the last paragraph, things take time - and in 5 years, some of your peers may be in positions where they may refer you. Likewise, you may one day be in a position to refer them.


    Back to top

  10. Should I work with a recruiter?
    Recruiters don't always have the best reputation. It's a tough gig and to be good at it you have to have spent a lot of time forming good relationships with developers (who don't pay you) so you can send them over to companies (who do pay you.)

    Recruiters get paid only when a candidate is hired - and it's usually a percentage of the candidate's baseline. That's great if you're extremely hirable because it means you'll make a high salary, and the recruiter will make a lot in placing you - but it can hurt you if you're starting off. Many companies don't want to pay the premium just to hire an entry-level candidate.

    A good recruiter can be really helpful because they know the good companies (if they send job seekers to the bad ones, that will hurt damage their reputation), and they can also help you sort out your strengths and weaknesses so you know where you can focus your attention. They can also give you the inside scoop of the company. Their motivation is generally aligned with yours: get you placed for top dollar.

    Good recruiters think long term: they build good relationships with good companies and good people. So even if timing isn't right today, they'll still be a good connection in the future.

    Bad recruiters, on the other hand, think in the short term: They will send you to roles that don't interest you, companies that are desperate (and there's usually a reason why they are...), or otherwise they're rushing through things while not being very communicative. 

    It's important to keep in mind, recruiters are just one avenue for your job search. Not all companies use them. Larger companies may have their own internal recruiting teams. Smaller companies don't have the budget to work with recruiters. Recruiters fit in the niche of companies big enough to pay for recruiting, but not big enough to make it in an in-house department.

    So yes, work with the good ones - but conduct your own job search too. And before working with any recruiter, get to know them and their reputation with the community.

    Back to top

  11. ATS resumes, LinkedIn Quick Apply, Recruiters... it's all very stressful. Why is it so overwhelming?
    Job hunting still is highly subjective. Everyone has advice (including me) and it's all on their own subjective experiences. None of the advice is guaranteed - and at the end of the day, it's how you are going to pay your bills. It's easy to feel like you're doing it on your own because it is a very personal problem.

    Despite that, I think there's value in knowing it's overwhelming for everyone. No matter your years experience, no matter the places you worked, or your polished resume - it is still a challenge.

    Job hunting is kind of like a skewed version of dating where being single isn't really an option. That sense of urgency makes it a challenge.

    That being said, the best advice I can offer is that you're playing the long game. In dating you can't really leverage your previous relationships - but that doesn't apply for the job hunt. As you build your connections and your network, as you gain experience through previous experience, you become more marketable. Because you're playing the long game you can make more short-term sacrifices because you know them to be short term. Overtime, as you become more valuable you are able to leverage that value.

    That overwhelming sense never completely goes away but if you do it right, you gain more confidence in yourself, the relationships you've built, and the track record you've formed.  

    Back to top

  12. Should I pursue a role that's different from my objective?
    I generally advise against it, especially if it's a large departure from your career goals. If you're a coder, don't pursue a QA role - but maybe consider the UI Developer role.

    I love the term "career narrative"- your goal is to be painting a picture over your career. Maybe you stayed at the same company, or maybe you switched roles every 18 months. Your career narrative is how you tell the linear story across it all.

    There's nothing wrong with a QA role - but if your aim is to be a coder, it puts a wrench in your narrative. It may make others question your eligibility and qualifications for the role you do want - and remember, your goal is to be in the "Definitely interview" bucket.

    That being said, we're not always in a position to wait for our dream role. Sometimes, after months of looking, we're in a spot where we have no other choice but to take the divergent path. If you're ever in that position, then I'd suggest making your intentions known to the hiring manager. Often times you'll find they have a clear need on their team, but in interest of getting good talent, they'll be more flexible about what the role entails. For example, they may need dedicated a dedicated QA role but they're willing to immerse you with the Dev team so that you can get the training and mentoring you need. They may even work out a plan with you: perform QA for the first 3 months, then as you get comfortable with the code base maybe you can resolve some bugs under the supervision of the Sr Dev. After 6 months, they may put you on a transition from QA to Dev but asking you to scale down your QA work over the next 6 months while they work out budgets. This will leave you with something compelling that aides your overall career narrative.

    Back to top
On Companies
  1. Should I consider a start up?
    Yes! Start-ups are extremely exciting places that offer a lot of valuable experience at the cost of additional challenges, risk, and demands. You get exposed to so much more than you would at a larger company, and you have a lot less red tape.

    Depending on how much risk you can stomach, find a start-up that has adequate funding so that you don't have to worry about the budget running dry. If the start-up is a B2B (a company whose customer is other businesses), it's best if they already have a some paying customers and an active sales pipeline (I've worked at start-ups that had as few as 3 and as many as 1,000 - with a few that ranged in between.) If the start-up's primary customer is an individual consumer, you'll want to at least be sure they have an established revenue stream and adequate funding.

    Start-ups come at all different stages - so assuming you can stomach the risk, the next thing to do is get a sense of what areas you'll participate in. Will you strictly be coding, or will you act as a Sales Engineer at any point? Will you also be doing QA? Responsible for infrastructure & DevOps? Get a sense of where they need you as a resource so you can determine whether it's for you.

    Back to top

  2. What challenges exist in a small company, medium company, large company?
    It's wrong to think you're ever "safe" at one company or another. There are plenty of horror stories as companies of all sizes - and from people who are well skilled.

    Generally speaking, your roles and responsibilities are inversely proportional to the size of the company. The smaller it is, the more they'll have asked you to play a broader role. The larger it is, the more the role aligns directly to your title.

    The larger a company is the slower it moves. There's plenty more red-tape and internal politics - but you also have the opportunity to work at a scale much larger than you would at a smaller company. Your contribution is, however, smaller. With a smaller company you have a voice and say in more and have a closer connection to the company's mission and its customers.

    Benefits will also vary - but not in a predictable way. I've seen both large and small companies that give great benefits and have better work/life balance - it's a question of leadership.

    I recommend it all. You'll definitely find one that suits you more - and what you find suits you will also change with time. 

    Back to top

  3. Am I missing out on anything by being fully remote?
    Just about everyone out there has an opinion on in-person vs remote work. It's all a trade-off. Personally, I've found that remote work definitely creates more flexibility, but it also makes it more difficult to form stronger connections and build up your network (which I'm big on.)
    Being in-person allows you to collaborate and learn more organically. I've learned a lot from just hearing what others were struggling with or what they'd solved - and not when they formally present it to the group, but when they're in the thick of it.

    Especially when you're starting off, it's incredibly helpful to be immersed with other coders and collaborating with them. It's also likely that your good work is more likely to get noticed and praised. 

    As with everything though - it's not for everyone, and especially if you've been hired as a remote employee, it's almost impossible.

    If you are remote (and don't have much positive experiences from being in person), I'd encourage you to be aware of what you could be missing out on and consciously make the effort to supplement those: get connected with your community, get a mentor, talk to the seniors on your team more regularly, participate in the technical chat rooms on your Slack or Teams.

    Back to top

  4. Someone pitched me an idea and can't pay me but will be a reference to me. Should I pursue it?
    I hear about this a lot - and while it sounds like you're getting "paid with exposure" I'd treat it like you would any personal project. Provided you don't overcommit to where you can't work on your own projects, then pursue it. You may want to ask for an equity stake in whatever is being built - but what I definitely would encourage avoiding is doing free work for a brand-new company that is just getting started that isn't offering any equity. Yes, I've heard of this happening and no, it didn't end well.

    Back to top
On Interviews
  1. How should I prepare for my technical interview?
    There are so many great resources out there these days that not only help you refresh your technical skills, but also help you improve how you interact with the interviewer. Many technical interviews are just as much about the coding as they are about the collaboration and discussion.

    A couple of books I strongly recommend checking out are: 

    Both these books will give you tons of common questions and ideas for how to approach them. I wouldn't memorize these questions though - a lot of hiring managers come up with their own questions. It's all about the approach, but the questions make for good practice.

    But: practice. Practice by yourself, practice with your friends, practice with your mentor. Practice using online resources. But also - practice with someone who isn't technical. Ask them to pick a coding question and ask you to do it. Then ask for their impressions. While they can't measure your technical response, they'll be great at providing you clear feedback on how you handled the collaborative/conversational aspect.

    Back to top

  2. Are all interviews going to be white board/virtual coding sessions?
    No. Sometimes you get a white board, sometimes it's using an online tool, sometimes it's a theoretical question that you need to talk through. And sometimes, the technical interview is very different.

    Companies are always exploring good ways to assess someone's technical ability - I'd recommend sticking to these basics:
    1. Practice coding questions relevant to your stack/role; Try all kinds of problems, but don't just focus on getting the answer. Focus on why the answer works. Generalize the solution: did you introduce something new, did you transform things, did you solve a simpler version first, etc. These are little tools for your toolbelt. If you run into a question you don't know, consider it from those angles.
    2. Practice thinking out-loud. Make sure you understand the problem. Make sure you demonstrate understanding of the problem. Practice finding areas that could use clarity. Practice finding the edge cases and talking through them.
    3. Be comfortable with saying you don't know how to answer something, but don't stop there. You've encountered problems you couldn't answer before - what did you do? Talk through what you do when you run into a problem you've never seen before.
    4. Remember the technical interview is not just testing your technical abilities. They're also watching your soft skills.

    Back to top

  3. How should I introduce myself at the beginning of an interview?
    Another question that's not been asked, but I needed to include. For years and years, I've started every interview the same way. I've told candidates I want to hear about them first - to get to know them and who they are, and to tell me about themselves, to shamelessly brag about themselves and their accomplishments without fear of judgement. I've had great responses, and I've had terrible responses.

    I'm always surprised when people struggle to talk about themselves. Some people are shy, some people are anxious, some people are very humble - they're not the ones I'm talking about. It's the people who say a lot while saying very little. They overshare in the wrong areas, under share in the right areas, and otherwise seem like they're generally unfamiliar with their own careers.

    My advice is to get good at summarizing your career into something you can say succinctly in no more than 2 minutes. But don't just summarize it by rattling off a timeline of events. Synthesize your story and build it around common themes. What is your career narrative? How are all those events connected so that they make sense? What are some unique qualities about YOU that you want to highlight?

    For example...

    Interviewer: So, tell me about yourself...
    Interviewee: Sure - so I've been coding for 9 months now. I just completed a bootcamp, so I'm really only getting started out. But how I wound up at the bootcamp is pretty interesting. I've always been pretty technical. I built my first gaming PC when I was 11, and I'm the guy everyone calls when something on their computer or tablet isn't working right. I think it's because I really like to get to the root of issues and understand the technical reasons for why something is failing. Before the bootcamp, I was a team lead at Olive You Glad I Ordered Pizza. It may seem pretty far from being technical, but because we're a small pizzeria we didn't have an online ordering system. We only took phone orders - and I was feeling that we were less efficient than we needed to be. I started to Google some strategies and landed on Kanban and Lean principles and I realized it could really help us out. So, while I implemented that with our team, I also started tumbling down the rabbit hole of Lean development and the Agile principles. Long story short, the bootcamp's program coordinator was ordering pizza and we got to talking - and I realized I had to start coding. I've loved it since. While I've not had any professional coding experience, I think I've been a coder all along.

    Back to top

  4. What questions should I ask at the end of an interview?
    First, please, have a few questions. It's such a great opportunity to stand out, and to just shake your head and say "No questions, I'm good..." is such a missed chance.

    You can ask about the role, challenges, why they're hiring for your role, was it a backfill or a new role, who are some of the people you'll be working with, the size of the team, some of the major challenges they team is struggling with. Ask about the product, ask about the tech stack, the methodologies being used, the size of the backlog, the structure/format of dev meetings, the opportunity to learn, mentorship opportunities, how work is prioritized, the QA process, the users.

    You can also ask the hiring manager about themselves: how often will you work together, what their approach is to management, one on ones, growth, what skills do they most value in employees.

    You can extend the same line of questions to the department or company leadership. 

    You can ask about Covid: How did you all adapt in the early days of Covid? What were some of the challenges? How have you worked through them? How did you maintain a baseline of productivity with people being remote? Has Covid shifted any priorities for the product/business/team?

    There's so much opportunity to ask exciting questions - bonus if you can come up with a question based off something that was discussed during the interview. The more relevant your question is, the better.

    Finally remember there's such thing as Recency Bias; a bias which favors recent events over historic ones. In other words, how you end your interview can be more important than how you started it. 

    Back to top
On Managers
  1. How often should I be meeting with my manager?
    You should have regularly scheduled one-on-ones. No less than once every 2 weeks, but ideally once a week. Regular meetings are crucial to tracking how are you doing so that you're set when performance reviews come around.

    Back to top

  2. What should we be talking about when we meet?
    Don't have a status meeting. Don't give an update on the project you're working on. If your manager seems to mostly focus on whatever work is currently in flight, ask them if you can also discuss your overall performance.

    1:1s are great times to talk about your objectives, how you're growing, where you think you're weakest, where you want to be in 6 months, 1 year, 3 years. It's also a good time to focus on areas that are normally outside your purview. Maybe you've identified an inefficiency - or maybe you've felt someone else isn't fully performing to the best of their ability. While you want the main focus of your 1:1 time to be with your manager, you also want to make sure that you're both on the same page come performance review time. If you're having candid conversations regularly there should be no surprises.

    Feel comfortable with even asking, very plainly: "How am I doing?" or "Is there something I should be doing that I've not been doing?" or "Where am I weakest? What should I focus on learning/growing?"

    These questions are direct, and some managers have a hard time with candid and honest criticisms, even if it's constructive and actively being requested. Don't be afraid to ask for it a few times. In the absence of a meaningful answer, give your own. "Well, it's great to hear you think so - but here's what I'm trying to learn on my own. Would love to get your thoughts..." 

    Back to top

  3. I'm not sure my manager is invested in my growth, or really knows me. What should I do?
    Not all managers will be invested in your growth, and you don't need their investment in order to grow. Of course, when they are invested it can be really rewarding - but I've also learned and grown a lot under managers who only cared about results.

    It's ultimately a matter of your own perspective and how you apply yourself to different challenges. You'll always encounter people who are difficult. Learning to work with different styles will greatly help you.

    Case in point, I once had a manager who never provided feedback. Neither positive or negative. No criticisms, ever. Given that I was still pretty junior at the time, I needed the feedback but wasn't getting it. Eventually, I grew to realize how he communicated expectations and how he measured quality. I got there by mostly observing his interactions with others. He had the habit of casually talking around problems and ambiguously assigning ownership and accountability. But I clued into the fact that if he wasn't talking about something - that generally meant he was good with it.

    I'm not defending the style, and it definitely was a struggle - but I couldn't easily change his style, nor could I easily change managers.

    Most importantly, after learning his style - it became as effective for me as anyone who was more explicit. Once you decode an illusion, it never fools you. As a result, years later I had a manager with a very similar style. That manager was largely disliked by the team - but yet, having cracked the code with a different manager, I was successful with them.

    That's one approach.

    Other managers are a lot more receptive to criticism and suggestions. Especially if they're early in their management careers, they are learning how to adjust from an individual contributor to a manager. They need help in learning that people are their priority. Managers can learn a lot about their role from their team members, and that's where the 1:1 can be really valuable. 

    The Manager's Path talks about how, to be a good manager, you should learn how to be managed. The sad truth is many managers learned poor management from their own managers. Learning to manage upwards by setting expectations and communicating openly will help you - whether it's with respect to your code, the product you're producing, your own growth. The more you relate it all back to relationships with people (and not roles), the more successful you become. 

    Back to top

  4. I feel like my manager isn't being very transparent. What should I do about that?
    Being a manager comes with a lot of difficult responsibility. You're made aware of different challenges and risks, and you have to carefully navigate the space while being accessible and honest with your team. Full 100% transparency may sound ideal, but it can actually create more chaos than you may want. 

    As a manager you learn about budgets, customer attrition, business challenges. Managing through those circumstances is a balancing act. Sharing too much (in the interest of transparency) can create chaos and uncertainty in the team's life. Sharing too little creates a sense of distrust. Saying "Trust me, things are good..." also creates distrust.

    Hearing "We're about to lose our highest paying client..." doesn't help anyone. It's speculative, for one. Stating things in these terms creates chaos, stress, anxiety, and uncertainty. No one does their best work when they're hearing that kind of news.

    2 weeks later, the manager may then update everyone with "Great news! They've signed on for 2 more years!" Or they may say: "I called it. Yeah, we lost them. This is going to impact our budget..." Managers who try to be fully transparent create distracting emotional roller coasters.

    A good manager will address lingering concerns or suspicions while doing their best to avoid introducing unnecessary chaos. They focus on facts and share them as they materialize. They'll avoid speculating or editorializing.

    If, in the earlier example, the team begins sensing something is going on a good manager will step in to say: "I know you've noticed the stress the sales team has had lately. They're dealing with frustrations from our largest customer - the current experience is slowing them down. We're working closely with them to get a better idea of how we can address those issues. You may see me get pulled into a few urgent calls - but to be clear, this is a priority for me, not for you all. I'll let you know if/when it ever needs your attention. For now it's too high level to be worth distracting any of you guys with it."
    Someone on the team may ask: "Are they cancelling their contract with us?"
    And the manager would say: "That's too speculative. Right now, we're still looking to understand the gap in expectations. Keep building against the backlog because that work has been vetted and prioritized. If priorities shift, you'll be part of the conversation."
    Managers are often asked questions that require their speculation, and that can also be difficult. "Will we hire for more roles next year?" or "Are we going to get the investment we need from the business?" or "Will we have the budget for me to get a raise?"
    Good managers won't give concrete answers to those questions and will probably give you the answer you are expecting: "It depends."
    My recommendation is, if you're seeking transparency, ask questions that they can answer honestly and without speculation: "How am I tracking against my yearly objectives?" or "Will you be asking for additional headcount next year?" A safe follow-up could be "What if we don't get the additional headcount?" This last question isn't asking your manager to speculate; it's asking them to share their contingency plan.

    Back to top

  5. How should I ask for a raise?
    First off, do some research. It's often true that job-hopping will also increase your salary faster than staying at the same place - but it can also damage your reputation if you hop around too frequently. A lot of companies have a 3-6 month ramp up. If you leave shortly after a year, or even at the national average of 18-24 months, your contribution will be pretty minimal. (Incidentally, if you're worried about handling attrition, you should check out my primer on Systems Debt.)

    Leaving too soon means it's harder to share our outcomes and impacts on your resume. You're not giving yourself enough time to be successful - and eventually the hopping will catch up to you.

    So, do some research. Find out what you could make if you were to leave, but also find out what you should be making if you stay. It could be less - but it shouldn't be below the average of what people make at your level.

    Next, track your work and progress over the year. Start at the beginning of the year - don't wait until the end of the year to quickly summarize it all.

    Instead, keep a running log of your "wins" and contributions, and use your 1:1s & quarterly check-ins to talk through those and show your progression.

    It's good to be aware: many managers suffer from recency bias when doing annual reviews. If you had a strong first half of the year, but then later slowed down, they'll remember the slow down. On the flip side, if you were lazy in the first part of the year but really applied yourself in the later half, they'll likely forget your laziness. (That being said, I wouldn't advise being lazy if you're going to ask for a raise...)

    Don't track your progression in a vacuum. Keep your manager informed and involved so you don't unload a long list of wins at year's end. Instead, go into 1:1s and mention a recent accomplishment. Ask them to break down for you what you could have done better, if they believe you can take on a larger challenge, etc. Make them a part of the discussion.

    The easiest raises I've given as a manager is when all the work was done for me. I didn't feel like I had to advocate for someone out of the blue. Instead, I could be talking about someone's progression on my own 1:1s. I could be prepping my own manager for the inevitable ask: "Sally finished that one major project ahead of schedule - and not only that, but she's also continued to grow beyond her current role. Just giving you the heads up - when we do annual reviews in 4 months, I'll probably be looking to promote her and give her a raise. At the pace she's growing, I don't see us retaining her if we don't recognize her work."
    In a nutshell, when you're asking for a raise - plan early to be asking for a raise and know that you're not asking your manager for the raise. You're helping your manager get you a raise.

    Back to top
On Growth & Career Progression
  1. When should I leave my current role?
    I'll often point to a study that shows tech professionals stay with a company for 18-24 months before looking for their next role. I've seen this number a few times, and it's also been an anecdotal observation as well.

    If you think of that period, it generally makes sense: 18-24 months is long enough to have shipped some meaningful projects, it's also long enough to burn out, grow bored, start re-evaluating your priorities. Maybe you got married? Maybe you had your first child? Maybe you bought a house? A lot can happen in 18 months, and even more in 24.

    Incidentally, if you're a manager, isn't it funny how we'll ask candidates about their 3 year goals, and then we're surprised when half that time passes, and people leave? It's almost as if...we've...not...actually...invested...in...them....

    Anyway, does this mean you need to leave at 18 months? Not at all. In fact, I don't think you should unless you're not getting the support you need. I've stated this in another response to a question, but I'll re-state it here: if it takes you 3-6 months to ramp up at company, and you leave at 18 months, that only gives you 12-15 months to have made a meaningful contribution. It's definitely possible to do that - but your opportunity is lower, and your impact is less measurable. Plus, you never want to be the candidate who is ditching their team in the midst of a super big project that is nearing release. I've seen many candidates who are on the cusp of delivery - and unless they have a compelling case for why they are leaving, it can be a red flag.

    The thing is: getting a project over the goal line is tough. The first few months are super exciting, but that excitement decreases quickly and then it's a slog. You start to encounter bugs, things you had beautifully designed have become to get cluttered and sloppy. You've had to cut corners. You're increasingly less proud of what you're delivering and quicker to pass the work on to others. You lose the desire to see it through. While tackling this problem is worth a separate article - the simple point is that there's lots of value in seeing a project through.

    If you're getting antsy and want to leave, ask yourself why. You may be unhappy with the company, or maybe the work has lost its novelty. If you struggle with that, and always get distracted by bright and shiny new toys, try to learn to trade novelty with nuance. As you learn to appreciate nuance, projects remain appealing. You start to broaden your perspective around problems and come up with new solutions. The experience you gain from getting a project released is huge - and it'll help you fight the feeling the second time you butt up against it.

    So, when should you leave? Either when:
    1. You're in a toxic, unprofessional, negative environment.
    2. Your growth has been stunted, or you're hearing false promise after false promise,
    3. You're being drastically underpaid/underappreciated,
    4. You've stopped learning,
    5. An amazing opportunity has come your way that you can't pass up,
    6. Your personal priorities have shifted

    The important thing is to always try to leave on good terms. Don't burn bridges, keep connected with the supportive people. You probably won't return to that company, but those people will help you build your network.

    Back to top

  2. Am I networking correctly?
    What do you expect to get out of your network? If you have an answer to that, then you're doing it wrong.

    Your network is made up of professional friendships - and any good friendship doesn't come with expectations. They're supportive, they're genuine, and they may or may never have a big pay-off. Your goal, with any kind of friendship, is friendship. If any other benefit comes out of it, that's just an unplanned perk.

    The larger (and more genuine) your network, the greater the odds of realizing some kind of perk - maybe a connection into a company you've always wanted to work at, maybe a connection to a mentor, maybe you can learn from them, they become a resource, whatever - but you can't make that your end goal and you have to be willing to provide similar perks for others.

    Connect with people because we are social creatures (even the introverts), and we long ago realized that there's power in connections.

    Reach out to people on LinkedIn, at virtual events, at live events - and have genuine (non-needs-based) conversations.

    Back to top

  3. What personality traits should I highlight, emphasize, grow?
    This one is an easy one: Growth. Have a growth mind-set. Embrace and be empowered by the fact that you don't know everything, but that you can learn it. Be a forever learner. Be interested in things.

    Skill is important, but candidates who also convey that they're continuously looking at how to grow are the best hires.

    You can learn new tech stacks, new methodologies, no paradigms and technical concepts. But there's so much more about that. Learn about productivity methods, learn about leadership, learn about management skills (even if you don't want to manage), learn about the industry you're in, learn about your product, its history. People who learn have infectious enthusiasm.

    Share what you're learning. Learning is the one thing that you can unabashedly brag about. I personally love learning, and I love being taught things. When someone teaches you something, you see them light up with energy and passion.

    Lastly, and critically: the opposite of a learner is someone who is stubbornly stuck in the same spot, refusing to budge. Don't be that.

    Back to top

  4. Do I need to constantly be coding?
    Not constantly. There's lots of people who have had successful careers and only code at work. It can definitely help you grow your skills, it can definitely help you stand out as a job candidate, it can definitely help you keep your skills sharp when you start to code less professionally (yes it will happen, even if you stay a coder.)

    Don't just read theory, put it to practice. Even if to get a sense of how it works. 

    Back to top

  5. When should I become a Jr/Intermediate/Senior?
    While this is not too different from the earlier question - but there's something important I want to highlight with this question: There is no right answer, and so there are so many things it depends on. Ultimately, the best answer I can give it should be a question you consider without pressure or a sense that you're behind.

    There are so many factors that determine seniority - and one org's senior is another's junior. There have been times in my career where I took an intentional step backward (in terms of title) while still growing my skillset so that it can ultimately give me more opportunity to take larger steps forward.

    It's an easy trap to fall in - comparing yourself to your peers, to others who seem less skilled but have bigger titles. But focus on your own interest, your own talents, your own career narrative. 

    Titles aren't always an accurate portrayal of skill - but more importantly, titles aren't universal. The best way to think of a title is how the title applies to the current problem space you're in. I'm confident in my abilities as a Senior Engineer, Engineering Manager and Director. I'm growing as a Product Manager. But if tomorrow I decided to be in Marketing, I'd want to be a Junior. Similarly - while I'm confident an Engineering Director, my expertise is in a specific scope. There are different kinds of Engineering Directors - whether you're at a SaaS company, start-up, enterprise, whether you're mature with your DevOps, or you're selling packaged software. 

    At the end of the day - there is no real "race." You're racing against yourself - but the key is to be asking yourself where you want to be and what you want to be doing.

    Back to top

  6. What books should I read?
    There are so many great books out there - and in the interest of being a forever learner, you should read more than what I've listed here. These books have had a profound impact on my own career, and I'm always quick to share them:


    Have others you'd recommend? Send them my way!

    Back to top
It's worth noting, all these responses are my own subjective views that I've generalized across small and large companies. They reflect my personal style, but I'll also happily submit they're not 100% right either. It's what's worked for me - but I love getting input and thoughts from others.

Have any questions I haven't answered? Connect with me on LinkedIn and send them to me!

Popular

Let's Clear Up The Ambiguity!

Image
Job seeking is hard - especially when you factor the ambiguity around expectations, the lack of transparency and consistency around process. It's frustrating dealing with the sheer subjectivity of everyone's opinions. Just think of even the basics: How long should your resume really be? Traditional black and white, or modern? Should you include a headshot? Oh - and cover letters - are those needed? Is anyone actually reading the cover letter? What are they looking for? Is there a bias for people with a more traditional background? Worst of all: The dreaded typo  that you catch only after applying to your dream job.  Are typos really going to cost you the opportunity??? To help bring some clarity to the process, I surveyed a bunch of hiring managers. The results were really interesting, and very illuminating.     If you're on the job hunt, I hope this information helps out! One final note: My recent post,  7 Steps to Writing an Amazing Resume , factors a lot of this feedba
Read more

7 Steps to Writing an Amazing Resume

Image
  Since sharing my resume template  I've received plenty of feedback from job seekers, HR and hiring managers - all of whom value its purpose. Two (now former!) jobseekers even shared that as soon as they used my template, they were getting calls. Something about this template works, and given the traction it's getting others, I wanted to share - in more detail - why  this approach works so well.  Before continuing, let me give an important disclaimer: This resume isn't a miracle cure that's going to land anyone their dream job. Unless they're filled with lies, resumes are only as good as the candidate themselves. But they can also be a whole lot worse. This template and approach are all about maximizing the potential candidates have by highlighting and summarizing key areas.  Last point before beginning: If you don't know me, it's worth stating this advice comes from more than a decade of having hiring a broad range of coders: straight out of college, high
Read more

7 Steps to Building your Portfolio MVP

Image
Often when I suggest to coders that they build a portfolio, I'll hear back: "I don't need one..." "With all the effort it takes to apply, where will I find the time?" Simply put, having a portfolio's never going to hurt your chances at landing a job - it can only help. That second question is where a lot of struggle - because applying to jobs can be time consuming. Especially if you're wrapping up a bootcamp, or having to manually type in your resume info after uploading your resume. That's why I made these 7 steps which, when done correctly, can really help you stand out with a hiring manager. And, the best part is, it should only take you 2 days. Being the Agile-Obsessive that I am, it's all about maximizing value while minimizing effort. Fix links to your Resume, GitHub, LinkedIn, etc. at the top where they're always accessible. Link to everything here - and then remove all other links on your Resume except your Portfolio link . It sa
Read more

Work Experience vs Professional Experience

Image
In reviewing a bunch of resumes this week, I noticed quite a lot of resumes with a  "Work Experience"  section. In each of those resumes, people had de-valuing some very valuable  experience - and I write that with no exaggeration. The problem is people were looking at their experience purely through the "Job Title/Relevancy" lens and had reduced their experience down to a list of discrete, random, disconnected jobs. No interconnectedness, no narrative thread weaving through it all. As much as you may feel some jobs have no way of being connected, the reality is  you   are always the connection . To not connect them on your resume is to lose all that growth, knowledge, skills, impact, value, and trajectory. In other words - you lose the " You " in the resume. I recommended they start with a small change. Reword "Work Experience" to "Professional Experience" because, ultimately, every single job they had was in service of building their
Read more