Ask HN: I'm 10 years into CS career, but rarely code anymore. Is this normal?
I now work at another large enterprise, and find myself being more "architect" than "developer". I spend time discussing vendors, high-level design, architectural decisions between domains, and just more overall "steering" strategy than coding.
Is this normal? And further -- is this "OK"?
Some more context:
I enjoy my work; I especially enjoy being involved in the higher-level issues and strategy. I enjoy working with other decision makers, and might even enjoy it more than the hands-on coding work I used to do.
However, I worry that I'm losing my edge. If I want to job switch, I'd be fucked on the LeetCode stuff. I could study it no problem, but I'm curious how much pure coding skills impact my career trajectory. As it stands, I'm not entirely sure where I'd move next but I want to ensure my skills are valuable (e.g. I don't want to become stale!)
75 comments
[ 6.0 ms ] story [ 118 ms ] threadThis is totally normal. If you like doing that keep hammering away... I 100% believe system thinking is more valuable than leetcode when I interview Senior or higher.
In order to keep your edge and facilitate the use of your architectural designs I would recommend implementing skeleton, or proof-of-concept, implementations of your designs that your colleagues can use as examples or templates.
I wouldn't worry about being fucked on the LeetCode stuff as your 10 years of employment should move you past that bar.
Furthermore, I've coded for over 15 years, worked with people that have over 30 years experience, and all of us would have a rough time of it since we've been busy doing other stuff.
I have a buddy that is a pure coder -- individual contributor type of guy. He will often share his latest clever idea in some code snippet, and while I understand it abstractly, I feel lost when I focus on the finer details. I definitely couldn't sit alone in a room and come up with it myself at this point.
At the same time, _he_ is a bit lost when I talk the more broad architectural stuff I work on.
Thus, I often go back-and-forth on what I should be focused on, especially as it relates to future opportunities. It's helpful to hear I'm not necessarily abnormal or falling off (as it sometimes can feel).
Any FAANG will still give you algorithm questions in interviews, even at a Staff level.
1. Why do you assume people want to work for FAANG? Those are the last places I want to work. I know many people like me.
2. Algorithm questions - you can't forget your algorithms. At this point that would be like forgetting how to ride a bike. There's stuff I learned decades ago in unrelated fields that I work in that I still remember. Even so, it's not lost on anyone that extensive knowledge of algorithms is rarely important in actual day-to-day development work, and the things that are important interviewers rarely dig into.
¯\_(ツ)_/¯
I remember plenty of algorithms and the general ways they work but coding them up on the fly without any errors is another thing when out of practice.
It’s more like training for a race. Yes, you can pedal and get there eventually but compared to your competition - you’re coming in last.
Again - done this a lot and have worked with a lot of others. Spending half a year is very very common. Those who never stop practicing tend to only need a couple months - but they like that shit so that’s why they do it to begin with.
As someone in that position, it unfortunately has not.
That being said, I refuse to spend any of my time on preparing on LC. I recently lost out on an opportunity at Facebook over this.
Someone from a specific team had reached out to me, was extremely excited about my background, assured me LC would not be a large signal due to my experience and that other rounds would matter more and referred me.
Because of their strong interest I was given a do-over after a sub-par first LC.
After the second LC I was told they wouldn't move forward (so much for other rounds mattering more?)
-
To me it's a sad comedy. I'm sure a fresh grad who couldn't code a "Hello World" without autocomplete would have outperformed me on LC by virtue of remembering algos I have long forgotten and having the time to "chew and pour" as we say in my country of origin.
Now a team loses out on someone who was (by their estimation, not mine) a great match because of some shibboleth that would have never come up in day to day work?
Obviously I went in willing to potentially accept an offer, but to be honest... had I continued after the second LC interview my plan was to turn them down and cite LC as the reason.
Someone who didn't make it complaining is just sour grapes, but maybe having someone they deemed "worthy" turn down their money to point out how ass-backward the practice is would have meant something.
I also think that all hiring depends on internal politics, to which the candidate usually has no insight.
Luckily my wife and I have learned to laugh about it.
It’s a rare opportunity to see other people solve the same problem as you, and I found I discovered quite a few interesting tricks, and was generally in awe of some people’s grasp of DP (I’m quite sure any DP whiteboard problem would stop me in my tracks).
The big learning for me was exactly the kinds of problems I knew I could solve versus those I knew I could not. I got two of the latter in my interviews, and immediately refocused on getting as much help as I could, which worked, and which I now would see as a positive signal as an interviewer. I’m always happy to hear “this is a problem of type X. I know I need to do Y and honestly I’ll probably need some help but let’s see what we can do”.
I actually completed the task fine, but it definitely took me fumbling around a little to get there. I made a point of explaining my thought process and the questions I was asking as I went, but the problem just wasn’t one you come across much in real-world work. (And you know, algos as the first session in the morning before your brain is fully warmed up is brutal)
Importantly, the other sessions (two covering tech they actually use day to day, and a cultural fit one) went great. In the end they passed on me, and when they asked “do you know why?” I correctly guessed it was the lacklustre algo performance. They invited me to “do some study and try again in 12 months”.
Interestingly, the fact that they weighed it so heavily turned me off working there anyway. I was also surprised they didn’t ask me for any feedback on the interview process.
It was a very interesting experience, but I’ve learned that if I want to apply to anything similar in the future I’ll definitely need to grind more leetcode in preparation.
But I’m enjoying taking a break and working on side projects now anyway, and am thinking I won’t be back in an office for awhile :)
They want newcomers who can chew everything.
Their interview process perfectly fits.
I think you transform the way you code (actually writing) to the way you think strategically and make decision. So whatever you write as coder will be seen in design and decision making process.
I'm on a small, special-purpose team and we spend a significant amount of our time investigating what we're going to work on next. From there, we put together docs and justifications that we take to the team that owns that service so we can achieve buy-in from them. We frequently run projects in parallel, so we can end up being the point-person for one project while assisting on others.
I'd say I spend 30-40% of my time actually writing code, though this is extremely bursty depending on the project. The other 60-70% is spent writing docs, doing research, or achieving cross-team buy-in.
You've done what the rest of us do, which is specialize. If there comes a point where you need to LeetCode into your next role, I am sure you can study for a short time and nail it. Your broad experience is an asset on that front.
I often have this weird imposter syndrome, where I sit on calls for 2 weeks and create some detailed end-to-end design. I then take that design and present it to a a team of engineers are are tasked with actually implementing it.
It feels strange to be doing that, and not having a hand in the implementation (i.e. coding). But then, those same engineers are the ones who come to me for the high-level questions.
Well, it's at least typical - it happens to quite a few people at about that time in their career.
> And further -- is this "OK"?
> I enjoy my work; I especially enjoy being involved in the higher-level issues and strategy. I enjoy working with other decision makers, and might even enjoy it more than the hands-on coding work I used to do.
Then, yes, it's OK. It's good, even. There's nothing wrong with doing work that you enjoy doing.
I try to sharpen the knife with side projects that keep my interests in programming high, but at work it is just a minority of my time.
Anecdotally, I have moved twice from higher engineering management roles (VP / Director) to Senior / Principal level IC roles and I am a bit older than you. It does take a bit of work to find the right IC position to shift into at the right company when you are ~recovering~ moving from management/architect roles.
I feel it is very helpful to be up front right away when you interview and express that you want to be more in the trenches with hands on coding. There are a lot of companies that want IC developers to have architect-like "spacial awareness" experience on their engineering teams. It's a valuable skill. Lean into it.
There are a lot of contradictions and one has to come to terms with what fits to ones values. The market prefers specialists but generalists often tend to get more stuff done and thrive once inside an organisation. In higher technical roles management skills are often key. Likewise in management roles being grounded in hard facts can be a plus. None of the HR advertised "career paths" help here much as one learns best by doing very hard for real - technical as well as managerial. Switching is hard and takes time but on the other hand one learns a lot. Nothings free.
Managerial skills age better so recovering (jdoss stressed that word for a reason) from a technical doing break does require some planning and having the right environment around one. It also requires having reached real depth in coding, design and architecture beforehand. Part of my job currently requires me to do some training and coaching and I find that really satisfying helping me to recover technical skills and have a positive long term impact on people.
And as it is easier to keep a skill than to relearn it from far behind I would spend 1-2 hours a week on true, raw coding. Leetcode, hobby project, whatever. My 2c.
Your skills are still valuable, but the problem is that many companies don't separate architects from developers when hiring, and that's why they subject their potential architect hires to the same LeetCode coding stuff. So when you switch jobs, you might have fewer companies to choose from, or fail a few more interviews from companies that insist their architects can get down to the nitty-gritty details of coding. It's a choice you'll have to make.
A longtime ago I had 40 developers under me and frankly hated it. Went and got a contract as an individual contributor, wrote some FOSS found I was happier.
Every few years I have to decide between the no coding daily route and the coding daily route.
It frustrates me that there has to be a choice. Let me explain.
I am (honest) writing a book about software literacy where I conjecture that software is a new form of literacy unlike the other analogies like driving a car is a lifelong skill and importantly will force society into massive meaningful change.
So let's rephrase the question :
"I used to write English everyday, but now I am going to become an executive and will stop writing English and instead set guidelines for other people to write English"
It's not you. It's that we (all) work for software illiterate organisations. Getting promoted should not mean stopping writing code.
It should be part of a natural day to day work. Why is it ok that an executive should spend a day buried in a spreadsheet but not buried in pandas code?
At a certain point the whole organisation should push to the CEOs repo. At that sort of level I can imagine they won't write production code, but they should damn well read it, approve it and write their own for their own (executive) purposes
You won't fix this. But fight back against it. Somewhere there is a project at your company that presents important data in a web form, and maybe has a download in excel button, but has no API, and worse only allows downloads by human SSO not machine tokens.
Every time you can make "programmatic access" a first class citizen. It's a start. Others may think of other ways to start
Many managers are promoted engineers who feel more comfortable with code than people management. So when they don't want to hold 1:1s, don't want to deal with an interpersonal problem on the team, don't feel comfortable escalating an issue to management, etc... they instead pick up tickets and start writing code as a way to kind of procrastinate. This is bad because the organizational structure is such that the manager is often much better equipped to deal with such issues than the dev team, so they can go unaddressed.
What I am trying (badly) to convey is that we should build software-driven organisations - where the processes and policies, the back-office if you like, is software driven and so if you "the executive" want to chnage the company you do it through explicitly changing the code.
The difference here is openness.
What your argument means to me is a need for democracy and openness in companies.
Companies should have two ladders. IC ladder and management ladder. Where companies fail is that they make the IC ladder less about actual work and more about documents, RFCs and 1-pagers and other nonsense.
They start measuring productivity by these docs instead of actually building something, thus setting perverse incentives for a promotion.
Docs, RFCs, designs are all means to an end, not an end unto itself.
If someone is trying to improve their performance as a manager it needs to start with real assessment of the core functions of the job, and those don't include coding. Too often people tell themselves they need to make time to "stay sharp" with coding when what they really mean is "I don't know how to tell Karl to stop micromanaging Hayden, and I don't know how to get the Widget Access team to stop ignoring our bugs, but I do know how to write a rate-limiter". Then it becomes "oops, this rate limiter is pretty involved, so I didn't have time to talk to the WA team. I guess I'll get to that later".
And if we think the manager should go fight and persuade the organisation it needs a rate limiter then, yes. But they will need to write code to show the slowdown in latency, calculate the cost in servers if we don't have this etc etc.
And frankly that sounds more valuable to the bottom line than whether Mary is being micromanaged.
There are always always trade offs. "people management" is rarely about inter-personal issues arising to the level of HR like action. It is for more often enforcing standards on the job. Oh like linting.
Less and less human stuff cannot be improved with coding and almost always the solution built in is insufficient, and customising it at enterprise level slow and costly.
I agree don't do the job you left behind, but that's is not the same as stop coding. The software literate company will need most software not less.
I couldn't disagree more with this perspective. Interpersonal relations are not reducible to technical problems, they require getting buy in from other people.
> And frankly that sounds more valuable to the bottom line than whether Mary is being micromanaged.
What if Mary (or in my example Hayden) leaves the company because they're tired of being micromanaged? Engineers are costly to replace which is why we have people to keep track of the human side of things.
- model - monitor - mentor - resource allocation
Using Software to "run" the company will encourage openness, reusability, and robust discussion. This may not be what executives want.
And yes Linus Torvalds will inevitably come up here. And I think he is an excellent model (excluding the stuff he resigned / apologised for). He does / did not write code that goes in the kernel, but will write things that solve his executive needs (everything from mailing him when his local build has finished to, you know, git). These things will mostly be open, and beneficial to the "organisation".
No his job is not to write kernel code. But that's not to say he writes no code, nor is that code not useful in building the whole organisation around the "factory floor" job.
Anyway, the model / Monitor / Mentor thing - yes of course software will help building such things. And yes of course there is proprietary code out there (SAP etc) to kinda sorta do that but mostly it all devolves to executives downloading everything to excel and writing their adhoc queries in excel to answer the problems they face today.
There is zero point hoping SAP will write a custom what if filter for Company X's problems with holding US Sales in Dollars or Yen.
And there is a big upside in thinking if they were coders, and did write that query and made it open inside the company it would be reviewed, challenged and improved. And maybe even open up debate in the company but that's politics ...
That being said, I don't think it's wrong to step back and look at the bigger picture. Just because it's not for you doesn't mean there aren't people who love it, or even prefer it! After all, coding is just a tool. A very finely set tool, but just a tool and nothing more.
Then again, you can have situations like Linux, where Linus still looks at every bit that comes into the kernel, so who knows.
[0]: https://www.youtube.com/watch?v=r2mC4k9Rghs?t=2m04s
If the CEO is spending a day buried in spreadsheets, then he's likely spending time the wrong way, or is operating a very small business where he can afford to do such things.
Again, the idea of "pushing to the CEOs repo" is actually crazy for all but the smallest shops. There should be no "CEO's repo". There should be "org x" repo or "product y" repo.
I agree with your sentiment that a working knowledge of programming should become something like a working knowledge of Arithmetic. Every educated person is expected to know basic addition, multiplication and so on, and also be able to use a calculator to perform these tasks. Similarly, every person should be taught the concept of a Von Neumann computer and writing programs in a simple programming language. However, building software product vs. writing a basic computer program are, again, two very different things.
Honestly writing English is a technical craft. It's just one that 99% of the country has been practising this craft daily since age two. There is literally nothing else we are all so well trained at. Maybe washing?
As a senior engineer you are more valuable doing all this than hammering out code. If you enjoy it and are doing real work/adding real value to the company then this is a good career path to continue on. You are ultimately paid for the problems you solve, not the number of lines of code you write.
You can worry about Leetcode if/when you decide to switch jobs.
Your value comes from solving problems, not from typing code.
With time and experience you learn to solve the right problems, and sometimes throw away non-problems, saving massive amounts of money and resources.
As a side note, this appears to be the way for many other technical careers as well. For example, I know a prototyping engineer that bemoans a similar path. The more responsibilities you have, the more you delegate, and it snowballs.
As for "ok", that's entirely up to you. If you enjoy it and find fulfillment, then I think it is. I have a co-worker who's been with the same team for around 10 years, is at a manager level, but is perfectly happy to stay at the individual-contributor role. It's really about where you find the joy.
As for switching to another job, you probably wouldn't go through the LeetCode stuff, if you didn't want to. You'd likely move straight to manager, where your skills are currently. I imagine they'd be smart to not waste your time and just look at your resume.
Also, for me at least, I try to code at home to keep my skills up to date. So if it happens to be the case that I am not coding on a particular assignment, that I make sure to keep the skills sharp by coding on side projects at home.