Reflections on the Latest Round of Job Hunting

This post is a part of a series on job hunting and job interviewing.

Back in February, my employer let my whole team go after getting rid of the project we had been working on. It threw me back into the world of job hunting. While there some similarities to my last job hunting experience, this one just felt a bit different in many ways.

Types of Jobs I Was Looking For

What was I looking for in my next position? Well, in a way, basically my last position. I originally joined that team (and subsequently moving to Pittsburgh) because I saw five things that really stuck out to me:

1. The team seemed very thoughtfully constructed and full of smart, empathetic individuals (including a big focus on diverse team members)
2. The manager not only cared about the work we were doing but really cared about the individual team members as actual people. He also noticed that despite the fact I didn’t know any of the technologies the job required, he immediately saw I was a fast learner and quickly absorbed new info. (Something my manager later wrote pretty high praises in an employee review (see about halfway down))
3. The company seemed to be working on a product that I not only thought was good, but potentially having a great effect for its users
4. The pay was a definite increase over my last job and felt more in line with what I thought my experiences brought to the table, and I appreciated some of the other benefits (including unlimited PTO that seemed to be done in the “correct” way, like ensuring you took a minimum amount of time off, you took it when you needed it, vacations were real vacation time (and not “work” somewhere else), etc.)
5. It would allow me to get out of my last city, which I just started to feel stuck in, and Pittsburgh seemed like a great place to be that I had great recommendations from people I knew there

While ultimately the job didn’t work out, I came out of the job knowing what I wanted out of my next position. A strong, diverse team. A great project I felt good working on. Empathetic team members, managers, and company. Good pay and benefits.

And when companies asked me, “What kind of role do you see yourself in next?” these were a lot of the things I mentioned. (I didn’t say the pay/benefits part.)

The Difficult Spot I’m Starting to See Myself In

One of the difficulties I found in the last job hunt was that I wanted to make sure I was in a role that I felt would challenge me, but also a place that I felt like I could use my skills. So an equal part being able to contribute a lot, but also being able to learn a lot (from work or from coworkers). It’s kind of why I aimed for the moon (and going for the cliché of if I missed I’d be among the stars). I interviewed at Google, Amazon, Square, Etsy, MongoDB, and more. And I made it to nearly the final round of every one. I knew I couldn’t quite do that this time.

For starters, I had just moved. I wasn’t ready to relocate before I had even lived in Pittsburgh for a year. So I was looking for remote or local work.

But as time has went on, I’ve sort of landed in this spot where I’m in a new language, a new tech stack, a new field… basically everything new. Ultimately, I see this as a skill. I’m a great problem solver, and so if you throw me into a weird situation, I’ll find a way out. The more I expose myself to different languages/frameworks/technologies, the better I think I end up after seeing all sorts of new ways to approach problems. The downside is, of course, there’s a bit more ramp-up time to get myself going. My last job appreciated this though. There would be 2-3 days after a new task was assigned to me where in standup all I could go was “Uh, I’m learning this thing.” However, time and time again I not only solved problems but felt like I conquered them. The more time goes on, the more I’m finding this is an amazing skill.

I learned to program in first grade, so one might way since it’s 2019 that I have about 30 years of experience. But obviously not all of that was paid and in a business setting. If you count work since I got out of college, then it’s only four years of experience. But I had development jobs before college too. I estimate if you added up all of those positions, I probably have 7-8 years of experience. I taught C++ in college as well for three years, so I figure having to know a language strongly enough to not only teach someone but answer all sorts of weird questions thrown at me and have examples of how to do it should count for at least one of experience on its own.

This range is a very weird thing to reflect, both in interviews and on a resume. People seem to want to calculate it differently, and the prevailing number seems to be the lowest.

But when it comes to my “seniority” as a developer, it gets even trickier. No matter which number you pick, if I haven’t stayed in one stack/language long enough, I don’t come off as “senior” in it. Which is weird because I feel like the “seniority” of a developer comes from experiences in problem solving, in software design, in dealing with data and algorithms, and in dealing with other teammates, clients, and other people. The best developers are going to have this big bundle of experiences. And I have that. But if a job is looking for someone with 6 years of .Net, that’s not me.
(Though I have 6 years of experience and have .Net experience.)

In other words, the longer I go into my career, the harder I’m finding it is to “sell myself” (as those career coaches like to say) to future employers despite the fact that all of them would probably agree that these individual skillsets are important.

Experiences in My Interviews

Since I’ve been looking at local Pittsburgh jobs as well as others that are remote, I’ve had a wider variety of interview types than I did in the last round. This seems to include:

• Experience questions (ex: “Tell me about your last project you worked on,” “What did you do when you encountered a situation when…”)
• Technical questions (ex: “How would you go about solving a problem where…”)
• Coding questions (ex: “Here’s a small problem, please code the answer in this language” but also where I discuss what I’m thinking)
• Pairing questions (a coding interview, but there’s discussion back and forth with the interviewer)
• Computer Science Trivia (ex: “What are the steps in a HTTP request?”, “What does REST mean and what are the different commands it uses?”)

I’ve been tracking stats of every one of my interviews on Trello. I’ve probably done over 70 phone calls of some sort or another. I’m definitely seeing some major patterns.

For starters, one of the biggest problems I’m having lately is ghosting, or the process where the interviewer or recruiter doesn’t get back to me and no longer responds to emails or phone calls. I’d say about a third of all of my interviews end this way. (This is a TERRIBLE percentage and it’s just plain rude for me to spend so much of my own time and energy to get no response.)

Another problem I see is that I learn later there’s some sort of discrepancy in information passed back and forth. For example, they reached out but are a much lower experience or pay than I had before, or along the way they changed their mind about what they were looking for in the role and failed to tell me. This usually results in me declining to go further, or me just not matching up to the revised attributes they’re looking for. (I once had a role I applied for that, mid-interviews, changed it’s job title to a stack I don’t work in. Recruiters said “oh keep chatting with them.” Interviewers were VERY confused why I applied for a role I knew nothing about. That was fun to explain.)

There’s been some others where they turned me down. Those are sort of the ones I want to focus on mostly.

Reflections on Interview Feedback

Most of my interviews don’t result in feedback, though I can kind of extrapolate a few general ideas of why they turned me down. Though there’s a few that do offer feedback, and they usually leave me quite annoyed, but not for the perhaps obvious reasons.

First, some of them seem to interchange “experience” and “knowledge” with each other. While I won’t dispute that having a good amount of knowledge (what I like to call “computer science trivia”, or the things I would have learned from a class in college) is important, I feel like the more “senior” a level is that I apply for, the more they assume that means I should remember more of these types of things. Obviously the further I get from college, the more I tend not to remember things from my classes because most of them don’t apply on a daily basis. And I don’t think memorizing as many terms as I can and knowing what acronyms stand for really equates to showing off my skills as a great problem solver.

Second, I’ve started to get some feedback where people see me as more an “individual contributor” than a “team leader” type thing (which some degree of leadership is something you generally want as a senior developer). I’m learning though it’s coming from something I wasn’t expecting: I’m too kind. I’ve learned that, as a team, it’s often a variety of people involved in pulling off things and I want to give everyone credit where it’s due. However, this becomes a problem in an interview when you have to talk about things you did. So I tend to start off talking about the project my team works on as a whole then try to dive into things I worked on, but I guess I’m doing it in such a way that it’s not reflecting my contributions well. (Fun fact: I had a director-level person just tell me that it’s funny because their teams work on so many things in pairs that they have trouble self-describing what they work on individually, so it’s weird they counted this against me.)

Finally, one of the things I’ve learned is that I really suck at the 9am-5pm job schedule. Partly because I just don’t do mornings well and even if I do get to an office on time, it takes me a bit to get fully going, but I’ve found I just don’t work well in one continuous block of time. Some of my best work is done in multiple, small bursts. Heck, I even solved a tremendous bug from about 11pm-2am once to get it done in time for a large scale deploy the next day that I knew was going to fail miserably. (I pushed the bug and emailed my team to say “this should solve all the problems for tomorrow’s deploy. I am sleeping in late and will see you after 11am.”, then went to bed. The deploy went flawlessly because of this. I was basically applauded by my manager in the company Slack for doing this.) But I’m finding I have to tread cautiously as I ask about core hours or scheduling, and many local and smaller companies have very strict hours or core hours (usually 9am-3pm) and there’s a tiny flexible window. But that window isn’t usually flexible to how I work best, and I’m usually not certain how to proceed (though often one of the other reasons for rejection happen).

(I do wonder sometimes if gender has a role to play as well, as studies show that men tend to just find other men more competent than women by default, and so I guess I have the bias game to fight against as well.)

So, Now What?

Good question. I’m not sure.

I have a temporary freelance project. It will last about a month. After it’s over though, I’ll be connected with a freelancing network in the area that seems to get projects quite regularly, and I might be able to just start picking those up. And honestly, at this point freelancing might seem to be the way to go. I’ll be thrown into random projects, in random tech stacks, and can use those problem solving skills to not only figure out solutions, but use my experiences to help design some software solutions. And with flexible hours, I can more or less work whenever my brain feels like taking on work. While I always hated the idea of finding my own work and dealing with client billing and such, the pros might outweigh the cons at this point.

I’ve pondered also if I should try to go back to school to get a Master’s degree. If I could go learn about robotics, or machine learning, or natural language processing, or something that seems interesting and up my alley, maybe it would give me that specialty that I keep hearing that I need and allow me to enter a challenging field I could succeed in.

It also makes me wonder if it’s time for me to do some hard core research and resource gathering on effective interviewing and team building strategies and start writing up some guides on how to do effective interviewing. I keep seeing things like “oh you know, tech people don’t know how to interview.” Why the heck not? There’s research out there. I’ve seen talks on it. If you care about hiring the right candidate, spend some time not just interviewing but making sure you’re interviewing correctly, and you’re judging your candidates in the right way possible.

But maybe in the mean time, I keep reflecting on my interview skills and try to document what I’m doing and take time to focus on building up other strategies for “selling myself.” Clearly my skills and experiences aren’t showing, and while I know the process of interviewing is terrible, maybe I need to take time to learn how to bend the rules to play the game a bit better.

I’d be happy to hear your thoughts and discuss this (though constructive feedback only). Let me know what you think!

~ Sarah

Photo credits:

• Interview room: Razvan Caliman
• Two rocks: Ann Kanth
• Cell phone on table: Craig Young
• Man with question marks: Bob Smith