
What I Learned from 50+ Mock Interviews - sun123
http://blog.jobfully.com/2012/01/what-i-learned-from-50-mock-interviews/
======
brandall10
"However, if you are in danger of becoming management, make sure you stay
technical. Write code."

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.

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.

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&R C, and so on. On Christmas break one year read
through Godel, Escher, Bach. Found Hacker News, mostly as a lurker.

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.

------
awt
Something about the last bit of advice (Find your Center) rubs me the wrong
way.

It appears that I'm expected to be excited about either one particular
programming language, or hard computing problems.

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.

The potential to succeed excites me. Seeing a product I've worked on loved by
the public is exciting and satisfying.

It just seems like the OP thinks that his candidates should find the making of
sausage enjoyable and pleasant.

~~~
dpark
> _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._

Those are not hard _computing_ problems. They're just hard problems. Solving
hard computing problems involves developing new algorithms and heuristics,
building elegant solutions to complex issues, working around hard constraints,
optimizing for massive scale, etc. Creating a system that quickly sorts and
ranks flights by different criteria could be a hard computing problem.
Figuring out why that system crashes on Tuesday mornings at 2:37am is just a
hard problem.

Very little of what most software engineers do on a daily basis is actually
about solving hard computing problems. It's mostly just work, which is why we
get paid. The hard computing problems are generally fun. The rest is what
earns a living.

~~~
eternalban
Pretty much agree with you. I would classify between tedious and hard (where
both would take the same amount of effort). Beyond that, some borderline
tedious/hard problems can be fun (and you can/will get paid for it.) For
example, I've to date spent untold hours of my own time trying to squeeze as
much performance as possible from a concurrent pipelined noSQL driver. The
tedious part is the trial and error of trying n different variations, running
effective benchmarks, etc. The thrill :) is in seeing throughput increase 3
fold. It is a rush.

------
drblast
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.

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.

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.

------
dollar
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.

~~~
maslam
I agree management is not programming. But do you feel confident working for
an engineering manager who does not understand what you are doing, even at a
high level? Can you talk about design and cost with him or her? Look, managers
who are not technical can still be great people managers.

The first job of a people manager is to set the vision, and inspire you to do
your best, none of which requires technical skills. I believe this was even
supported by empirical research Google did a year or so ago (I can't find it
right now). Still, to lead an engineering org, I believe managers have to
understand technology, too, otherwise they will make uninformed decisions
which will end up hurting the product.

I'll give you an example: I interviewed someone a couple of days ago who had
shipped large-scale real-time trading systems for a bank. He couldn't write a
for loop. Fine. But I expected him to be able to do design an ETL pipeline.
Couldn't do that either. How about basic functional design? Nope. At some
point, I started questioning what value this person would add to the org.

------
nvarsj
> 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.

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.

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.

~~~
georgemcbay
I've only got myself as a single data point, but I'm 100% sure that in my
early 20s I could interview much better than I do today when it comes to on-
the-spot interview questions like implementing tree insert/walking algorithms,
reverse this structure in the least steps possible, etc. Yet as a 38 year old
I write far better real-world code today than I ever have.

------
CoughlinJ
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.

Good advice, albeit a bit obvious.

~~~
maslam
@CoughlinJ: isn't it also obvious that we should eat healthier, exercise more,
and watch less TV? What I have observed again and again is that many engineers
start off with positive qualities but lose them over time. What's obvious to
you may not be obvious to someone who has been working at the same company for
20 years and hasn't interviewed in just about as long.

~~~
CoughlinJ
I've been in the same position for 6 years, so I know what it feels like to
become complacent. I just thought it'd be obvious to anyone gearing up for a
change. It's like checking the gas tank indicator in your car before making a
trip, and making sure you packed clean skivvies.

------
geuis
The last statement kind of bugs me:

"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."

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.

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.

------
huherto
Why do we force developers to become managers?

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.

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.

------
strlen
> You are a senior software development lead at an A-list firm ... you “don’t
> have the opportunity to write code these days”

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)?

------
motoford
What I learned from 50+ mock interviews?

That 50+ is too many mock interviews

