What I Learned from 50+ Mock Interviews
Today’s guest blog is by Bilal Aslam, who recently launched WiserProfile, giving you personalized feedback on your LinkedIn profile. Bilal is a technical visionary with 5 years of experience at Microsoft, currently an engineer on Windows Azure. Recently, Bilal was the VP of Engineering at emptyspaceads, a seed-stage startup. His passions include data mining and distributed systems.
One of my friends Gayle runs an awesome company (CareerCup) which provides phone and in-person technical interview coaching for A-list companies like Microsoft, Google and Amazon. I have been doing mock interviews for CareerCup for more than two years now. While I don’t remember the exact number of mock interviews I have done, it’s in the neighborhood of 50+. Candidates have run the gamut from hopeless to brilliant. Many have gone on to get jobs in the companies they applied to. Disciplines have run from developer (the majority) to tester and even a few program managers.
Here’s what have I learned by interviewing 50+ people:
1. Don’t Lose Your Technical Chops
You are a senior software development lead at an A-list firm. I ask you to solve a fairly basic coding problem which takes a college grad 15 minutes, but you get stuck on it for an hour. You stumble your way through various possibilities, write atrocious code and then mumble an apology about how you “don’t have the opportunity to write code these days”. You would have been red-flagged in a real interview in the first 5 minutes.
If you’re 25 years old, out of college, and write code for fun (or your job!), move along. However, if you are in danger of becoming management, make sure you stay technical. Write code. Hell, read code and do code reviews. But don’t run a team of developers or testers if you can’t do the jobs they do. Your annual review may not reflect it, but your long-term career will suffer for it.
2. Invest in Yourself
This one is pretty straightforward – follow the old financial maxim and “pay yourself first”. It doesn’t necessarily have to do with getting a higher-education degree. It has to do with taking time to teach and, if necessary, reinvent yourself. Take time to learn new technologies. Install them. Play with them. You have been a customer support guy for 10 years? Who says you can’t write code – pick up a Ruby on Rails book and start your first web app. Don’t just do your day job, because chances are you will become specialized over time.
3. Work on what Matters
In a nutshell: work on what matters for you, or what matters to your company. Ideally, work on the intersection of these two.
The first piece of advice is obvious – follow your passion. Work on technologies you think are awesome. You will be engaged and, as a result, will produce great work.
The second piece of advice is not as obvious. If you are working in an investment bank, do you think it’s better work in investment banking or for the IT department? If you are working for Google, do you think it’s better to work on search or HR? If you are going to work for a large company, chances are you will do learn more by working on what really matters to the large company. I have seen countless candidates who, over time, ended up working on niche products or in supporting roles. These products and teams get cut in difficult times. You also learn and earn less than people who work on core areas. It’s entirely possible to be personally fulfilled and happy in such jobs – but at least be aware of your role and how it fits in with the core mission of the company.
4. Find your Center
I ask many candidates, “Tell me why you want this job”, I get two types of responses. College grads just cannot stop talking about cool programming languages, social media, green energy, etc. Crustier engineers talk about “hard problems” in computing.
Sadly, the more common response I get is “I want to work on company X because I think Product Y is awesome” e.g. “I want to work at Google because of Search” or “I want to work at Microsoft because Windows is so interesting”. Dig a little deeper, and you find that the second population is looking for “a job”. They may have cared for changing the world at one point, but chances are their friends and family pushed them into a well-paying field.
The second group does not have technology at its center. This is painfully obvious to an interviewer.
Given a choice, all other things equal, I will always hire someone who truly cares about the product over someone who treats it like a job.
“But don’t run a team of developers or testers if you can’t do the jobs they do. Your annual review may not reflect it, but your long-term career will suffer for it.”
Unless your goal is to be a top manager, executive, etc. The top managers, etc. are supposed to focus on the bigger picture, not just the details of particular programming tasks. Another issue is that even top programmers who are over a certain age may find it a struggle to be hired when there are younger, cheaper workers available.
@GregBo: I’m not saying that a manager should literally do the jobs of their direct reports. We have specialization for a reason: so team members can do what they do best. My point was that managers should not lose touch with their technical roots – stay coding, stay technical, stay relevant.
The way I read this was that you shouldn’t lose sight of the core competencies of your industry. Analytic skills will dull if you aren’t looking at problems analytically. It’s important to stay on top of latest buzz words and the software life-cycle flavors of the week but it’s also good to keep yourself well grounded in the fundamentals of programming if you want to stay in that industry.
Managers should have a firm grasp not only on the employee’s they hire, but the projects the employee’s are working on themselves. No boss should realistically have to sit in and do the job for and employee, that is why they were hired in the first place, and a manager worth his grain in bytes should learn how to hire the right candidate in the first place. Employee’s would have more respect for their boss however if they were able to sit down and show them how its done.
Kind of reminds me of naive people who join the police force because they want to make a difference. In the end, they don’t realize they will be handing out parking tickets, traffic violations, spend countless hours in the office doing paperwork and maybe, once or twice a year, if they’re lucky, do something that matters.
I think this is the main difference between the naive college grad and the “crusty” developer as you described. One knows what he/she is getting into.
Everyone’s goal is to grow in their career, not just get a job (unless they’re unemployed). Working with great technologies is often viewed as the means to do so, or working with a more reputable firm.
Over the years, I’ve read countless articles on “how to interview”. From an interviewer’s perspective, I always find myself reminding the blogger to remain humble or alternatively let countless talent will slip through your fingers due to a pursuit of raising red flags over nothing.
Other than that, I do agree with investing in yourself. Too many forget to do that and as a result end up as obsolete.
I also agree with becoming familiar with the product of the company you are interviewing with; this is very challenging, however, when so few accurately articulate what they do, what product or team they are interviewing for.
“The second piece of advice is not as obvious. If you are working in an investment bank, do you think it’s better work in investment banking or for the IT department? If you are working for Google, do you think it’s better to work on search or HR?”
I agree with the thought behind this, as far as I understand it, but I think your examples are very wrong. If you’re trying to build a career in HR, you could do a lot worse than working in HR at Google — recruiting is a core competency for every tech company. Likewise, if you’re trying to build a career in software, you could do a LOT worse than working for a bank. A huge number of developments in high-performance software have come out of the banks.
But the larger point, I think, is correct, as long as you understand it within the bounds of your career focus. At Google, working on search relevance is probably a better bet than working on Google Wave was. At a bank, working on trading systems is a good bet.