I’ve said before that I like badges, especially ones that take real effort to achieve. While it may be my first “gold-level” badge on Stack Overflow, I can’t really say it took skill, just dogged persistence (and liberal use of Slack’s /remind command):
Recently I was attempting to set up automatic payments with a utility company via their website. I dutifully entered my bank’s routing number and my account number, but when I tried to submit, I was told the routing number was invalid. I double-checked it with the bank’s website, but I still got the error.
Being something of a nerd, whenever I run into trouble like this on a website, I open up Chrome’s dev tools to see what’s going on. Turns out the UI was sending the routing number to an API endpoint that ensured it belonged to a real bank before submitting the form. For whatever reason it appeared this API didn’t have my bank in its database.
Which made me wonder if I could twiddle the site’s Javascript to skip this API call and submit the form anyways. Lucky for me they didn’t perform any minification, and it was straightforward to bypass this verification step. When I did so, the form submitted just fine and told me automatic payment setup was complete. I suppose I’ll find out on my next billing cycle if it worked, but I bet it will.
Three takeaways from this little adventure:
When I’m asked about interview advice, one suggestion stands far above the rest: be specific.
I want to hear real stories about events that actually happened, not hypothetical situations you might come across in the future. Having a real story to tell that only partly addresses the question is better than a direct answer with no experience to back it up.
Tell me the actions you individually took in the situation, not what the team generally did. A job interview is not the time for false modesty. Be humble and honest about it, of course, but you’re the subject of the interview, not your colleagues.
Explain not just what you did, but how the situation turned out. What were the actual results? If you have metrics or other data you used to measure the outcome, even better, and if you can quote actual numbers, that’s the holy grail.
Finally, what did you learn from the experience, and how would you apply that to future situations? A discussion on learnings is never out of place, no matter the interview question.
Bonus tip: don’t be afraid of negative examples. No one is perfect, and most future successes are predicated on prior failures. As long as you can articulate how the situation changed you for the better, it’s a plus in your column.
It’s been said that Vincent Van Gogh didn’t like _The Starry Night_, which is crazy, because it’s one of the world’s most recognizable paintings, and an obvious masterpiece.
If some of history’s greatest artists were unable to judge the value of their work accurately, how much less so are we. Don’t be quick to disparage your creative efforts, no matter how meager they may seem.
There are really only two tasks a company must perform:
Each employee, no matter her job title or role, must contribute in some way to one or both of those two goals. Any other task is only a means to one of these ends; everyone involved does well to remember that.
And yes, I realize strictly speaking products and services are two different things, but for the sake of pith can we consider the latter a type of the former? Thanks.
Back in my days working for a large defense contractor, it was understood that as a developer became senior she would get involved in writing proposals. At the time I thought it an odd expectation; shouldn’t developers stick to doing what they do best, i.e. writing code?
But now I see the wisdom in getting engineers more involved in the process of winning new business. For one thing, it forces them to write, which is not a bad thing, even though it isn’t always fun. Secondly, it helps build relationships between engineering and sales, two departments which are often at odds (this is probably worthy of its own post, stay tuned for that). Finally, it gives them insight into the kinds of features customers are asking for, and allows them to be a part of suggesting creative solutions for those features.
So yeah, I’m a proponent of proposal writing. And in a completely unrelated note, I’ve got a big spreadsheet of proposal questions I need to divvy up among the team for responses. Who’s with me?
Developers like to write code, that’s what they do. But being a software professional means working on a number of other tasks, some of which are decidedly un-fun. The wise developer recognizes the importance of these tasks and approaches them with no less effort than their more enjoyable work. Grooming a task list. Writing documentation. Cleaning up repositories. Slogging through a naming refactor to improve consistency. She knows that these will all pay off in the long run.
Yesterday I spent nearly 10 hours working in JIRA, getting my head around nearly 150 tasks that need to get done in the next 3 weeks. Circumstances had forced me to be pretty heads-down in dev-world the past couple months, and my planning responsibilities had fallen by the wayside. I owe the team more than haphazard and vague requirements, and this is the first step to doing better. Here’s to a full July!
A wide variety of tasks face the developer each day. Some can be accomplished quickly, like responding to emails, and some need much time, such as implementing a new product feature. Some require little thought, like cranking out a refactoring across several components, and some take a lot of mental energy. Some have immediate near-term deadlines, and others are not due for some time.
It’s particularly easy to focus only on the tasks that must be done soon (so-called “urgent” work) but the responsible developer must fight this tendency. Urgent and important are not synonyms.
Any engineer worth her salt must learn to prioritize well. The next couple weeks are crunch time at the office, so my posts here will be spotty at best. My hope is that once things settle down I can dive into some meatier topics. But for now, superficiality rules.