Why We Should Stop Talking About Imposter Syndrome In Tech

Last week, my Virtual Coffee small group had a great conversation about imposter syndrome. I had wanted to talk about it because I had seen a request for an imposter syndrome channel in Slack and I didn’t think it would be a healthy choice. So I had some hot takes, which I am now bringing to my blog. First up, let’s define imposter syndrome. Merriam-Webster defines it as:

a false and sometimes crippling belief that one's successes are the product of luck or fraud rather than skill

Historically, this has been a phenomenon seen in high achieving women, which, as HBR noted, is likely due to the negative feedback that women regularly receive. So why does it seem like everyone in tech (particularly developers) have imposter syndrome now? Well, strap in, because I’ve got some hot takes coming your way!

1. People commonly use the term when referring to junior/early-career developers. This is pretty wild to me! If you are early in your career, you, by definition, have not really had any success as a developer! You are just getting started. I think Kim Crayton described this well in a talk she gave on mentoring at PyCaribbean in 2017 (quote is slightly paraphrased):

Learners do not have imposter syndrome. Imposter syndrome is people who have senior level skills and still don’t think they can do a job. Imposter syndrome is not learning. Learning is hard. Learning takes time. You don’t look at a baby who’s just been born and can’t flip over and tell them they’re suffering from imposter syndrome. No you’re not, you just don’t know how to flip over yet! That sounds absurd right?

With that in mind, maybe stop telling junior developers they have imposter syndrome. They are learning! They should not be expected to know everything.

2. Our job descriptions are absurd. I’m pretty happy with my current company (hey come work with us at Splice) because we don’t have 20 different technologies in our job description. HOWEVER: most job descriptions ask for multiple years of experience in both a backend language and frontend framework, Docker, AWS/Azure/Google Cloud, Kubernetes, GraphQL, etc. And you will see that on job descriptions that are not for senior developers. This is especially fraught for early-career devs, who regularly see non-senior posts that are still asking for all of those and 5+ years of experience which makes the job search seem hopeless. Let’s be more realistic with what we need versus what it’s more acceptable to learn on the job.

3. Interviews are an absolute nightmare. If you want to feel terrible about yourself, interview as a developer. At almost any level, you will be told by at least one company that you “aren’t senior enough” or “aren’t technical enough.” The way most companies do interviews also makes it feel way more like it is a personal failing on your part rather than just you and that job not being a great fit (which is actually the case). For example, I have had a broad swath of experience which has enabled me to jump into almost any codebase and be able to figure out (roughly) what’s going on and be able to make improvements. But I do not have experience building applications at scale. If we are being honest, very few people do. If you are at a large company that’s at that scale, you are likely part of a larger team and not making big architectural decisions. Or you might be at a smaller company and maybe have to scale from 100 to 1000, but not any further. Or, like me, you could have spent a decent portion of your career at B2B companies that do not have a ton of users. So why are we making people feel like they suck for just not being the right fit at your company? Maybe we should treat each other better.

4. To that point: talking about imposter syndrome makes it an individual problem. The problem is not with the individual! The problem is how we, as a community of developers, are treating each other. Instead of helping each other grow and lifting each other up, we are constantly putting others down to make sure it’s clear that we are the better developer. There are a ton of jobs! There is room for so many great developers. We do not have to compete in this way.

5. Is talking with others about imposter syndrome actually helping anyone? I think in some ways, it’s nice to feel like you aren’t alone! But when I see people with way more experience than me say that they are also struggling with imposter syndrome, it makes me feel hopeless. Like there is never going to be a point in my career where I can feel confident in my abilities. I can’t imagine what early-career devs are feeling when they see more accomplished developers also struggling. I think talking about it has made it way more of a thing than it should be. Everyone is sad sometimes, but not everyone suffers from depression. Everyone has times that they doubt their abilities, but not everyone has imposter syndrome. But we are at a point where, if you doubt your abilities, you have imposter syndrome. I think this is a bit absurd! It’s turning a normal human experience into a problem that you must solve.

Always happy to talk more about this and am also interested in any other hot takes!

Why I Didn't Speak Up Earlier

My former employer is having a very bad week. I worked at Mailchimp from March 2011 to November 2012. I wrote an anonymized version of the latter part of my experience already. I talked to the reporter for the Business Insider story, and it’s likely to come out soon. I opted not to be anonymous. During this process, he asked me two questions that made me think and want to write a bit more about my own perspective.

1. Did you talk to your coworkers about salaries?

2. Do you have any documentation of reports you made?

The answer to both of those is no. I’m going to dig into each one by one.

I grew up being told that you should not discuss salaries. I even thought it was illegal, or I could get in trouble for it! Even a few years ago, I was onboarding for a job and the HR person said pay was something we could not talk about, other than to our manager. Just in case you don’t know: in the United States, you are legally protected when discussing salaries with coworkers. It is in your best interest to discuss salaries with coworkers. Keeping quiet about salaries increases pay inequality. However, I was 24 when I started at Mailchimp, it was my second job out of college, and I had no idea. I was the only woman in engineering and I was paid $45,000. The excuse for the low pay was that I didn’t have any experience… but the role was for a deliverability engineer, which is a role that only exists at email service providers and internet service providers. There are still not many of those and there were even fewer in 2011… especially in the Atlanta area. The other guy in my department only had one year of experience, only at Mailchimp. I had an engineering degree and almost a year working in IT at Home Depot. Given that I know know that entry-level support made $35,000, I do not doubt that I was the lowest-paid engineer by far. I wish I had talked about salaries with my coworkers then and even in later roles because it took me years to realize that I was being underpaid. I think another reason Mailchimp gets away with this is that, for many people, it’s their first professional job and it’s just great to have healthcare. But given how much money Ben and Dan have made off the backs of their poorly-treated support team, I think they could have easily paid their employees a bit more.

As far as documentation, there is no documentation from me because I never made an official report. One of my coworkers would lift his shirt a bit in meetings, scratch his stomach, and stare at me. It was unnerving and very creepy. Why didn’t I report that? Well, everyone was aware he was creepy. I was young and we were all “friends”. Why would I report a friend? Plus, everyone knew he was a creep, so obviously, he wasn’t doing anything wrong, right? Looking back, I think it felt like someone else should have come in to fix it, but there was no one else. All I felt I could do was ask my boss not to make me share an office with the guy. One day while we were all (at least 20 people) eating lunch, another guy on my team decided to start debating what makes a person. Then he posed the question, “Are people with Down’s Syndrome really people? They have an extra chromosome, so if DNA makes a human, do they count?” I was pretty dismayed, mentioned that was inappropriate, but didn’t do anything beyond that. There were managers in that room; if it could be acted on, they would surely do something. That man is now a manager at Mailchimp. He is also the person who made it so uncomfortable for me to work there that I moved up to Boston with the first job I could get and a full 6 months earlier than I planned.

So why didn’t I speak up earlier? Like many people, I felt like Mailchimp had an outsized influence on my career. I was worried that, if I said anything against them, it would be a black mark against me. Even after I moved states… twice. Even now, I was hesitant. It also felt like, on an overall scale, it wasn’t that bad, right? I was never propositioned or assaulted, A+ for that. And yet… in all the companies I have worked for, Mailchimp still stands out as the place that feels the most problematic (other than the super tiny vegan startup that shall not be named), even almost 9 years later.

Questions to Ask During An Interview

I've had a lot of jobs, and, over the years, I've been refining my list of questions to do my best to ensure that the company I'm interviewing at is a good fit for me. I just went through the job search again, and asking all of these questions helped me determine that Test Double was the right place for me. I cannot stress enough the importance of asking questions in the interview. When I was first out of college, it sounded like I needed to ask questions to impress the interviewers. The truth is that interviewing is a two-way street, and asking questions is how you can find out if the company is the right fit for you. Not asking the right questions is how I've ended up at a lot of places that just weren't right for me in the long term. You should feel free to either use this list verbatim or use only the questions that are relevant to you and your needs. I also listed additional resources at the bottom. I also keep this list up-to-date on Github.

Culture

1. How does the engineering culture differ from the overall company culture?

2. Can you give me an example of a mistake you've made here, and how it was handled?

3. How often do you pair?

4. When something goes wrong, how do you handle it? Do devs get shamed for breaking the build?

5. How are disagreements solved - both technical disagreements and other kinds?

6. What happens when personalities clash?

7. How flexible are work hours?

8. What tools do you use for remote collaboration?

9. How do they work together and ensure good communication and collaboration?

10. Can you tell me about what I can expect from the interview process?

11. How many hours do people work in an average week? In your busiest weeks?

12. How often are there emergencies or times when people have to work extra hours?

Dev Process

1. Who sets deadlines and what happens when people fail to meet them?

2. Can you walk me through your development process, from a ticket or task to code on production?

3. What checks and balances are in place to make sure people don't make big mistakes or repeat mistakes

4. What is your build process like?

5. How does this team plan projects and create deadline estimates?

6. What is the median age that an issue will be open for?

7. Who is responsible for doing deployment? How often do you deploy?

8. Is there a written roadmap all developers can see? How far into the future does it extend? How closely is it followed?

9. How often do you have meetings? Are there any scheduled/standing meetings?

10. What’s your approach to technical debt?

11. Describe your deployment process – how do you find bugs in your team’s code?

12. Do you have a QA team?

13. Do you have style guides?

14. How does engineering work get assigned?

15. How are technical decisions made and communicated?

16. Would I need to be on call? How often? What is the SLA? How often do people tend to be paged? How often is it a real emergency?

17. What does your stack look like? What languages/tools/etc. do you use?

18. What sort of growth is available for senior engineers?

19. How does your company support the growth of junior engineers?

Soft Skills

1. Technical capabilities aside, what soft skills would make someone successful in this role?

Company

1. Are there times of the month, quarter, or year when the team is most busy?

2. Tell me a little bit about your team onboarding process.

3. How is employee performance evaluated?

4. Is there a budget for employee education/training/development/etc.?

5. Is there support for conference attendance?

General

1. What accomplishment are you most proud of since joining the company?

2. What size is the team?

3. How many total development teams?

4. How much vacation do people get? Sick leave? Are they combined or separate?

5. Do people check in when they’re on vacation? How often?

Additional Resources

Culture Queries

The Cut: Best Questions to Ask in a Job Interview

Julie Pagano's Job Search Retrospective

Julia Evan's Questions I'm Asking In Interviews

Julia Evan's Compensation Questions

Changing Careers

I have basically written this post before. However, I recently got the following email:

I'm an electrical engineer looking hard at web development bootcamps. How was your experience transitioning from engineering to software?  Did you do a bootcamp, self study, or something else?  The bootcamp is full stack and looks pretty comprehensive, but I'm just so nervous about such a big commitment. 

and oh boy did I feel like I had more to say. I ended up writing enough that I felt like maybe I should go ahead and put it in a blog post as well. I’m going to add some annotations to this to make my intentions even more clear. Here goes (again):

I actually found transitioning from engineering to software to be fairly easy. Hiring managers are more likely to take you seriously (versus if you had a philosophy degree [1]). Granted, a lot of what I’m going to say is assuming you currently have a job. If you do not, a boot camp is not a bad idea. If you do, a boot camp is 100% not worth it [2]. I’ve heard many people who went to boot camp say that they valued it for giving them projects and deadlines but that they basically taught themselves. If you require external deadlines to learn, that’s about all a $15K boot camp is going to give you. Here’s what I would recommend:

1) Find a language that does what you want to do. If you want to do more data-focused work, choose python. Web development? Ruby. Systems programming? Rust or C. There are a lot more (so. many. languages), but you want to make sure it’s common enough that there are resources and you can get a job. Then learn it. Not completely, but enough to get started on projects.

2) Practice and get feedback. Exercism.io is perfect for this. You can do exercises in any language and, once you’ve submitted your solution, get feedback from mentors and also give feedback to other users.

3) If possible, code at work. Automate tasks that you do regularly. When I worked at MailChimp, I was able to write scripts to automate log parsing. Again, this might not be possible! But think outside the box, because if you can do this, it can go on your resume under your current job.

4) Have one or two good projects on Github. These are projects you want to show a potential employer to effectively prove you can code. It doesn’t have to be huge! If you wrote a great script that is really useful, that counts. If you wrote a web app, that counts. Just get some friends to review the code, maybe do a bit of QA on the app and open up issues for things you want to fix.

5) Another alternative (or in addition if you are feeling extra ambitious) is to find an open source project or two that you find interesting and contribute. In many ways this is better because it means someone else will have reviewed your code. But it’s often harder to find a project that you feel confident putting up a pull request.

6) NETWORK. Oftentimes bootcamps tout this as a benefit of the bootcamp, but really they just send you to local meetups. You can do this on your own! Meetups are almost always free.

7) Review some basic CS concepts. I hate that people interview this way, but enough people do that it’s worth your time to do a small amount of studying. This video series by Rob Conery covers most of what you need to know, but you can also do a lot of googling because everything is out there.

8) Just start applying to jobs. Even if you don’t feel 100% ready. You’ll be applying for junior positions and no one interviewing you should expect you to know everything (or even most things). You might get questions that feel that way, but they are just trying to gauge your knowledge level. Or maybe they are assholes! But then you don’t want to work there.

Annotations:
1. There is nothing wrong with a philosophy degree! One of the best developers I know has a degree in Classics. However, many developers still think that having a liberal arts degree means you are less technical and will have more trouble as a developer. This is not true, but you might encounter it.

2. I know this is a strong opinion. And it’s just an opinion. I know great developers who went through boot camps. However, I am quite certain that they would be great developers without the boot camp.

Job Search Retrospective - The Remote Version

I started my new job in mid-June and have had this in my drafts since my job search last year. I’ve now done two remote job searches and I don’t think I’m ever going back to a regular office job. So far, I’m really happy at Stitch Fix and I’m hoping I don’t have to find another job for quite some time (years??? 🤞🏽).

Tips

1. During remote interviews, have a list of questions and type up the answers as you hear them.

2. Often, companies will ask for you to do a 5-8 hour final interview via video. Feel free to push back and request that a video interview be broken up. I’ve noticed that it’s less likely for interviewers to think of someone on video needing a break and, since you are on video, it’s harder to ask for one.

3. If they want you to travel to do the final interview in-person, consider pushing back and asking for video interviews. Here’s why: you will be working with the company primarily over video. The interview process is what helps you evaluate how they work remotely. If they have to have you come in person for the interview, how can you be sure you won’t be stuck on dev island when you actually start?

4. Out of my questions I have listed, here are the two most important ones for remote jobs: What tools do you use for remote collaboration? How do they work together and ensure good communication and collaboration? These should be a priority because remote employees require good communication more than in-office employees. It’s easier to ignore them… so you want to make sure that’s not going to happen to you.

Favorite Recruiting Group

Mirror focuses on Ruby, JS, and mobile devs. I’ve used them a few times and it is only chance that I haven’t taken a job through them because they have consistently put me in front of companies that I hadn’t heard of that I would actually be interested in working for. I definitely would recommend them.

Job Boards

Authentic Jobs

Remote.co

RemoteOk

StackOverflow Remote

FlexJobs

We Work Remotely

Working Nomads

Getting Your First Job As A Software Developer

Preface

This post is aimed primarily at people who are transitioning to another industry, not new grads. New grads will probably get something from this post, but they are not the primary audience. With that said, this post will discuss primarily getting a job as a web developer since, not only is that what I have experience with, web dev jobs are usually the ones that junior developers can get.

Getting the Interview

In some ways, this can be the most daunting part. I'm going to break this up and hopefully help you to see that you (yes YOU!) have what it takes to apply.

Getting Your Resume Ready

One thing I always tell people is to make their existing jobs as technical as possible. For example, when I was applying to my first software developer job, I made my job at Home Depot (which was a PM job) sound like I did way more development. I did all the things that I put on my resume, but I emphasized the more relevant tasks and did not mention that my day to day was mostly working in Excel. Did you optimize a process at work? That shows how you can problem solve! Did you write a script to help you analyze data? Definitely add that. Also, writing actual code is not the only skill needed by developer. Chris Doyle, CTO of Pretty Quick, does a good job of summing this up (slightly paraphrasing from tweets):

There are many valuable dev skills besides code, many of which you probably possess! Start there.[1] Also, your dev skills may be relatively small, but it doesn't mean they aren't already useful.[2] A junior developer sent me a cover letter identifying a potential UX improvement in my site, saying "This is something I could help you with."[3] That was such a concrete demonstration of initiative! They were an immediate favorite who was ultimately hired.[4]

For new developers, I expect to invest in their training, so it's really about "are they going to multiply or waste effort".[5] I do consider their current ability and have a low minimum bar, but gaining confidence in trajectory is much more important.[6]

What are these other valuable dev skills? Chris has created a whole list of developer competences. Don't worry if you look at that list and feel like you are missing a few. However, this list should help you decide what to include on your resume. For example, if you are currently in a customer support role, you are probably very good at suggesting possible causes for bugs! For more of my thoughts on resumes, see my post on the topic.

Creating Your Portfolio

This part of applying to jobs because less critical as you have more relevant experience. For example, a visit to my github or gitlab pages would make one think that I never coded! False... all my code is just proprietary and I invest my time in PyLadies vs OSS. Works for me because I have former employers and coworkers who will back up the quality of my code. If you are starting out, you need to show it. As Carlos Alonso said, as a junior developer, "your public code is the most important part of your CV." Dustin King recommends "writing a small game or other fun demo and putting it up online with code." Your project doesn't have to be huge, but you should have a friend QA it and make sure that there aren't glaring bugs. My project ended up being a choose your own adventure game that was part of going through Zed Shaw's Learn Python The Hard Way. However, I would recommend going a step further and building your own web app prior to applying. See the end of my "Getting Started As A Developer" post for more suggestions on how to get started with that.

Finding Jobs To Apply To

How do you even find jobs that are available? There are many great job boards out there, my favorite being Stack Overflow Jobs. But don't stick with just one. Search any job board that you can find and, as Christian Steinert says "try not to only consider common tech companies. Others (like financial services) might offer interesting stuff." At this point, most companies have at least a few software developers on staff. If there's a company you love, look at their job board. If it looks like they have a few technical jobs, reach out! Being passionate about a company's mission/product can often get you pretty far. As an example, if I lived in San Francisco, I would be hounding Betabrand until they hired me. If you have extensive experience in a field, look at companies with that focus so that your past experience can be even more beneficial. For example, if you are a biologist by training and looking to switch to development, you might find a place like AddGene to be a good fit. I, personally, have also enjoyed working with recruiters, like Talener in Boston. At bare minimum, they will get you in front of a ton of companies and get you in for interviews. Even if none of those pan out, it will be good practice and you will be better prepared when you find a job you are really excited about. Also, don't forget to milk your own personal connections! Do you know anyone who works at a company that's hiring devs? Contact them, see if they can meet you for coffee (buy them a coffee), and talk to them about what it's like to work at their company and their hiring process.

Now that you have a long list of job postings, you maybe are starting to notice that they all seem to say that you need experience with all these different languages, maybe one of which you have used... how can you ever be ready? GOOD NEWS! Most job postings are wish lists. Yes, even the parts that say "Required" are often negotiable. If a job sounds interesting, you should apply. Let whoever is reviewing your resume determine whether you are qualified. The only phrase that should give you pause is "Senior". If a job posting is looking for a "Senior Application Developer" or something like that, the hiring manager is unlikely to hire a junior person instead. Even so, if it's a company that you are really passionate about, reaching out will not hurt.

Acing the Interview

Before

One way to prepare is to work through a list of common interview questions and maybe a few exercism problems. Almost every interview I've had has also asked questions about SQL. Given that every job I have had has required me to use SQL in one form or another, I would recommend learning a bit before applying to any job. If you aren't up to speed yet, work through exercise 12 of Learn SQL The Hard Way. It looks like most of the lessons probably aren't too time consuming and it will be well worth your time!

During

I wrote my own "Job Search Retrospective" last September which talks about some of the things that I did in my most recent round of interviews that made me feel a lot more confident. As a junior, the most important thing to remember is that it's ok to say "I don't know" or "I don't know, but I was reading about this recently and I think it is [x]". An employer who you actually want will not be expecting you to be super knowledgable about development at this point. Stay calm on just make sure all your awesome qualities are on display. Most importantly, don't forget to ask questions!

After

If you aren't sure that you did very well during the interview, don't despair! You still have time to make a good impression. Going back to Chris Doyle, he had a person who sent in a refactored version of a coding exercise they did during an interview. This is such a great demonstration of initiative and also that you continue to consider and think about your solution even after you have "solved" the problem. It is good to send an email to the interviewer and thank them. That's a perfect place to add in "and I've been thinking about that problem that we did and I think the solution could be improved by [x]".

Starting the Job

Getting the Offer

The only advice that Mr. Sam Phippen threw out really struck a cord with me:

Charge. More. People entering the industry consistently underestimate their reasonable salary band by about 20%.

This hit me because, as of recently, I was underpaid by about 25%. To get an idea of what other places are paying, look at sites like Indeed and the recent Stack Overflow Developer Survey. If you find out after the fact that you have undervalued yourself, you can fix it, but it takes a while. I speak from experience.

Doing the Work

Never feel bad about asking questions. Take advantage of the senior devs that you work with and learn as much as you can from them. If your company supports pairing, pair program as often as you can. You will learn so much more so much faster that way. Also, take charge of a project or a feature. That doesn't mean you have to do all the work, just that you are taking responsibility for making sure it gets past the finish line. Along those lines, @codepaintsleep says:

Don't get stuck with grunt work just because you're junior. Push your knowledge when there's more experienced people to help! Also, don't write off grunt work as grunt work. Learn from everything!

To give an example of how you can learn from everything, I am covering for a coworker and working support this week. I am not doing any actual coding. However, the amount that I have learned about how our system works and what our users want in just a week is incredible. Learn. From. EVERYTHING.

Postface

I hope you got something out of this. If you think I missed something, feel free to comment on the post or contact me.

A Quick Post About Resumes

PyLadies Boston recently had a mock interview night and with that I offered to review resumes. I got a few takers, did some reviews, and now I have some thoughts.

1. If you are randomly switching fonts, please have a good reason for it. It is distracting (in a bad way) if you go from a serif to a sans serif for seemingly no reason.
2. If you are writing your job duties as a bullet-point list, please make sure each point is connected to itself. I can't seem to think of a great way to say that, but let me give an example. If one of your points is: Improved test coverage by 10%, organized tech talks, and implemented a code quality standard - then those should really be elaborated upon if possibly and definitely split into three separate points.
3. Make sure your resume reflects the skills of the job you are looking for. That doesn't mean that, if you have been a research scientist that now wants to be a full-time programmer, you have to ignore your past history. However, you do have to highlight different things. For example, how did you analyze a set of data? Did you use Python? What libraries did you use?
4. Along the same lines: If you are applying for your first programming job and don't have any related experience, you really need a projects section that lists the programming projects you have worked on and any open source you have done, along with descriptions. You know you can do the job, but if you don't put proof that you can code, the internal recruiter/HR person is going to throw your resume out.
5. For skills section: if you are including it, please make sure they are relevant! If you are applying for programming jobs, you do not need to include photoshop. Also, definitely do not include the Office Suite... familiarity with Office or similar software is assumed if you know how to use a computer (which is also assumed if you are applying for programming jobs).
6. White space is your friend! Definitely don't jam everything together. Separating out sections, careful use of bold fonts and color, and horizontal lines can really help draw the reader's attention to wherever you want it to go.

Sorry some of those were a bit of a ramble, but these are all things I have seen recently on resumes. A resume is often the first look that many people have into your professional life, so you want it to represent you in the best way possible. If you have any questions, feel free to comment!

When Bad Things Happen to Good Jobs

No job is perfect. This post is going to cover some types of those imperfections (from personal experience) and what you can do to fix it (or at least make your job a bit better). One piece of advice applicable across the board: if something seems off, document it. Get a weird IM? Save it. Even if something is good now, you’ve got to protect yourself in case the situation gets worse.

1. Retaliation

How to spot it

Retaliation is not acceptable at most companies. However, most people are aware of that, so the way they retaliate can be more nefarious and more difficult to prove. This is one situation in which it is definitely critical to document everything. The two things to look out for are: 1) did a triggering event happen? Example: did someone get fired and could you be blamed in any way? 2) has one of your coworkers’ behavior towards you changed dramatically? Example: did you formerly have a good relationship and now they are criticizing you and complaining about you?

How to fix it

If this person is not your boss, I would first talk to your boss. Unless you have direct proof, it doesn’t serve you to be acussatory, but you can at least clear your name. You can possibly say that you think the retaliator seems to have an issue with you and ask for advice on how to handle it, or ask if you should change teams or departments.

If this person is your boss, go directly to HR. Again, unless you have direct proof, I would stay away from harsh accusations. Say something like “I’m not sure what happened, but ever since [triggering event], Joe has treated me differently and I’m not sure it’s healthy for me to continue working under him.” Ask for advice, see if you can transfer to a different manager, and possibly start updating your resume. Do not be afraid to talk to HR because that is not a fireable offense. However, if it doesn’t go very well, it’s probably not the type of company you want to work for.

2. Boss Is Not a Good Manager

How to spot it

There are so many versions of this. My favorite is the super micro-manager. Or the “never there and you don’t know what to do” manager. Or the “for some reason wants to make sure you don’t grow professionally” manager. All are bad, just on different levels. Depending on how you work, the micro-manager or never-there manager might not be too bad. Or not.

How to fix it

When you have issues like this with your boss, I would go to HR directly, especially for the second two. If you aren’t getting support (because they are never there or are denying you the opportunity for advancement), that has a huge impact on your career and your productivity at the company. Most HR professionals will listen and try to find a solution. This happened to me and I was moved to a different boss within a few weeks. For the micro-manager, I would actually first try to talk to your boss directly, if they are approachable. If you frame it as you wanting the opportunity for more independence and “larger” projects, the conversation could go quite well. No one likes to be told that they are doing something wrong, so make sure it is about what you can do, not what they are doing wrong.

3. Boss Dislikes You

How to spot it

This one can be sorta hard to tell. I think that you can know, but it’s definitely hard to prove and your boss would probably never admit it. If they admit it, then I would go to HR. Otherwise…

How to fix it

If your work environment is good otherwise, I would stay and keep doing good work. Your boss may not be a good reference, but if you keep submitting excellent work, your coworkers will be. I had an experience like this (and my suspicions were confirmed after I left). I still had great work experience to add to my resume, great coworkers to add to my network, and just a man who I know I don’t want to work for again.

If your boss’ dislike of you is really affecting your work environment, I would polish up that resume and leave as soon as possible. If you have proof, take it to HR.

4. Coworkers Are Inaccessible/No Help

How to spot it

This can be a fairly common problem when you are a junior developer or a new employee. It can be especially common if a lot of people work from home and turn their IM off. This can be especially hard if you need to get a particular piece of information and the person everyone points you to is in their “dev cave”.

How to fix it

If you are in an office full of people like this, get out now. Teamwork is an important part of growing as an engineer and obviously you are in an environment that doesn’t value it. Gross.

However, this is unlikely. Most of the time it will be a small handful of people. Search out the people who are available and willing to help you and reach out to them. If you have a decent boss, request a one-on-one and discuss the situation with them. Most bosses want their team to communicate and will not be pleased if they find that quite a few of their engineers are radio silent most days.

5. Total Disrespect

How to spot it

This is luckily an uncommon problem and also can be really easy to spot. However, in my experience, it was the problem that I felt most like I could fix and yet was totally unfixable. If you are constantly getting second-guessed, but nothing you have said has been false or even inaccurate, that is a form of disrespect. If your superiors are saying negative things about you to other employees of the company, that is a form of disrespect.

Those are a bit more outright, but disrespect can also be less blatent and take the form of microagressions. For example, if your coworkers, especially your higher ups, are smiling and nodding at you, then completely ignoring your suggestions and doing the opposite of what they said they’d do (what you recommended), that can be a microagression and a form of disrespect. This can be hard to spot because it usually doesn’t happen all at once, but if you are stripped of the ability to do your job effectively, that is also a form of disrespect.

How to fix it

You probably can’t. Definitely document everything. In a situation like this, you can’t be sure what will happen. Save all your emails, save all your IMs, and, if possible (and with permission of the people in the meeting), record conversations. If this is actually happening with a company large enough to have HR, definitely go to HR. However, that is fairly unlikely. You can try to have conversations with the people or person who are/is being disrespectful, but you definitely have to be ready to quit. I’ve had one job on this level. I kept bringing things up and even coming up with solutions in meetings that were agreed upon, would think things would improve, and they never did. In the end, that was the only job I walked out on. As a human being, you should not be treated like that, but, if you are a programmer, the job market is good enough right now that you absolutely do not have to be treated like that.

Job Search Retrospective

Wow what a month. I’ve been interviewing for a little over a month now. Two weeks ago, I quit my job (post on that mess coming up in a a few more months) and somehow got a job offer the same day. This has definitely been my shortest job search (time when I submitted my first application to first offer), so I wanted to share what I think has been different.

Finding Potential Employers - Recruiters & Networking

So first things first… I may run a fairly large meetup group, but I’m actually pretty bad at networking. If you are a networker and can go to a ton of meetups and talk to people, that’s the best way, hands down. First interview I got was because I went up to someone who I knew was hiring at a conference and talked to them.

If you aren’t much of a networker (like myself), working with recruiters is the way to go. If you are in one of the areas they serve, I have had really good luck with Talener, their Boston office in particular. They have put me in front of some great companies and I’ve had a ton of in person interviews as a result. 

Many people say that you don’t get anywhere from submitting your resume just from the company’s website. NOT THE CASE! I got my last job like that and, during this search, I got a great interview by doing that.

Now that the interviews are lined up…

Interviews!

The biggest change is obviously experience. Time definitely makes each round of interviews a bit easier! There were a few other things that made it a bit easier though. 

The first was inspired by Julie Pagano’s own job search retrospective. I’ve never been very good at asking a bunch of questions, but I looked at the questions she and Julia Evans asked and took a bunch of my favorites. I had a notebook and wrote out all the questions and all the answers. This helped immensely because, not only did I find out more about the companies and how they worked, but it also helped turn the tables a bit to have me interviewing them. 

The second was that I finally actually thought of a good answer for ‘Tell us about an interesting/challenging problem that you have solved and how you did it’. I was asked variations of that question at almost every interview and this is the first year I felt I had something to talk about. I was just talking to a junior dev about this question and, really, anyone who has solved any problem with code should have an answer to this question. If you have a project, you must have created it to solve a problem. If you had a bug in your project and fixed it, there’s your problem. Sure, it’s not the most interesting, but you will get better and better answers as you gain more experience, and employers recognize that.

And the one thing you cannot forget in tech interviews, WHITEBOARDING. Three years into this and whiteboarding is still nerve-wracking and I still feel like I’m awful at it. One thing I have learned: how the interviewers interact with you while whiteboarding tells you a lot how they would interact with you when actually problem solving on that job. If someone is making you feel stupid while whiteboarding, then you probably don’t want to work with that person. On the flip side, If you are having a bit of trouble and the person interviewing you is actually helpful, then that is the type of person that you want to work with.

Overview

Interviewing is tough. No matter what level you’re at, you’ll get people who will tell you don’t have enough experience for the job. Don’t sweat it. It just means it’s not a good fit… you’ll find a good fit somewhere else :D