Something that I find interesting is that career advice coming from professionals having many years of experience focuses almost exclusively on the people aspects and not the technology: communication, trust, teamwork, documentation, clarity. The advice is clear, precise and honest.
This is the opposite of what you get from new hires/juniors: they tend to focus on which stacks matter, what to learn, how to develop, deploy and maintain. Not much real advice on the behavioral side, to the point that people often take trainings for behavioral interviews and memorize “leadership principles” and other nonsense.
What you're saying is important for everyone to internalize. I'll spin it like this:
Your job satisfaction/pay are a function of your impact. Your impact is a function of your leverage.
If you're a "pure coder" who doesn't have any of the other skills you mentioned, your output is incredibly limited. At best, you produce a day's worth of code in a day, but you also require someone to manage you closely to make sure you code the right stuff.
The more of these other skills you have, the more you can (a) work independently (b) make others more productive and (c) make sure your team/business is doing the right things and (d) drive overall efficiency.
The more of these things you do, you become orders of magnitude more impactful than a pure coder.
One of the most important skills is the one he describes like this:
>> The more specialized your work, the greater the risk that you will communicate in ways that are incomprehensible to the uninitiated.
In my experience (35 years), this isn't just about knowing the right way to describe things, it's also understanding what things to concentrate on when communicating, and what to ignore. If you are a tech person communicating with a decision maker, they are typically looking to understand options and their implications and risks, not the details of how the options work. They can then decide, based on their (presumably) better knowledge of the wider context, which options to select. If the decision makers are genuinely intelligent and motivated, but their eyes glaze over when you describe something, chances are you have chosen the wrong things to communicate to them.
Thank you! (Actually the raptor conservancy [0] is interesting from this perspective as well. I'm a newbie / junior in that context, but I can see standard employee patterns that I recognise from the tech industry, e.g. in terms of people who know to report and / or delegate well, or to make effective decisions vs. be indecisive. Perhaps I'll have to see if I can document my observations on what I've learned in my career).
Very well said. It's stuff like this that makes me think all CS majors need some sort of business communications requirement, something to at least give a foundation on how to speak to decision makers.
Good business communication is something you only learn by /doing/ it. Expecting a course to facilitate that is flawed. I'd be all for increasing the roles of internships in CS education in order to accomplish that -- and I have noticed that's begun to happen as well. CS majors these days have internships lined for summer and winter if not more (especially due to COVID). I am sure they'll learn a lot more than I did during that era of my life just by sheer osmosis.
If it is a good course on business communication they _should_ be doing it - in class. And getting feedback and suggestions on improving with every attempt.
Internships are a wonderful thing but many people don't realize how they are coming across so don't look to improve. There is some learning by osmosis, but mostly people keep doing what they have always done because it works (as far as they can tell).
They won't be doing it, they will be doing a simulation of it. How are they going to learn business communication without doing it in the context of a real business with a real P/L line and real consequences for good and bad execution?
This is the party line. It misses that “a day’s worth of code” is highly unequal across individuals. The people whose “day’s worth of code” are most valuable, quickly get pulled off of spending their days that way.
It appears that they key skill is coordinating a lot of developers, because the ones left developing are the ones you need a lot of (and who need close supervision) to get anything done. Managers will never rock this boat, because their career KPI is the number of people they manage.
That means you have bad middle/upper management. Large tech companies have heard of the Peter Principle and don't promote this way; they have separate technical tracks.
Which is not to say they're doing everything right.
> That means you have bad middle/upper management. Large tech companies have heard of the Peter Principle and don't promote this way; they have separate technical tracks.
That doesn't really jive with my personal experience, which is that contributors really don't want the only path to career progress to be a transition to management. I saw this happen firsthand at a consulting company--the technical side was pushing for the split, not the current level of management.
Having no track even better. Some people like what they are doing and the field is constantly changing. You want your best surgeons doing operations not managing other doctors.
You need some kind of title so people can feel responsible for career growth and so you can calibrate against other companies' pay at least; it doesn't need to control what kind of work you're allowed to do.
Even if they don't transition to managing people, someone in an individual contributor role presumably needs to be growing in some way if they want to get raises. While someone doing something valuable even without growing will probably continue to get small raises anyway, it's not the ideal path.
And, as you say, to the degree that position titles mean something cross-company, it gives a point of comparison.
People high on our technical track don't spend their days on code. The job of a Staff, Sr. Staff, or Principal engineer is about coordination, negotiation, and consensus-building across bureaucratic distances. Most only look at architecture diagrams. Some review code. Vanishingly few contribute. When they do, the contribution is about keeping their skills fresh and their understanding of the project grounded in reality. It's not not what they're really getting paid for.
> If you're a "pure coder" who doesn't have any of the other skills you mentioned, your output is incredibly limited. At best, you produce a day's worth of code in a day, but you also require someone to manage you closely to make sure you code the right stuff.
This seems to miss the point of teams. Everyone should have a role if you hire someone as a software engineer and they spend all their time doing devops because they like it more you've made a bad hire. If all your engineers are having product meetings with various departments then you've again made bad hires. Everyone should have their role and fullfill that role to work as a successful team. People thinking they're above fullfilling the role they were hired for is one of the fast ways to have a poor performant team. To put this into sports you don't want your defender to be constantly hanging around the other team's goal mouth.
And yet, there's incentive for somebody (say, in soccer) to try and score a goal even tho it's not their role - because scoring a goal is rewarded to the individual.
Individual coders/contributors' compensation don't scale until they are shown to "score a goal". And yet, to do so, they may have to stop contributing in their usual, assigned role, but go "above and beyond" - such as redesigning the system, or to make their mark on the product and be recognized as such.
This, i find, is probably what the fundamental problem/friction with teams are.
I can appreciate how this kind of specialization helps a team to scale. At the same time, what I like least about my current job is how structured my role is. ‘Draw within the lines’ is constraining and can push creative folks away.
> The more of these things you do, you become orders of magnitude more impactful than a pure coder.
Your job satisfaction/pay are also a function of how unique your skillset is.
With this in mind, increasing your impact (through soft skills) is just one of two ways to increase pay - the other way is to do something that not many others can do. For many people, doing something unique is far more satisfying than dealing with people problems.
I will point out that a lot of engineers are bad communicators, and those that are not often change roles. So communication is a unique skillset. As is understanding the business.
> For many people, doing something unique is far more satisfying than dealing with people problems.
These are not mutually exclusive. If you want to accomplish big unique things, you can't do it yourself. You are going to have to convince others that your big new idea is worth doing so that they will help you achieve it.
"Your job satisfaction/pay are a function of your impact. Your impact is a function of your leverage."
I'm skeptical. I mean, sure, for most people, the ability to convince a large number of other people to do things, to do your things, without worrying how they do it, is going to have more impact than any other contribution they could make.
On the other hand, Van Jacobson's algorithm is like four lines of code (I used to know where it is in *TCP/IP Illustrated, Vol II.) and is responsible for the Internet as we know it. That's an awful lot of impact.
I don't think we disagree. I hadn't heard of Van Jacobson but a quick glance at his wikipedia doesn't make it look like he was just a "pure coder" in the cartoonish sense of someone who doesn't know what's important and can't collaborate with others.
I'm not sure how "(a) work independently" fits. In fact it seems the opposite. The whole point is about working with and influencing others. That's not "working independently"
"Working independently" is not the same as "working in isolation". Not sure that this is also what the GP meant, but "work independently" usually means that you understand what the business needs and can initiate new tasks on your own, without waiting for someone to tell you what to do.
Found the manager. This is just more developer hate drivel. Yes, if you think managers are more valuable, then obviously you are going to say engineering work is "incredibly limited" and manager activities are "orders of magnitude more impactful" Listen, no amount of ass kissing and brown nosing is going to solve actual tech problems.
It sounds like you're making assumptions in bad faith. I'm a SWE (i.e., not a manager) and I didn't read the comment at all like you did. On the contrary, I quite agree with it.
Well, as someone who has saved my company's ass multiple times to the tune of millions of dollars I think technical solutions are orders of magnitude more impactful and foofoo talk bullshit is incredibly limited. So I guess we will have to agree to disagree. Maybe noob coders "produce a day's worth of code" and that's all they can do, that's your perspective.
I've sat through dumb two hour meetings about deciding which words in a document should be capitalized. Is that what is meant by "make sure your team/business is doing the right things?"
I think what you're missing here is that the original comment isn't suggesting code doesn't solve problems when it counts. The thing is, developers often code things they never needed to. Or they code things off spec. Or they code things outside of the convention of what's appropriate for their immediate team or long-term needs of the product. The list goes on. Output could seem good for a long time before it becomes problematic, then the pure coder simply codes more to solve those problems. This is very circular and makes up a lot of work done by software developers in my experience.
I agree with what you're saying in part. Pure coding skills are essential, especially in critical situations like that. Soft skills won't fix broken things, for example. Salespeople can't deliver the features they promise without someone to develop them.
However, soft skills can help someone with excellent coding skills to know what to apply their skills to and when, and how to integrate their skills within a broad team of different disciplines.
This is arguably true in any field; I think it's often missed in software development because people have such a difficult time distinguishing boundaries of things. The problems you're solving, when you're passively or actively solving problems, when output is applicable to a specific problem, etc. Even software engineers themselves struggle with this.
Your ability to save your company's ass is an excellent skill to have, but it isn't directly related or exclusive to what the original comment was saying.
You have a very noob view of software engineering. You make a lot of generalizations about coders to support the theory that coding is low impact because coders fuck up a lot. Noob coders fuck up a lot.
When I saved my company's ass those times, no non-technical people were present and it was wholly technical knowledge that solved it. I could have and probably should have ignored the problems and let the talkers try to fix it and take the blame for millions in losses. So it is very apropos to the original comment.
a) I never said coding is low impact, although I do believe software engineers make a lot of mistakes
b) my generalizations are very common in software
c) saving companies’ asses with code is not common
d) I will never not be a noob
The tech lead at my place has just burned himself out and quit after making a load of poor decisions. He reinvents the wheel over and over again rather than use some prebuilt solution. I am going to have to maintain his undocumented, untested code. Experienced coders can be just as bad for over-engineering as noobs.
> Well, as someone who has saved my company's ass multiple times to the tune of millions of dollars
Even though it sounds good, this is actually a bad measure because all coding consists of constantly making new zillion-dollar mistakes and then fixing them as you go. You can always do a worse job, and if we're supposed to be impressed by you visibly fixing something, then mess up and fix you will.
I entered the industry with no degree, having taught myself to code. After approx 15 years as a developer, I decided to get a degree, because it was becoming a problem (Australia is very sensitive to qualifications). I decided to get an MBA because all the hard problems I'd met were people and/or business problems.
The tech is generally easy in commercial coding. There is usually a definitive answer, and if not then the trade-offs are generally well-known. It's rare to run into a problem that requires complex technical knowledge, and in those cases it's fine to hire a consultant to help.
But the people problems are hard. Getting clued-up on these is important.
A mature MBA done after 10-15 years experience is very different that some one who went from BSC direct to a MBA (to game immigration hurdles in a lot of cases)
I think everyone agrees that bad management is the biggest problem facing a lot of software companies. The part that's disputed is whether managers with MBAs are actually any better than managers without them.
I think an MBA will help you be a better manager if you want to be, because at least there's some clue about what a "good" manager should look like.
I've met sooo many bad managers. In most cases they were bad because they didn't really know what they were doing and they felt they couldn't look "weak" or not be in charge. There's always the urge to authoritarian leadership because it's the default (for some reason).
If the MBA course is any good, it will at least have exposed such a person to other leadership styles and some management theory. They might reject it, of course, but at least they'll know it.
So, yeah, I don't think having an MBA makes you a better manager or leader automatically. But I think a manager who wants to get better could be helped by doing an MBA.
Of course, there are lots of managers who are convinced they don't need to get better, and so won't/can't be helped. And there are lots of people who get MBA's because it's a ticket to promotion and don't really care about the learning.
> I think an MBA will help you be a better manager if you want to be, because at least there's some clue about what a "good" manager should look like.
I think even that part is disputed; we really don't know what a good manager looks like. Some of what's taught in MBA classes now is the opposite of what was previously taught, and there seem to be as many failure stories as success stories. I do take your point that maybe just thinking about anything other than the authoritarian mode is enough to raise a manager above the average, which is distressingly plausible.
> The tech is generally easy in commercial coding. There is usually a definitive answer, and if not then the trade-offs are generally well-known. It's rare to run into a problem that requires complex technical knowledge, and in those cases it's fine to hire a consultant to help.
I'm totally on board with highlighting the importance of communication, team work, people skills (and I've seen how awful it is to work with people who lack these skills despite their technical expertise), etc. but this statement I simply cannot agree with.
Everyone's experience is obviously different. Some people may work on problems where there are few legitimate technical challenges, or where they aren't solving any problems that haven't been solved before. That hasn't been my experience in most of the jobs I've had so far. There were significant architectural and sometimes even algorithmic challenges to be solved, and not solving them properly would mean either bugs or unmaintainable software.
ITT we talk about the importance of communication, but good coding patterns and architecture (as well as the right level of documentation) are part of communicating to other developers.
> There were significant architectural and sometimes even algorithmic challenges to be solved, and not solving them properly would mean either bugs or unmaintainable software.
I get that, and I don't mean to suggest that some bits of this aren't tricky.
But with an architectural problem (for example), it's usually a choice between 2 or 3 options. We know what the options are, we know what the trade-offs are, we can make guesses on what we think the impacts will be. It's a "known known" problem, with usually enough time to research it fully. Implementing it properly can be difficult, but that's the kind of thing that can be iterated if necessary - we don't have to get that right first time.
There are lots of management and people problems where none of this is true and it's very much a "known unknown" that has to be got right on the first try, without knowing all the possible tradeoffs or consequences, and under time pressure.
> But with an architectural problem (for example), it's usually a choice between 2 or 3 options. We know what the options are, we know what the trade-offs are, we can make guesses on what we think the impacts will be. It's a "known known" problem, with usually enough time to research it fully. Implementing it properly can be difficult, but that's the kind of thing that can be iterated if necessary - we don't have to get that right first time.
No, I disagree. Some problems are truly novel (or maybe, there are just a handful of competitors and you obviously can't see their source code) and you just don't even know what kinds of solutions might exist. There might be bits and pieces in the research literature, but good luck even finding them, let alone understand if they are applicable. The space of possible technical and architectural solutions is infinite-dimensional, so it's not always a "known known" issue. There might be crazy solutions out there that you simply didn't think of.
Now, if it's about "create a CRUD interface to you e-commerce store", then I agree that the situation is more similar to what you described, but that's not what everyone is working on.
I had to work on a scheduling problem once that involved going to a university to talk to Comp Sci PHD's who were working on similar problems. That was fun. In 25+ years of commercial coding, that's happened once ;)
Now you talk about an algorithmic problem and there I agree with you - there isn't much algorithmic complexity in normal business coding.
But in your previous post, you talked about architectural problems and there I disagree with you strongly.
Taken in isolation, individual technology pieces are relatively simple and easy to evaluate. But when you plug in one such piece into a middle of a larger system (let's say typical corporate IT landscape), then it becomes way more complex on all fronts. (Enterprise) architecture is also interfacing heavily with business decisions and company structure. You need to think a lot about how your ivory tower architecture will be actually used by the teams.
But if you get it wrong, what happens? You have to refactor (if you didn't get too far in), or start again if you did. No big deal - code is perfectly amenable to this.
But the political and social problems of "we got it wrong, we're going to have to start again from scratch" are the real problems. Dealing with a marketing manager who has a product launch scheduled for the 2nd quarter and you're about to tell them that you need to reschedule because you got the architecture wrong on the first try - that is a business problem not an architectural problem.
The tech problems get a lot easier if you have some kind of framework for dealing with the business problems.
> But if you get it wrong, what happens? You have to refactor (if you didn't get too far in), or start again if you did. No big deal - code is perfectly amenable to this.
This works nicely on a small scale, but not with the architectural problems.
> that is a business problem not an architectural problem
It's an architectural problem because this business constraint forces me to get the architecture right the first time - I won't get another chance.
There's no business reality where it's OK to say "just give me another 2 years to re-do the system in a (probably) better way".
But there is a business reality where you can say "I don't know which architecture option is better, give me 3 months to do some prototyping and I can make a definite decision".
But knowing how to frame that, and manage the expectations of the other people involved in that negotiation, and recognise their objectives and priorities, is a business skill.
And, y'know, if you spend 2 years building a system on the wrong architecture because you didn't know how to ask for more time to make a better decision in the first place... well, you need some management training ;)
> But there is a business reality where you can say "I don't know which architecture option is better, give me 3 months to do some prototyping and I can make a definite decision".
And now back to your original claim. You need 3 months of prototyping only to reach a decision, but you still insist that it's an "easy" problem?
Then there's a problem that prototypes often don't uncover unknown unknowns. Investing effort into prototype improves your chances at arriving at correct solution but by no means guarantee it.
No it's not an "easy" problem - like I said, I get that these can be tricky. But in my 25+ years of commercial software experience, I've not bumped into one like this. I have bumped into complex technical problems, but the answers were/are always out there and findable. As I said, these kinds of problems are "known known" - you know what the problem is, there's a decent definition of what "good enough" is, and there's usually a lot of Comp Sci literature around to help.
Remember, this is in contrast to the people/business problems. For these, because they're involved the specific personalities involved, there is no definition of the problem (people will react to a situation according to their nature, and you can't check their source code). Often there is no good definition of what a good solution even looks like (except a broad "get everyone happy and working again" maybe). There is no literature describing the solution to the problem, or usually even addressing similar problems. And the problem always has a time limit - taking no action is seen as an action in its own right - and it's usually days at most. You literally have to make up some solution as you go along, not knowing if it's going to work or not. That's why I called these "unknown unknown" problems. In 25+ years of commercial software experience, I've bumped into at least a dozen of these (that's not including the "normal" run-of-the-mill management problems).
Your experience may vary - mine led me to conclude that the tech problems were not as difficult as the people problems, and that therefore I should get some training for the people problems.
For example: the network admin comes out as gay, starts having a relationship with someone on the night shift. The number of "emergency network outages" during the night shift suddenly spikes. A quiet word didn't seem to have any effect. The night shift supervisor is getting fed up of the disruption. Sacking the admin isn't an option. Sacking the nightshift worker isn't an option. Going down any kind of formal disciplinary process is the "nuclear" option as the company has to make absolutely sure it's not in breach of discrimination legislation. Ideally everyone would go back to work and be happy and the network would stop having problems at night (one of those where there is a well-defined "good result"). I didn't manage to solve this problem - the network manager ended up leaving in a huff (though thankfully not sueing us). I still to this day have no idea if I could have found a better solution to that problem. There is no technical problem that I've ever faced where I wonder 20 years later if I could have found a better solution (though plenty where a better solution has become available later).
If you want to get into management and deal with those kinds of people problems, then there are lots of management training courses around. An MBA is at the upper end of that range.
If you're having problems fitting into teams and getting along with people (actually quite common in dev teams), then maybe look at therapy or personal coaching. I spent a few years in therapy and it really helped.
If it's office politics and the like - some workplaces are toxic. I can't deal with those even with the training and experience. Life's too short to deal with that bullshit ;)
There were lots of things I was curious about, like company financial records/statements, some of the legal stuff around employment. The accounting stuff was really useful.
But the real wins were the leadership and management units, to my mind. Learning the "formal" knowledge around this has really helped in subsequent management roles.
The entrepreneurship unit was vaguely hilarious, as I was running a blog for the local startup scene at the same time and neck-deep in Lean Startup, which no-one on the MBA course had heard of. Writing a really tight business plan seemed to be the hardest part of starting a business ;)
I think this is on point but I've work with a lot of MBA's with garbage people skills. I'm not sold on the value of MBA except as a piece of paper on a resume. I'm not claiming that it is entirely not useful, but I don't believe it necessarily means someone is qualified either.
Did you find the MBA trained you to solve those people problems better? Did you get any practical, hands-on experience dealing with people problems during its course, or did it provide an interpretational framework, with true learning follow afterwards, like with a programming degree?
I think the latter. We studied formal models of leadership and management. Knowing those really helped me to put some kind of structure on the things that I was dealing with, but ultimately dealing with them came down to interpersonal skills and "walking the walk".
One of the really useful-but-unexpected things was having some kind of head-canon for "what a manager is and isn't" and (in one case) "what a CEO should actually be doing". It was really helpful having a kind of connect-the-dots picture of what should be happening and therefore what dots needed to be connected to make that picture happen.
Generally speaking - your technical qualifications value over a replacement hit their peak sometime between 3 and 10 years into your career for most folks. Meaning while you may be particularly skilled, learning one more discipline, stack, technique, or language probably won't let you get a particular job done any better or faster than the next engineer.
Many engineers move to management at this point, which requires that you can mentor and grow a team of engineers, set goals, drive projects to completion, and manage your team through performance reviews.
Folks who stick to the technical path need to become an indispensable piece of technical glue across N teams, keeping them all building in the right direction and not crushing each other. This job requires deep technical knowledge but often doesn't involve a ton of coding e.g. Linus Torvalds.
If a junior engineer showed up with the behavioral qualifications of Torvalds and the technical skill of a junior engineer - they would still be a junior engineer and unable to build trust, guide a team effort, or other activities.
Hum... maybe it's because they have so much technical expertise that they are able to have insights into other things?
Technical knowledge is still very important, and it's the basic foundation of being a software engineer, and maaaaannyyyyyy people out there don't even know the basics.
This is the opposite of what you get from new hires/juniors: they tend to focus on which stacks matter, what to learn, how to develop, deploy and maintain. Not much real advice on the behavioral side, to the point that people often take trainings for behavioral interviews and memorize “leadership principles” and other nonsense.
This was exactly the experience I had not so long ago.
Management brought in a new "team leader" to "shake things up" with "new ideas."
She spent most of her time reading management books, taking online management courses, and going to management seminars. She almost never spoke to the "team," and when she did, treated us like underlings.
They gave her two years to make a difference, and then kicked her out in the first round of COVID cuts.
Wow. While I do not have experience with management courses, and seminars, one book I read about management (https://www.amazon.com/First-Break-All-Rules-Differently/dp/...) talks about exactly this scenario. I am surprised to hear about it in the wild.
This is not just a junior problem. A lot of "people problems" seem to come from fighting over which stack to use. (and most people fight for whichever stack they are best at, to maximize their own personal contribution). I always spend a lot of time asking people what technology they would use to solve a particular problem, what technology they really don't like, etc. It saves a lot of trouble fighting over things if you get a team that is willing to go with a particular technical approach and is more important than most "cultural fit" issues.
In my experience, this mostly happens with people who only know one technology. Many juniors are like this. On the other hand, when this happens with a senior, they fight extra hard.
I suppose it also depends on company culture. What happens if a technology you have never seen before is selected for your project? Are you given some time to learn and is it expected that your initial contributions will be smaller, or are you supposed to be just as fast as people who used it for last ten years and get negative reviews otherwise?
>Not much real advice on the behavioral side, to the point that people often take trainings for behavioral interviews and memorize “leadership principles” and other nonsense.
This is what FAANG interview generally look for so why is it a surprise that potential hires focus on it? Amazon literally says that you need to highlight all the leadership principles in the stories you tell when answering behavioral questions. Granted, FAANG barely asks behavioral questions for senior engineers (and then it's like 90% project and bureaucracy management) much less junior engineers.
Do you know why Amazon is focusing so much on the Leadership Principles questions, yet there seem to be so many horror stories from people who work there? I am genuinely curious why they don’t manage to filter out the jerks.
As I see it, the Amazon leadership principles are designed to select for jerks. Specifically jerks who make money. Just look at them. One or two out of fourteen indicate to not be a jerk (Earn Trust, maybe Hire and Develop the Best) while multiple other ones rewards you for being a jerk if you succeed (Disagree and Commit, Bias for Action, Insist on the Highest Standards, Are Right A Lot, Ownership, Deliver Results, etc.).
edit: Amazon's goal isn't to be a nice place to work, it's to make a lot of money and everything else is secondary to that. They are so far succeeding splendidly at that goal across multiple verticals so arguably their approach works. I wouldn't want to work there myself but you can't argue with results.
I think that you may be onto something there. I have noted that when I meet (many) ex-Amazon employees, a lot of them (especially on the business side) are not nice people to work with (backstabbing, destructive political games etc).
It's come to a point where I kinda assume that they are likely to screw me/other people if I don't know otherwise.
(Obviously this is a generalisation, I'm sure there are loads of really nice people at Amazon).
You should read the descriptions[1] of those leadership principles, not just the titles. They're not what you think.
Have Backbone; Disagree and Commit is specifically about NOT being a jerk who digs his heels in, and sabotages projects or decisions that they disagree with. Rather someone who is a team player and embraces the decisions of the group:
Are Right A Lot is about constantly questioning your own understanding and being CAPABLE of changing your mind. We literally interview for it by asking about a time your mind was changed on something important.
Ownership is about not saying "That's not my job". If there is some work to be done, and nobody's doing it, don't have a high and mighty attitude about it being beneath you. Just get it done. (e.g. Developers doing QA, Ops, Documentation, etc)
Bias For Action is about taking calculated risks.
Insist on the Highest Standards is the only one that I know jerks abuse.
I recently looked at some of their hiring material, and one of the before after leadership showed a lot of bullshit in the after. The content was nearly the same, but it felt embellished in a way that left me feeling hollow. It was some oncall event, of which I’ve experienced dozens, and the second version just felt oddly misguided for the sake of saying the magic words the interviewer wanted to hear. The leadership principles seems to be reinforcing bullshit. We’ll tell you what we want to hear, and you’ll tell us what we want to hear. Do our principles line up? ‘Who cares? You told us what we wanted to hear.’ It’s effectively a jerk pass filter at that point.
Mind you, there’s some of this in all interviewing, but from some people I’ve talked to, Amazon seems to really love these leadership stories.
Amazon asks senior engineers MORE leadership/behavioural questions.
But no, you don't need to memorize the leadership principles themselves, and your individual stories can't highlight ALL the leadership principles. Some of them are deliberately in conflict with another.
Most juniors have a much narrower focus in their day to day activities. Their responsibilities tend to be far more focused on churning code and dealing with cool or bad tech choices, whereas the more senior you get, the wider or high level your job can become.
professional interview sign seen at the "interview desk" for work placement at an expensive school for digital creatives: "sit up straight; look the interviewer in the eye; wear presentable clothing; answer the questions asked of you" .. I believe the sign was there because that was not occuring in many cases !
My experience from being on both sides of the desk has been that devteams are relatively tolerant of candidates exhibiting personality quirks during the interview process - it's the candidate's skills that are in demand, not their winning personality.
Maybe it's different when you interview at a FAANG company though? I imagine FAANG recruitment is a merciless sausage machine.
> My experience from being on both sides of the desk has been that devteams are relatively tolerant of candidates exhibiting personality quirks during the interview process - it's the candidate's skills that are in demand, not their winning personality.
I'm growing further and further away from this mentality in hiring because the sad truth is most of those folks who come in with "quirks" lack maturity. To me, quirks are "yellow flags" in the interview stage because it means that you're not able to put your own weirdness aside to fit socially when you arguably need to the most. Invariably these same "quirks" come up down the road in the employment with output problems, copping attitude with superiors, weirdness in internal/external meetings, and just general antisocial behavior.
I get that we're all in hella demand right now but I'm starting to go back on my, "I'm just hiring for the engineering skill/talent" as an excuse to overlook yellow flags.
The other thing is contextually, what are the quirks? If the "quirk" is someone being super shy/timid it doesn't even register on my radar as a problem unless it's extreme... I'm talking about the stereotypical "oh so cute dev quirks" like: not dressing appropriately for an interview, interrupting me/talking over me, talking down to me, comparing their last junior position to being Steve Jobs, being sing-songy, inappropriate jokes in any way/shape/form, getting in arguments with themselves... etc etc.
I'm at a point that if you can't act 95% professional in your first interview you're done as you're not capable of being "on".
> interrupting me/talking over me, talking down to me, comparing their last junior position to being Steve Jobs, being sing-songy, inappropriate jokes in any way/shape/form, getting in arguments with themselves... etc etc.
Besides being "sing-songy", none of these things are quirks, they're ineffective communication or untruthfulness of their past positions.
As far as dress and "sing-songy" go, I would agree with the above poster: software development tends to be much more inclusive of these sorts of characteristics. Jeans and a T-shirt is perfectly acceptable attire for an interview. Do your software devs wear suits 5 days a week? Why expect a candidate to do so, either? A candidate I interviewed going, "uh-oh sphaghetti-oh!" when they hit a segfault when running their interviewing solution was kind of ridiculous, but ultimately has no impact on their contributions as a developer. Factoring in these kinds of thins into the hiring decisions is ultimately about including people from a culture similar to your own. Different cultures have different definitions of "weirdness" so selecting based on the ability of the candidate to identify what is "weirdness" is ultimately a cultural litmus test. And expecting male candidates to be shaved, as per your other comment, is just blatant cultural discrimination - some demographics like Sikhs could even sue you for illegal discrimination over this. This cuts both ways, both the case where a candidate in a T-shirt and jeans gets rejected for not wearing a suit and when a suited up candidate gets rejected for being too formal. Both ultimately hurt the company by excluding effective workers.
What is "dressing appropriately". I wore a suit to my very first interview for a dev position and very nearly didn't get the job because they were worried I wouldn't fit in (luckily I was able to explain that I don't usually wear a suit). The other ones in your list, sure. But I don't think those are what people typically means when they talk about quirks.
> I wore a suit to my very first interview for a dev position and very nearly didn't get the job because they were worried I wouldn't fit in
Yeah - I hate this. I had people at my last position give candidates negative points because they wore a suit and I went $%&#ing ape. In positions that I've held in the past it's been the appropriate action to wear a suit due to heavily corporate environments, and I see it as 110% normal that someone puts on a nice suit for an interview. The action of wearing a suit (or tie for that matter) to an interview should never be seen as a "cultural fit" problem - I'm looking at you SV...
Sorry that almost happened to you. That's some bullshit.
---
Overall a nice well-fitting button down + a pair of well-fitting dress slacks is what I would recommend. Personally, I wear a slim fit brand new white button-down (ironed), nice dark blue chinos (ironed, not pleated), and not-scuffed brown wing-tips. Often I also wear a tie, but am considering not thanks to a derelict SF "big-wig" grilling me in an interview as to "why are you wearing a tie?" All I wanted to say is "does it matter?" (offender: you're reading this don't do that again.)
Also get a solid hair cut, ensure you're shaved if male, and yeah - sit up and be confident while you're in the chair. Body language does matter, and your interviewer will subconsciously notice regardless if they're giving you a "pass" or not.
> The action of wearing a suit (or tie for that matter) to an interview should never be seen as a "cultural fit" problem
I would agree and would go as far to say that dress in general should never be a hiring criteria for a non-customer facing position. Unless there are hygiene issues or they are wearing something actively offensive.
I'm slightly more conservative - I've had people show up in t-shirt and jeans and have turned them away because I feel like they're breaking the social contract of what an interview is. Like - totally clean/non-offensive t-shirt and jeans.
In a lot of my engineering roles I have had to be internal/external facing and do things like budget presentations, work with partners, etc. Before that, I was a general web/app dev and we would get pulled along to client meetings all the time to collect spec, ensure that it was a good sales fit, etc. I'm not saying I had to be fully decked-out but being able to throw on a button down and tuck it in means that you "fit-in" to these situations.
For me, if someone is showing up in a t-shirt and jeans it's a red flag that you can't be bothered to dress semi-professionally which has been an occasional (but hard) requirement of me since day-1 of my career. 100% this all is anecdotal, and specific to my own needs/experiences.
I think this is fair to both sides.
I dress casually for interviews not only because that is what I prefer to wear but also in hopes of getting rejected by anybody who would consider that a red flag.
This is in fact the advantage of having a widely-understood dress code for things such as interviews: that way no one has to play guessing games, you just show up as expected and it's one less thing to think about.
Unfortunately, our industry has no such thing, so I always ask before an interview. So far the answer is always "uh, we just wear normal clothes", "casual is fine" or once "just wear clothes, please, this isn't quite Burning Man" (ended up working at the last place), but: this was in the Bay Area, so YMMV.
Dress code doesn't really factor for me, but I've worked for the same place for a while now and we've always been 95% remote. Half of us just wear whatever we slept in the night before. Most people don't get dressed until lunch time. Even in the office it doesn't get much fancier than a t-shirt and jeans. I guess our tech lead wears a button down shirt, but his jeans usually have giant holes in them, so I would call that a wash.
Expecting an interview candidate to wear something nice would feel a bit hypocritical.
Ha, you "went ape" when someone saw as negative wearing a suit and you're doing the same in reverse.
Bradley speaking, if you go to interview for lawyer position you wear suit, if you go to interview for developer position you don't wear a suit.
> you can't be bothered to dress semi-professionally
It seems to me that you're making an assumption about what is considered professional dress. I feel like it's fine to have such expectations, but you should express them clearly in the invitation to interview. It's not a case of "not bothering" if you have never expressed that preference in the first place.
I think nowadays it would be fair to tell applicants what is expected for an interview in regards to dress. I've been judged for underdressing and for overdressing. Just can't win and it's unfair to expect someone to read your mind.
Dressing appropriately does not mean "dressing up". It means dressing slightly above what is generally accepted as the normal dress code for the role your interviewing for, and the culture of the company. This is what makes it so hard, if it was just about putting a suit on everyone could do it.
If you're completely unsure, just call the hiring manager and ask. "What's the dress code at company X?", "How do people in role X normally dress at your company?". No one will be mad at you for making an effort and trying fit into the culture.
:-) I went to an interview (London UK) for a big name agency suited and booted and was interviewed by some one in a scruffy t shirt that looked like his dog had been sick on it.
I sort of twigged that I was over dressed when on the way to the interview some one stopped me in the street and asked me the way to the "Ivy"
I was treated poorly and mocked at an interview for wearing a sports coat over my jeans and t-shirt. Just can't win sometimes. In the end, not the kind of place I wanted to work.
Believe it or not, checking if the candidate is able to dress professionally and appropriately for the occasion is one of the major things being tested on most white collar job interviews.
> Invariably these same "quirks" come up down the road in the employment with output problems, copping attitude with superiors, weirdness in internal/external meetings, and just general antisocial behavior.
Yep, I’ve been that guy! Had huge problems for a while. Mercifully my team/department/business put up with me for the most part, but I did have to suffer for a while. Learnt some invaluable lessons though and I’m quite happy to be a fitter happier and more productive individual! (Yes Radiohead reference but really not as bad as it seems:)
To me, quirks are "yellow flags" in the interview stage because it means that you're not able to put your own weirdness aside to fit socially when you arguably need to the most
My response from the other side of the table: as an interviewee, I view these initial interviews an an exercise in expectation management. I don't consider myself as weird, so I act like I normally would, otherwise I'm setting myself up for failure later on.
Also, I don't wear to an interview what I wouldn't be comfortable wearing on a normal working day. I dress casual on purpose (but representably casual, not weird casual -- but that's my personal opinion of course).
Personally, I don't really care how anyone dresses. (Oh, up to a point. One of the jobs I had evolved to, "No tube tops, bicycle shorts, or French maid outfits". The last two involved one senior hardware support guy.)
But the other things? Oh, yeah. I've worked with (or attempted to) people like that, and I won't do it again. The first time a technical difference of opinion turns into a suicide threat, I'll just clean out my desk on my way out.
I would agree although sometimes this is a little too much. I have seen instances where they solely focus on the skills and end up hiring jerk. Ultimately, that causes way more trouble than a weak skillset.
An interesting experience I had at a previous company was that they really put culture almost above all else. It sounds great, but in all honesty it was actually depressing and horrible after a while. It almost always came down to, "Well we don't want to hire X person, because it's not a good culture fit." The real issue was that they wanted to hire people they could hang out with / mold into their way of thinking. No new ideas, and everything pretty much stagnated. If that's what you were looking for, then it was great, but people who think like that aren't typically the ones that can hit the homerun when you need to.
I think it is because the older you get you realize that all those projects are anyway just notches on some stick. For example everybody with some experience will choose a boring project with aweseom colleagues over a cutting edge project with a bunch of self-obsessed nerds. Life is short.
I really wonder whether this is a symptom of an industry that's bad at evaluating technical ability rather something that should be elevated. IME the best programmers by far are those who solve difficult technical problems quickly, whether or not they're abrasive. I don't like when they're assholes, but it doesn't matter. They still have more impact.
I used to buy into the whole "communication is king" idea but the more I program the more I just don't think it works that way. Most good coders I know communicate clearly as a side effect of being good, even if they're otherwise completely socially crippled, and they're way more productive.
You ever wonder if there's some kind of bias? Like successful people people (not a typo) will be more outgoing and likely to give advice. A successful tech focused person might not be blogging and giving unsolicited advice.
Definitely. In my experience, the nitty gritty "labor" part of software development, the actual process of learning and writing code, gives great satisfaction and enjoyment. But after a few years, a few projects and / or jobs, and especially once your hard work is effectively thrown away in favor of something newer and shinier written and advocated by younger and louder people, you get more cynical.
But once you get over that, you realize that code itself is just an implementation detail, and it's the people higher up that have more influence. As developer you get paid an X amount a year, that's about it; as a higher up, you get to play with millions, both as money and as 'resources'.
As a developer you'll learn your limitations, that you cannot solve everything and that you alone are not good or fast enough to tackle nontrivial projects (currently in the middle of that, single developer, at the current rate it'll take years for my software to become viable. At least I'm on the payroll). If you have bigger ambitions, climbing the ladder is the way to go. Personally I'm hoping to be able to get a small team together in the coming year.
The author doesn't state much about himself, so it's hard to tell from the article who he is and what he's been doing last 10 years. Obviously if he's mostly in the management/not coding he'll not focus on the programming advice.
If you are junior you would make mistake to ignore technical aspects of work (stacks, what to learn, how to develop, deploy and maintain) in order to focus on communication, trust, teamwork, documentation, clarity. While communication is somewhat important for juniors, but usually the technical aspects are even more missing. It is when you have technical aspects down when the other aspects start to matter more.
Also, juniors are not in political situations where the other aspects matter all that much. Generally, they find themselves in simply political situations. As long as they are not downright toxic, it is ok.
I think there is the effect of weeding out people with strong technical skill but low focus on “people” skills (not talking about jerks, just people who don’t play politics).
Honestly I don’t think it’s a good trend or that it’s unavoidable.
We shouldn’t look at the world today and take it straight as a lesson of what should be done. A bit like saying being gorgeous, extrovert and good negociator is the key to success, it sure can be but it shouldn’t be the goal of everyone.
Both, to some degree, matter. If your team makes poor technical decisions, that could spill over to eroding team trust. Your success is generally tied to how your team performs in aggregate. If your peers mess up, that could impact you professionally as your team's overall standing within your organization declines.
Technical skills were greatly undervalued anytime past a couple of decades ago so it makes sense, at the time they were building their career there where no highly paid people who weren't manager types.
And over the last decade or so this has "trickled up" due to the interview process: experienced and even senior engineers are essentially funneled into the areas of focus you mention.
Goldberg is talking about a longer term view and I think in general, after working for more time your job becomes more about interactions than the "knowledge" you have.
1) All of those people aspects are very, very important.
2) Stacks don't matter. Languages don't matter. Editors/IDEs/whatever-the-hell-else doesn't matter. What I used to call a "firm theoretical grounding" does matter.
What does that mean? At the base, the ability to write clear code that other people can read, and the ability to read code that other people have written. (Don't laugh, it's not uncommon to get called in when someone has bugs (or features) they can't get fixed after they've painted themselves into a corner.) (For me, the key to this is formal logic and what is variously known as axiomatic semantics (http://homepage.divms.uiowa.edu/~slonnegr/plf/Book/Chapter11...) or Hoare logic, or predicate transformer semantics. Theoretical, right? But the ability to think about a piece of code as a block of text, without "simulating the computer" is darn useful.)
Further, algorithms and data structures. No, you don't have to memorize a bunch of algorithms. But it's a good idea to understand what kind of things are out there and what they can do, as well as having experience writing them yourself. (I get downvoted a lot, but I do have to point out that everytime anyone puts code in an editor, they're building a data structure or writing an algorithm.)
Then, at least some knowledge of computer architecture and all the stupid little electricy bits. :-)
Then there is a stack of things that build on that, some of which are only relevant to some tasks: databases, network protocols, and so on.
None of this has changed fundamentally in 30 years. The only major change I've seen is an increase in the importance of continuous math---which I noticed because I've always had a hate-hate relationship with trig and calculus and so on. But all of machine learning and statistical techniques are based on that nastyness, so you can't ignore it any more.
Why does nobody mention technical things? For one thing, they're hard. You can practice communication at the grocery store. Not so much with technical matters. Further, the people aspects are important everywhere, whereas technical things just aren't. And at some point, it's easier to convince some one else to do the work while you have the ideas. (Personal motto: Ideas are cheap. Implementation matters.)
Finally, technical mastery is not really encouraged. Outside of academia, there are no real incentives for it. (Inside academia, there are almost no incentives for it.) After 20, 30, or 40 years, people will migrate on to something else, even if they don't like it or are really horrible at it.
I only half agree with this. I agree that there is no one perfect language or stack and that there is a reason for there being so many alternatives. I also have worked with a fair share of languages and stacks by now and am not afraid of picking up any new technology when necessary.
But languages and stacks do have trade-offs. Sometimes the trade-offs can even be almost prohibitive (e.g. there are stacks I've worked on that were so immature they were a legitimate liability to the product and business, even if of course we would find some ways to mitigate them (but you can't mitigate something you're not even aware of)). In other situations, it depends a lot on the context: what languages/stacks does the team/company already know? What sorts of libraries are you going to use (there is no point in trying to use Ruby for an NLP project, for example)? Do you have special requirements in terms of performance, parallelism, etc. (that might exclude some languages)? And so on.
Agreed with the rest of your comment, and I want to add that "the ability to reason about a program in your head" is also why I tend to prefer functional programming with immutable values (even though, of course, that has its own set of trade-offs).
True, it's not that the stacks and whatever don't matter at all, just that they'll change, you will have to learn new ones, and so any kind of religious attachment to one is a sign of an amateur programmer (in the Gerald Weinberg sense).
I, too, really like functional programming for that very reason. :-) It just isn't the approach I grew up with, and the functional programming manner of dealing with imperative is still a bit hard to get my head around.
I couldn't agree more, that said, I believe the difficulty for new hires in software engineering typically comes from the relentless focus on coding interviews.
This is the opposite of what you get from new hires/juniors: they tend to focus on which stacks matter, what to learn, how to develop, deploy and maintain. Not much real advice on the behavioral side, to the point that people often take trainings for behavioral interviews and memorize “leadership principles” and other nonsense.