"What should I do?" is another question I hear a lot, especially from the people I manage. It gets phrased differently sometimes:
What would you like me to do?
How would you like this done?
How should this be done?
How should it work?
Etc.
This may be the most value-robbing question ever. It essentially turns an opportunity to show who you are and what you can do into nothing more than a task to be completed. Asking what should be done is, essentially, asking someone to design the solution to the problem that you've been assigned. When I run a team, I want my team members to design (and implement) the solution. One of my management mantras is, "Bring me options and ask for a decision".
I can hear the naysayers now: "But Jay, not everyone who reports to me can design the solutions to the problems we have."
Oy.
I'm not suggesting that your only options are what your team brings you, I'm suggesting that before they ask for help they demonstrate an attempt at solving the problem. This is how you build design skills: You practice and you find out where you're wrong. Eventually you get to the point that your designs are accepted by your manager consistently and you get to move up a notch. Without that practice, though, you'll remain stuck where you are.
So instead of finding out (and doing) what you should do, do what you can. Present options to whoever needs to make the decision and if the options are unacceptable, then ask for help. Look for the growth opportunity in everything you do and you'll be amazed at how quickly you grow.
I've interviewed a few dozen developers in the course of my career and I've finally settled on a few questions that I'm almost certain I'll ask. If I'm going to interview you, consider this a study guide. If you're going to interview someone else, feel free to use the questions as you see fit. If you're going to interview with someone else, you might prep answers to these questions and find a way to slip them in even if the questions aren't asked.
1. Have you ever seen software written well?
I've come to believe that it's difficult to write software well unless you've seen it done well. But be forewarned, this is not a question you can simply answer "yes" to, even though some candidates have tried to do as such. If you tell me "yes", and leave it at that, the follow up will be "What did that look like? What made you feel it was done well?", or any number of variants See, I'm not just looking to find out if you've seen software written well, I'm looking for a sign that you noticed what made it good. People who have noticed good things will also notice the absence of good things. The first time I test drove this question I had a candidate named Khurram whose eyes absolutely lit up as he said, "Oh yes! I was on a project where . . ." and he went on for 5 or 10 minutes about all of the things he'd seen and why they were great and how they helped later. It was an interviewer's dream come true and cemented this as a permanent question on the list.
2. Have you ever been on a bad project?
Once again, you can try to answer "yes", but I'll ask very similar follow up questions: "What were the symptoms? What were the causes? When did you know that things were going South?" and one of my favorites: "What did you do about it?" Chances are you've been on a bad project, but did you pay attention to what was going on around you, or did you mindlessly write code and close tickets? People who have noticed what causes projects to fail are more valuable than those who haven't because they'll recognize the signs of a project that's going in the wrong direction. Even more valuable is having built up a collection of countermeasures, but if you have those then you probably won't be interviewing very often because there'll be a list of people who are trying to hire you.
3. Have you used branches in version control?
I'll admit that I'm a little . . . um . . . hyper-focused on branching and version control. But here's the thing: I can tell so much about where you've worked and how you've worked from this one question. If you say that you have used branches, I'll ask you about your branching strategy and start to learn about how you work by seeing what you protect yourself against. NOTE: Never, ever, try to fake having branched. There are all kinds of problems that are both solved and caused by branching and if you try to fake it, you'll get caught quickly. If you haven't worked in a group that uses branches, then I instantly know that you've never seen a good build process either. I'll know that you either haven't worked on parallel features/fixes or haven't done it safely. Another note: when I get on my branching soap box, it is a prime opportunity to talk about process, but a surprisingly bad time to talk about technology. I'm trying to open the door for you to discuss things being done quickly, safely, and thoughtfully. If you take this opportunity and use it to talk about the latest distributed version control system and how cool it is, you'll hear that door slam closed very quickly.
That's it. Those are the 3 questions I ask in every interview now. Notice that there are no right or wrong answers. There is literally no honest answer that you can give that would cause me to not hire you, although I will use the answers to qualify your experience level. Junior developers can answer "no" to all of the above and still get hired because this may be their first or second gig. Mids need to answer "yes" to at least one, but preferably two of the above. If you call yourself "senior" and can't answer "yes" to all of the above (and preferably have multiple examples) then you're kidding yourself. I don't mind that you're not senior, but I mind a lot that you're kidding yourself. Also note that there are no technical questions on the list. This is for 2 reasons: Technology changes often enough and is specific enough to the project that it doesn't make sense to me to have permanent tech questions. Secondly, and probably most importantly, I tend to work with programmers that are better than me and they usually have the tech portion of the interview covered really well.
As a final thought, keep in mind what an interview is. An interview is a chance to make people want to give you the opportunity to work with them. No one is really going to know what it's like to work with you until you're in the trenches together for a couple of weeks. If you go into an interview with a story to tell and make life easy on the interviewer by answering their questions in long form, with some examples, then they're going to like you. You will give the impression of someone who takes initiative and shares the workload. On the other hand, if information has to be dragged out of you or your answers are unclear then you're going to give the impression of someone who has to be spoon fed tasks and even then not necessarily deliver.
Feel free to add your own favorite interview questions (or the worst ones you've heard) in the comments!
This post will probably strike you as either common sense or absolute crazy talk. It is especially written for those in the latter group.
I write a lot about working safely. After lots of posts on branching, test environments, kitchen analogies, etc. I'm here to recommend some behaviors for those times when you totally screw up. After all, you may very likely find yourself in an environment without all of the safety nets you want because you were specifically brought in to build the safety nets. I'm going to assume that you messed up while doing the right thing in the wrong way rather than something criminally stupid like, say, encoding your DVD collection to Divx on the production database server because "it has those really fast drives and all that RAM".
First, and foremost, as soon as you realize that you've screwed up, let someone know. Do not be tempted to keep things quiet and fix it before anyone notices. I have yet to see a production issue that didn't get worse with time (and quickly). Keeping things quiet is outright selfish because you're putting your own comfort ahead of the good of the group.
Secondly, fixing your mistake needs to become your top priority. Fixing means not only getting things working again, but getting them back to the way they would have been. Does data need to be re-keyed? It's now your job to re-key it. Do numbers need to be verified? If you're not the one who can do it, be prepared to generate special reports or data dumps to make the job as easy as possible.
Next, take responsibility for your mistakes. Full responsibility. You don't get to say, "I deleted the production website, but the slow restore process is what caused the outage to be so long." Being up the creek without a paddle means that you own the upstream and downstream problems as well.
After things are back to normal, do your own private After Action Review (note: there's a good chance you'll be asked for either a public one or one with your manager). Take this opportunity to learn from what just happened while it's still fresh. For a big enough mistake, you'll probably also reflect on it for a day or two. Having said that, hear me now and believe me later: do not utter the words, "Well it's kind of lucky it happened because…". Even if there's some fantastically beneficial outcome, you don't get to celebrate the effect, you are still responsible for the action.
Lastly, get over it. If you've made the kind of mistake that I'm writing about, it will almost certainly affect you emotionally, mentally, and physically. That's to be understood and will actually help with internalizing the "Don't do that again" lesson. But don't let it affect you too much for too long or you'll kill your productivity. If making a huge mistake makes you skittish to the point that you are no longer a high performing contributor, then things aren't back to normal are they?
As a final thought, while things are at their worst you may start wondering, "Are they going to fire me for this?" I can't answer for certain, but I can tell you this: When I had headcount, I never fired someone for making a mistake . . . and they pulled some doozies. If you do get fired for a blunder that you feel comfortable defending (i.e. Doing the right thing the wrong way), then chances are it wasn't the place for you anyway. The only way you can do truly incredible work is by being willing to take some risks and if your employer squashes any chance of that happening by firing people for mistakes, then you're better off elsewhere. Just don't make a habit of it: it's easy to explain a one-off, but the second time you get fired for f'ing up big time it starts to look like a trend.
The secret to being a Big Swinging Developer is to be a force multiplier; make other people more valuable and you become incredibly valuable. Don't believe me? Which do you think is worth more: improving your own effectiveness by 50%, or improving 10 people's effectiveness by 10%?
There are several ways to improve others' effectiveness: tools, techniques, processes, infrastructure, the list goes on. The most direct way, however, is if you're the manager or team lead. If you've never lead a team before, or are afraid that you're bad at it, here is a dead simple guide to get you started or turn things around.
Step 1: Find out what success looks like for you & your team.
Your team exists for a reason. It's there to build features, or test stuff, or support a system that's in production. Whoever signs your check has a vision for what makes you and your team valuable and what success looks like for you. And if they don't? Easy, you find out elsewhere. There are only 3 ways to provide value to an organization: increase sales/revenue/demand, decrease costs (aka increase efficiency and output), or decrease risks. Your team is responsible for one of these, guaranteed.
Step 2: Determine how each team member can be valuable.
Remember in step one where I said, "Whoever signs your check has a vision for what you valuable"? Well, you're that "whoever" for each of your team members. Even if you don't actually sign their check, you are responsible for knowing what each person can do to be valuable and then communicating that clearly. NOTE: This is the hardest part of management. If you know what someone can do to help out and can communicate that clearly, you have it made.
Step 3: Monitor.
Lack of monitoring is the Heart Disease of management: It kills more teams more quietly than anything else. Even worse, lack of monitoring can look like so many other things. You see, one of the problems with organizations is that they're dynamic. If you're not monitoring what they need, you may find yourself doing what you've always done and unemployed because that's not what's needed anymore. Or you may do what you think is a great job of communicating to your team what you want them to do, but if you don't monitor them and provide course corrections then they could end up working really hard on something that you don't need.
If you put those 3 steps in an infinite loop, you can successfully manage teams for the rest of your career. If you need more supporting evidence, look around where you work for teams who are struggling and you'll probably see lack of monitoring, poor communication, or lack of vision.
That covers the basics of running just about any team. Next time I'll talk about how to build a really kick-ass team.