Senior engineers who don't code
josvisser.substack.com
josvisser.substack.com
I still fail at coding interviews, and I attribute it to the gamification fatigue and age.
Please understand me. I have a leetcode account but I can not force myself into solving puzzles in my free time after solving them all day long at work. And puzzles at work are more interesting, because they are real people's problems.
I avoid board games for similar reasons. Whenever I sit in and play, I enjoy being in the flow, the conversation, and the intellectual challenge. But dragging me in is damn hard.
On the other side, I am much more into sports nowadays: running, swimming, skiing and hiking, as if I was making up for my younger years spent in front of a screen.
I feel like I have to carefully choose where to apply my intelligence because I am not as resourceful as I was. But I am wiser.
Would you hire me? No. Would I be a net positive for you business even if I cost double your younger self? Probably yes.
The problems at work are also real, actual problems.
I have trouble with the coding section of the interviews but I do know how to write code. If the coding section of the interview was like "build me a ci pipeline for this app" or "find all the workloads in this cluster which need X attribute" or "design a terraform module to do Y" then I would pass with flying colors.
In the average SRE role, it has been my experience that there are very few situations where I would need to build out a perfect O(1) algorithm. Nothing I write is going to be so heavily used that this level of performance is something to be concerned with. These are the only code problems I really see when interviewing though.
In my experience, the algorithm-heavy interviews happen at large companies that use it as an extended IQ test to filter out people who don't perform well on mathy problems, psychologically or problem-solving wise. The argument is that with their influx of applicants, they can afford false negatives (a good programmer failing an algorithm quiz) more than false positives (a bad programmer passing a personality test).
I've had live-coding interviews where I consistently felt so dumb with flashbacks to my worst oral exams at uni.
And I've had live-coding interviews where I aced it so much it felt like improvising teaching material.
I don't understand this line of thinking, especially at the Big Tech companies. You're hired on a probationary basis, usually six months. If the candidate seems reasonable then hire them. It's sink or swim time.
Where is that the case? I have never heard of such a practice, and I don't remember that being routinely done at either Microsoft or Google.
This statement should be clarified:
You probably don't fail all coding interviews.
The closer your test is to realistic work (without realistic time use), the better you'll perform.
When interviewing for a senior position, what should matter is all of those secondary abilities.
Your ability to code should be a formality at this point; I think the touchy subject is that some engineers are primarily senior by age, and some by work-year inflation, and so are expected to be better in all possible ways than anyone with fewer years on their back.
I interviewed for a position this year where they requested I solve problems for a full workday.
I don't mind spending a couple of hours solving a programming problem (and risk failing), but I'm too old to spend an entire day working for free to get a chance at advancing to the next interview level with 3-5 other candidates. I could be making money, seeing friends, learning things, building things.
Looking at Glassdoor for that position, I saw someone say they spent 25 hours and 4 interviews to finally end up declining the offer because the company was being sketchy with the terms.
I have friends who love puzzles. I just always ask: Will my effort compound? If not, it's a tough sell. My time is precious.
I don't want to work for a company where people think performance on a coding interview is important for a "senior" role. Those people are wrong. Oh, except now "senior" applies to anyone with 3 years in the industry, and most likely those people don't really know what they are doing.
My suggestion: stop with the title inflation. If you believe you need to know if someone is competent in trick coding problems you should not be interviewing them for a senior role. It means your concept of "senior" is wrong and you should feel bad.
Better yet - don't reach out to employed, senior devs for a role, then play these "gotta see if you're a faker!" games.
It's like asking someone on a date, then asking for an STD test once they agree.
Maybe you should talk to the unemployed devs!
I've managed before and what I found aas that I didn't need to be as good as my best reports at their functions, but I did need a solid working grasp of their fundamentals.
That said, requiring mastery of 'hard'-level problems is silly.
OK, for an entry level to junior programmer trying to get into the mid-career levels it's possible that leetcode problems are useful for weeding out garbage programmers, folks who went to a code camp program and don't know anything about data structures and algorithms. These days what's called "senior" is, thanks to title inflation, really a mid-level job at best. For genuine senior work, which is sometimes called Staff or Principal level, the important skills are softer. There's a point where pure programming skills are complementary to the ability to understand and work with the business and understand how the organization generates revenue. At that point, whatever title it might have, the ability to solve an easy leetcode problem has no bearing on the ability to do the work expected. The challenges at that level are not "how do you code X", but rather "does coding X solve a problem that contributes to revenue, why or why not?"
It's also easier to objectively evaluate coding interview performance compared to "softer" interviews, which is helpful to reduce bias in hiring decisions.
It is not an accident that coding interviews became the norm. Many of the most successful engineering organizations in the world are known for their coding interviews. Just because you don't like them doesn't mean they're an ineffective tool.
> objectively evaluate coding interview performance compared to "softer" interviews, which is helpful to reduce bias in hiring decisions.
No, because those coding questions are themselves biased towards people who have the same experiences as those asking them. It's exactly the same as IQ and SAT tests: the bias is hidden in "objective" results. Men outscore women by an average of 37 points on the math section, and 7 points on the reading section. Asian students score the highest on average, with white students trailing them by 22 points on average, and black and hispanic students trailing white students by an average of 50 points. Finally, students who receive need based aid score an average of 20 points lower on both sections of the test. These results are held up as "proof" that white men are better than women of color.
> It is not an accident that coding interviews became the norm.
It's true. They became the norm because they allowed organizations to hide bias under cover of "objectivity"
> Many of the most successful engineering organizations in the world
I wonder how much more successful engineering organizations that didn't bias against applicants that score poorly on these tests would do. Unfortunately, we don't have a control group, so crowing about how great this or that company has done when comparing them to organizations with similar biases doesn't provide much insight.
And the suggestion that coding interviews are biased is insane. Everyone has access to leetcode. Virtually everyone can buy a copy of Cracking the Coding Interview. It's the one portion of the interview that doesn't rely on having the right history or circumstances. If you work hard or are naturally gifted then you can succeed on the coding interview.
Regardless, the author's point stands. It doesn't matter whether you think coding interviews matter. As long as they exist, you'll have to play along to get certain jobs. Selfishly I should stop trying to convince potential competition to embrace them.
As someone who has fun coding: this guy's a lunatic. Avoid them in a work setting.
> Don’t have that feeling. Even for a senior engineer, coding is worthwhile. Just don’t do it so often and so much that there is no difference between you and a more junior engineer...
This is rather incoherent. Am I allowed to have fun?
Yes, but you should feel guilty about it.
Grim reality
That should mean you're fully capable of doing anything from writing good quality code to going to bat for them in a meeting, writing documentation, SSHing into a VM to put out a fire, etc.
A senior dev should have done plenty of that before getting promoted to senior just not all at once. What's special about writing code and why are some people so afraid of "forgetting how to code"? No offense to anyone but sounds like a load of bs to me from someone who isn't ready and works at a place where that promotion is forced due to lack of choice.
BINGO!
I had been a developer for 20 years before becoming an architect - which was 20 years ago. You have to continue coding. It's an imperative. That's how you stay relevant and continue to provide good solutions and how to best apply new technologies.
There's also the fact that developers respect those who can code and you can't call yourself a "tech leader" if your team doesn't respect you.
In other words: If you have the MIPS and RAM, why pay for a top software engineer to do things efficiently when you can simply hire a way cheaper kid, point them at something like SwiftUI and achieve the same business goal? The problem is, you can't just fire the software engineer if they're over a certain age without showing they're unable to keep up, which you do by shifting the rules of the operating platform. The strategy fails only when the MIPS and RAM become limitations (or when the EEOP enforcement agencies around the Country figure out what's been going on since the microcomputer vendors took control away from the established mainframe and minicomputer vendors during the late 1980s and initiate legislative and/or regulatory changes).
It's your duty as a senior engineer to overcompensate for all of that. Pay will be the same wether you do it or not.
When I ask you to implement and discuss an advent of code style solution in 50 minutes it is because there is an expectation you are an exceptional violin player and I simply want to enjoy listening to you play. We choose the members of our ensemble based on many criteria and one of those is a rather binary proficient / not proficient violin playing test.
(As a senior member of the ensemble you will be expected to also show expression in your playing, be self aware of that expression, have an understanding of music theory at a large scale, an ability to communicate clearly and with confidence so that you can coach others in their playing, etc.)
I’ve been a violin professional for 25 years. I find myself doing just as much violin review as I do violin playing. If a junior dev, sorry, violinist is having trouble with a piece then the best way to show them is to play a few bars myself to show them an abstract example of how their playing could be different and better. Who will listen to my advice if I’m ham fistedly scratching out a fiddle dirge, when doing so?
Sight reading the way coding challenges are done is sometimes listed as a requirement, but extremely rare in practice according to my orchestral neighbors.
For coding interviews I do require that my recruiter tells the candidate pretty much exactly the way the day will pan out. If a candidate ever arrived and was surprised to be given a leetcode (lite!) challenge then something would have gone horribly wrong. An interview without signal is a waste of everyone’s time.