Tips for a successful software job interview process

Ah, the dreaded job interview. The call to set up an interview is always exciting, but the moment you realize that you have to perform well is nerve-wracking. Fortunately, I’ve been through the gauntlet of many interviews. I have some practical advice for you in this article, so read on! I recently wrote about some heinous experiences interviewing with some of the larger technology companies in the US. I can say, without a doubt, that I have some experience when it comes to being on the receiving end of the endless questions in an interview. Success in interviews comes from practice, study, and some luck. Not only are you being interviewed, but you should also be evaluating the company. How would you consider it a success if you end up in a company you hate?… Read more

In the last 8 months, I have interviewed with Google, Amazon, SpaceX, Blizzard, and StackExchange

Repeating the ridiculous technical interview process (including the onsite gauntlets) so frequently in such a short time span makes me feel like Bill Murray stuck in Groundhog Day. You know, the movie about the poor guy doomed to repeat the same day over and over until he becomes a better person. Am I stuck in a loop? Am I doing something wrong? Or are these job opportunities really just as “competitive” as the HR representatives claim in the copy and pasted emails that get sent out to the unlucky losers? I’m not convinced that the status quo for interviewing processes is sufficient.

I’ll admit it. I’m a bit cynical. It’s entirely possible that companies employing the standard technical interview process deserve the benefit of the doubt. Maybe they are bombarded with completely atrocious applicants who don’t even know how the most basic parts of a computer function. That’s fine. I understand. I get it! If I was receiving thousands of applications each week, I’m sure I would try to devise a firewall to keep most people out as well. But making a filter too finely grained causes one to miss out on some truly hidden gems.

For reference, every tech-related company seems to follow a fairly standard process of interviewing. It’s nearly formulaic.… Read more

Always Deliver to the Software Specification

As programmers and system designers, we want our time to be spent well and our products to be well received. Nobody likes to spend weeks of their life coding a system that ends up being hated and unused. But hey, you were likely paid for that work, so what does it matter? Well, unless you reflect on what exactly caused that scenario, the situation will probably repeat itself in the next project or another one down the road.

Of course, maybe it wasn’t directly your fault. Maybe you were constantly distracted by that guy who screams into his phone a few cubicles over. Maybe your boss constantly forgets his passwords and thought the best person to bother was you. Maybe the other developers decided that the coding standards were beneath them and made peer reviews a living nightmare. Or maybe the software specification just sucked straight from the beginning. Sometimes these things happen and become unavoidable or at least difficult to avoid. But never, ever, let a product suffer as a result of not delivering to the specification; no matter how bad it sucks.

“But it was just that awful! There was no punctuation, and the writer decided to write the entire thing in Ye Olde English.” you shout. OK, wow, that’s pretty bad. But why weren’t these things brought up during the specification review and sign-off? I guess someone up top thought it was well written and chock full of good ideas. If it somehow managed to pass through the stakeholders and into your hands, then there’s not much you can do except leave the company or do your best to implement the funny jokes generator that slipped in from someone in management at the last minute.

Now, that doesn’t mean the specification can’t be improved. You can certainly bring things to the stakeholders’ attention for post-sign-off review. Perhaps you don’t know the subtle distinction between thou and thee which seems to be sprinkled everywhere in Ye Olde Specification. This approach to specification review is quite common, because things will inevitably surface during development that you didn’t expect. This path leads to happiness and sanity.

But sometimes, we programmers get that creative spark, that hint of artistic genius, our Van Gogh moment. Ignore it. Don’t let your imagination get the better of what you should actually be doing which is delivering to the specification. I’ve had the displeasure of working with someone (we’ll call him Rembrandt) who constantly wasted time implementing features that no one asked for. And you know what, some of the features were really awesome. Rembrandt had some genuinely good ideas. Rembrandt also caused the ship dates to constantly slip because he was never finished with the agreed upon tasks.

Therein lies the lesson. Don’t create features that aren’t explicitly stated in the specification. I know it’s hard to ignore that nagging voice in your head that says, “It will only take a little more time to add this other feature!” In reality, it probably wouldn’t take much time to add useful little features.… Read more