"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.
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.
I think you missed the OP's point. The point isn't to say "languages" or "problems" specifically, those are just examples of responses from the "A" list candidates.
The point is the "D" list candidates respond with "I want to work for $company because their $product is $adjective", where it is painfully obvious to the interviewer that $company, $product, and $adjective are variables adjusted for every interview.
> 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.
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.
Something that bothers me is the feeling of expectation that software engineers (hackers) are supposed to be tech-heads without looking outside at the business, when really, the business pays the bills. Programming is my job and my hobby, but there's a big world out there where programming is only embedded into the general landscape, not the dominant thing.
Is it not okay to go home at 5 and focus on other things beside your work?
In my experience, much of the time when a company says they're looking for people who are "excited" and "enthusiastic" about the job, it's because they want to pay less money, and think that if they find someone "excited" that they'll be more likely to get away with it. If it's coming from technical people who want to hire other technical people, they may not be thinking that, but you can bet that's how the manager types view it.
Another way to put it is that they want to get more value, whether the company pays under market or well over. All other things being equal, you wouldn't hire the person who's more excited and enthusiastic about programming?
Honestly, if when describing the way you spend perhaps the majority of your waking hours, you have to put excited and enthusiastic in finger-quotes... then I'd suggest a career change.
Not everyone has an obvious way to make money doing what excites them. The most exciting thing I do most days is climbing, but even the best climbers barely make money.
I don't mind programming... I certainly don't dread it, and occasionally I particularly enjoy a problem I'm working on. But I wouldn't say I walk to work each day "excited and enthusiastic."
Sorry, getting to this late. The best climbers may barely make money, but I think it's fair to guess that they're excited and enthusiastic about climbing. That's my point. Most people want to hire the best that they're able to.. and there's a high correlation between being really great at something, and loving it.
I think the point is that people who don't enjoy what they actually spend time doing are fundamentally different employees than those that do. If you are in it for the cash instead of the technology, if the company falls on hard times you'll be out the door. If a hard problem comes up you might begrudgingly come up with a solution, but some people would be excited and invigorated by solving it.
There are many jobs out there for people who are willing to program for money. Those top companies, though, when they aren't desperate for talent, can afford to wait for people who will be enthused by the work, rather than enthused outside of it. Even being motivated by success doesn't mean people will dig in and be motivated to get the day-to-day work done the way people who are motivated by the work itself.
Side note: at least home sausage making is quite fun. Squeezing tubes of oatmeal-constancy meat product is awesome in a kindergardener sort of way. Even if I didn't get to eat the product, I would still be entertained. People who aren't? They buy sausage at a store.
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.
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.
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.
@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.
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.
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.
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.
> 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.
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.
"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.
26 comments
[ 3.6 ms ] story [ 77.4 ms ] threadInterestingly 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.
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.
The point is the "D" list candidates respond with "I want to work for $company because their $product is $adjective", where it is painfully obvious to the interviewer that $company, $product, and $adjective are variables adjusted for every interview.
P.S. There are people who live to make sausages. Read "How I Learned to Let My Workers Lead" http://people.wku.edu/rich.patterson/CFS-452/Readings/stayer...
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.
Is it not okay to go home at 5 and focus on other things beside your work?
Honestly, if when describing the way you spend perhaps the majority of your waking hours, you have to put excited and enthusiastic in finger-quotes... then I'd suggest a career change.
Not everyone has an obvious way to make money doing what excites them. The most exciting thing I do most days is climbing, but even the best climbers barely make money.
I don't mind programming... I certainly don't dread it, and occasionally I particularly enjoy a problem I'm working on. But I wouldn't say I walk to work each day "excited and enthusiastic."
There are many jobs out there for people who are willing to program for money. Those top companies, though, when they aren't desperate for talent, can afford to wait for people who will be enthused by the work, rather than enthused outside of it. Even being motivated by success doesn't mean people will dig in and be motivated to get the day-to-day work done the way people who are motivated by the work itself.
Side note: at least home sausage making is quite fun. Squeezing tubes of oatmeal-constancy meat product is awesome in a kindergardener sort of way. Even if I didn't get to eat the product, I would still be entertained. People who aren't? They buy sausage at a store.
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.
Good advice, albeit a bit obvious.
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.
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.
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.
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)?
"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.
That 50+ is too many mock interviews