What I Learned from 50+ Mock Interviews

"However, if you are in danger of becoming management, make sure you stay technical. Write code."<p>Interestingly enough, 3 reviews back I was offered the choice of going into management. I had been leading a product line with up to 5 engineers at a given time reporting to me, spent maybe 1/3 of my productive day coding, the rest in meetings, responding to emails/phone calls, and just walking around talking to people. It didn't dawn on me that as a 'lead engineer' I had essentially become management.<p>Something didn't sit right about that experience. On the one hand it was a promotion of sorts, right? I was doing a good job getting that product out the door and this meant I could move on to other bigger, more important products. On the other hand (esp. where I work), no more coding. I felt a deep pain in my gut. Something had been bothering me for quite awhile... every place I'd been hired into was a company with less than 100 people, I always loved working on whatever was thrown at me, and here I was being asked to go into management at a company with 15,000 people, a company I was at due to result of an acquisition from 4 years earlier. It was like I had slowly been stripped of my dignity and never had taken the time to look around and realize it.<p>Within a week I read a book called the Passionate Programmer, then the Pragmatic Programmer, a few Head-First books (I liked the child-like presentation, thought is was fitting haha) then eventually began working on SICP, worked through K&#38;R C, and so on. On Christmas break one year read through Godel, Escher, Bach. Found Hacker News, mostly as a lurker.<p>I'm still working at that job, but I turned down the offer, instead requesting to to work on difficult problems. The following year I got a promotion to a principal engineer. I am a little surprised when I mention things like Ruby on Rails and have trouble actually finding someone I work with who has even heard of it. Then I just remember that was me a few years ago. And I work with some sharp people, they're just isolated in what they do, tend to average in the 40s with families. 'This' has now become my main hobby. You can't ask anyone to do this, they have to choose it for themselves. They have to experience that pain in the gut feeling and act on it.

Something about the last bit of advice (Find your Center) rubs me the wrong way.<p>It appears that I'm expected to be excited about either one particular programming language, or hard computing problems.<p>At this point in my career, it seems naive to be excited about a programming language. In my experience, the programming language has mattered far far less than other factors in the success of a company. What are sales people expected to be excited about? I hope it's not Excel... I am equally suspicious of those excited by hard computing problems. Debugging memory leaks is a hard problem. Deducing the cause of periodic load spikes on ec2 instances in the middle of the night is a hard problem. I must admit, however, that these tasks does not excite me.<p>The potential to succeed excites me. Seeing a product I've worked on loved by the public is exciting and satisfying.<p>It just seems like the OP thinks that his candidates should find the making of sausage enjoyable and pleasant.

I work for a large organization. What I've learned from interviewing people is that you should beg, borrow, and steal in order to experience being the interviewer.<p>First, it really will boost your ego if you're competent at all. Second, you'll realize how ridiculously difficult it is to hire quality people in a large company. Third, you'll learn what answers you are giving in interviews that are identical to 97% of the rest of the candidates.<p>And finally, you'll get good at picturing people by reading resumes. In most cases, I can read your resume and know exactly how your interview will go. There are always surprises, but if you read enough resumes, you will know a bit better what yours says about you.

Management is not programming, these are simply different skill sets. If you are asking senior managers to write college graduate programming solutions, you are being an asshole. If someone has moved up to people management, ask them people management questions.

&#62; 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.<p>In my experience doing 50+ real interviews, even good programmers can fail a white board coding question. Experienced candidates tend to fail it harder, since they tend to be more rusty at interviewing than new grads. It's a different experience to real-world programming.<p>A good analogy is a micro-benchmark. What are you trying to measure here? It's quite possible you end up measuring how a candidate does under pressure rather than actual programming skill.

So what it's saying is be knowledgeable about the job you're applying for, keep your skill set sharp, do what you love, and know what you want out of a prospective employer.<p>Good advice, albeit a bit obvious.

The last statement kind of bugs me:<p>"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."<p>This quote was after a comment about some people who have families and other things going on. If you can find someone who is head first into your product, that's fine. But those interests can and should change after a while.<p>Someone who has a family and responsibilities can be dependable. An employee that is frenetically brilliant can burn out quickly. A team of balanced, stable, dependable people can be counted on to keep working towards a goal. This is vitally important when your young company is striving to survive and take on/create a market.

Why do we force developers to become managers?<p>IT organizations should hire accountants and/or other professionals to keep track of stuff. (budgets, costs, projects, assets, etc. ) These professionals should have the information organized in a way that the decision makers can use it.<p>Leading the IT organizations should be the individuals with the best vision, technical knowledge, business knowledge, soft skills, etc. They shouldn't spend their time doing clerical work.

&#62; You are a senior software development lead at an A-list firm ... you “don’t have the opportunity to write code these days”<p>Perhaps, we should revise the list of A-list firms to exclude those where it's impossible to advance without staying technical (i.e., writing code)?

What I learned from 50+ mock interviews?<p>That 50+ is too many mock interviews