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. 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.

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??? 🤞🏽).


  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


StackOverflow Remote


We Work Remotely

Working Nomads

Getting Your First Job As A Software Developer


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


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!


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!


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.


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…


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.


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