The following is the current version of a section in my book on interviewing for technical roles. I’m trying to help out with any advice I can while I’m putting all of this together. As part of that, I’m looking for constructive criticism and feedback alongside it. My experiences as an engineer are also not universal and so my own biases will creep up in my writing. With your input, I’m hoping to refine my own writing to help other folks out. If you’d be so kind to offer your advice in response, I would love to hear it.
This is the part where a nonzero percentage of you throw your hands up in the air and storm out the room in disgust. Ready? Ok, here goes.
I enjoy writing PHP.
It’s got quirks, to say the least, and they can be frustrating. Tear your hair out and hit the reset button on the internet infuriating even. But I know a lot of those quirks and I can work with them. I’ve got about 10 years of my career working in PHP, during which I’ve become pretty good at building stuff. I’ve even been fortunate enough to contribute back to the PHP community. So I like to highlight that as one of my strengths. It was several years of writing code in Basic, Perl, Java, and C++ before I got here, though. Conversely, there will be companies that don’t use PHP and engineers who shake their heads at the thought of even considering starting a project with it.
That’s ok too.
Not everyone has to like your favorite language. They don’t have to use the same editor you use or prefer developing on CentOS over a Debian box. See what else is out there, for sure, but love what you love. There are strong communities you can be a part of and contribute back to, even in small ways. This can and should be a solid starting point in your career, because that’ll get you through the hundreds of times when you’re banging your head against a wall trying to sort out a bug or generally just feeling like you’re not good enough.
I’m focusing on a language, but not everyone’s career starts that way. Some folks may be QA engineers who set up testing suites or network engineers running packet analyzers or working the help desk at your company to diagnose laptop issues. These are all critical to a well functioning tech stack, so don’t let others discourage you that you’re not really an engineer. The important thing to keep in mind is to build around a core set of skills that are going to inspire you and keep you interested in the tech industry.
You also might not find out what you enjoy doing the first 6 months of diving in. There’s a pretty strong chance of that, in fact. You’ll probably take years of trying different things before you do. It’s scary not to have a starting point because there are so many paths to take, with the pervasive fear that once you’ve chosen, you’re then locked into your decision forever. Let me say right here, there’s nothing true about that. That’s one of my favorite parts of engineering, the idea that we can have this adaptability built into our careers. As daunting as it is to first hop into tech, every subsequent change or additional resource your pick up becomes all the easier.
So how do you know when to try something new? You probably won’t realize it until you look back down the road. There are times in your career when you need some reflection. Between jobs is, naturally, a time to do so. Life events (moving to a new country, starting a family, etc.) also can make for good times. I’ve found the most difficulty in doing so when I’m neck deep in a project. So, pop your head up every couple of months. Find someone new to follow on twitter or pick up a new blog you hadn’t been reading. Look at a new part of the stack. In short, keep things fresh. Your new favorite thing could be right around the corner.