30s and “senior” software engineer, but I suck at programming

Leetcode isn't programming. Leetcode is pattern-matching which rote-memorized algorithm will solve a problem in the expected time/space. If you want to get better at programming, find some side projects you're passionate about and make time to work on them (if you can). If you want to get better at leetcode, force yourself to do them N hours per day. If you find both of these distasteful, you'll have trouble in your dev career, and might find management more enjoyable.

"When I'm not working, I sometimes think I know something. When I am working I realize I don't" - John Cage

Programming is not a hard science, it isn't a bunch of Engineering tables, there is no equation that returns an app. Donald Knuth said it then, and it is just as true today, Programming is an ART. You have techniques, usually they mean nothing, or need real massaging, you have experience, but the conditions have changed, you have a reputation, but you don't 'paint' like that anymore.

and those tests HR hands out. Man, don't make me laugh. You want to be a journalist? Ok, let's test your typing speed, oh, fine, ok, you're hired. It is not only madness, but I suspect it is a contributing factor to the horrors my industry has unleashed over the past 50 years. My teachers didn't call themselves "computer engineers" unless they built chips, no one said "software engineer" except maybe NASA; I think we could do better as computer /scientists/ but industry doesn't /do/ science, there's no money in it.

#end of curmudgeon rant

what you have is the ability to see the problem to be solved, the facilities and resources that may be available, maybe not, and a mind that folds, and sifts, and tucks and whittles and reforms that chaos into something no one has ever seen before, nor will see again (competitors legally can't replicate your experiment!) and that, I would say, defines a software program more than it describes yet another condominium or suspension bridge clone.

So, now, what is it about the reality of the situation that makes you think you suck at it? Right: EVERYTHING. We /all/ suck at it, every last one of us to the end of our days, because it is like music, or painting, or writing plays, no matter how many times you try, it always falls just a little short, and somewhere, painfully known to you, someone else does that bit a bit better. John Coltrane admired John Gilmore of the Sun Ra Arkestra, he said, "John has it."

That feeling is not going to go away, sorry.

So ... what needs doing now?

You know, I used to feel the same way, "good at my job bad at leetcode", but after asking around a bit, now I'm genuinely wondering how many people out there actually can get optimal solutions on leetcode problems without any practice - which seems to be the real insecurity that gets under people's skin when they write another lamentation on the state of tech hiring.

It sounds to me like the primary purpose of these difficult DSA questions seems less about accurately gauging one's ability to do the job and more about paring down a veritable tidal wave of applicants that big-name companies like FAANG routinely get. As such I don't think it's so unreasonable to get demolished by these kinds of problems if you haven't done any practice at all on them. Rather than looking at it as an indictment of your programming skill, it's probably more indicative of you not having trained enough for the "FAANG-lympics". They're all basically competitive programming problems. Of course you're going to get demolished if you haven't trained for a competition.

With that in mind I think if you look at smaller shops, they may not give you these academic-tier math questions (I know we sure as hell don't), more stuff like fizzbuzz or recursive factorial or any other very trivial whiteboard style question. At least where I work I know we don't get people beating the door down, and if we just cargo-culted Google's process on the comparative trickle of applicants, we wouldn't get any asses in the seats at all. Of course we also can't afford to pay FAANG-tier wages.

I guess you can look at it like this: the highest paying jobs all have the most difficult interviews. Almost everyone I talked to literally practiced to do them, it's not a talent thing, or might not be anyway. This can be avoided by applying to smaller, less-paying shops, so I guess it's ultimately a question of how much you're willing to practice and for what salary.

95% of developers don't have to solve actual algorithm problems in their daily jobs and very few of us actually do leadcode style of programing. I'd agree that an algorithm book/course will help, but solving people's problems is not always the same as solving algo problems. So, yes, read on the theory, but also look for companies who are just looking for people with practical skills. Good communication and diligent work are diferentiators as well.

If your job is to solve Leetcode type of problems and it is under threat, then by all means feel free to depress yourself.

If your job is to put out functional products within a team to the consumer so that the company can make money to pay your salary, then you have nothing to worry about.

I also had that problem, I grinded through 200+ problems but I felt like I was just memorising leetcode solutions. I dont wanna be a shill but if you can pay, then check out a site called structy.net, it's a hidden gem. Nevertheless you dont need to pay as 50% of its content is free. Compared to famous paid interview prep resources like algoexpert, it's way cheaper, explanations are more succinct, and personally I find it explains things better.

I worked through it and I'm confident I can smash leetcode mediums, especially trees and graphs. Arrays and Strings I found to be the hardest at leetcode hard level as there are a ton more corner cases to handle and there's almost no problem solving patterns in solving many of them, unless it's the "easy-hard" type (usually backtracking types like Sudoku Solver are manageable). Most leetcode hard array problems are just pure manipulation and observational/ad hoc types and it's hard to get good at them as there's little practice available in leetcode to ease you to such problems. One has to go to sites like codeforces to practice these ad hoc types, and it's annoying as codeforces problems are mathy. Luckily, those hard array problems dont appear in leetcode style interviews.

Anyhow, structy and the "top interview questions" from https://leetcode.com/explore/interview/ were enough for me to go from "forgot everything from algorithms class" to interview ready.

Fuck leetcode. It's a good exercise for the math inclined. It's useful to do a few to learn how to pattern match. It's not the be-all-end-all of programming. I ask a leetcode question, ask people about approaches, and I'm more concerned that they can write any code and that they can figure out how to problem solve than any particular problem. A good train of thought is as valid as a working solution, though I do expect to see some code (and will ask fizzbuzz if there's not any algorithm for my problem in the first 15 minutes)

Code. Practice Coding, in both leetcode and real forms for an interview. It's an unfortunate necessity that you study a little for an interview, and sometimes a lot.

LC is a bad measurement for your abilities as a software engineer since it only measures a very small subset of what software engineering is, heck, of what programming is!

You spend a lot more time in plumbing and debugging than implementing algorithms, and if you ever have to use one, it’s very likely that your manager would prefer you use a well tested library and move on to the next story in Jira.

Saying that LC is “actual programming” is a bit narrow. Actual programming takes into consideration architecture, code maintainability and readability, judgement calls between using external libraries vs building in-house, proper use of tools (IDE, cli tools, etc…) and a bunch of other stuff.

I’ve suffered working with code written by individual that are good at LC but wrote such unreadable spaghetti code that I wonder if they thought they had a 40m timer like in LC that they couldn’t bother writing a complete word as a variable name.

So no, don’t measure your worth by the fang sieve of LC and the likes of it. I actively avoid companies that use those as their measure to assess technical abilities because it makes me question what type of coworkers would I have.

Well, being a good engineer is about more than knowing all the leetcode algo ins and outs. If you're bound and determined to work someplace that interviews primarily on that basis, treat the leetcode like an entrance exam- cram cram cram and you won't need the leetisms very much after you pass.

Do you understand how to set up testing for the right things, how to design for testability? Do you understand the ins and outs of HTTP and object API design? How to review code for the right characteristics per PR? How to distribute and scale computations, how to build for economical operation as well as CPU and memory performance? How to write a spec or an onboarding doc?

Leetcode is a do-it-the-way-prominent-companies-did-it meme. It's not wrong on its own, but it's one dimension out of many, and the best leetcode problem solver I ever interviewed was a terrible senior engineer.

Just keep leetcoding. I couldn’t imagine solving a medium on my own a year ago and now I’ve done 450+ mediums and have one of those jobs that I thought only “geniuses” could get.

After enough practice, it’s just becomes muscle memory.

You shouldn’t even want to work as a dev in a position that is screened by leetcode. Not because the interview sucks, but because you’re going to hate the job. You won’t be using legos, you’ll be building lego bricks.

It’s not the same job. low level engineering is nerdy and often tedious, and is not for everybody.

You may like cooking, but don’t necessarily enjoy building the oven.

There is a place for people like you in tech. Just do your thing, stop worrying and let the leetcoders be.

Take an algorithms course, or read an algorithms textbook.

You'll probably be surprised at how much better at everyday programming you'll seem.

I'm also on my thirties and having some difficulty with leetcode. Something that has really helped me is Grokking the Coding Interview. It goes through a few patterns for solving algos. I'm not smart enough to figure these patterns on my own and the patterns I have learned have given me a really good place to start from.

I'd recommend doing some of the free Stanford or MIT CS courses online and really trying as if you needed the credits to graduate. Don't quit when it gets hard because ultimately you want to be compensated for not quitting when problems get hard.

Two options are to either continue studying Leetcode questions until you just know how to answer Leetcode questions, or apply at jobs with a more sane technical screening process.

They do exist: I just talked to a friend who was expecting an offer from a large company. He said: "They didn't ask me a single whiteboard question, they just sat down and talked to me about programming. It was weird."

I know this dead horse has been beaten a lot already, but isn't it funny how so many companies evaluate people for a job by asking them to answer questions that actually doing that job will not make you signifcantly better at answering?

I just watched a video today that I think may help a bit https://youtu.be/hIJdFxYlEKE.

Besides the advice he gives in that video, I’d highly suggest trying out Anki if you haven’t. Memory is related to how often you encounter something and with code interview type topics you rarely actually encounter those on a daily basis so it is hard to actually memorize it “naturally”.

But using something like Anki allows you to choose what you want to remember.

A "few years" might be considered a long time in software development terms but in the rest of the world, not so much. To be proficient you need to put in your 10,000 hours which translates into 10 - 20 years depending on how much time you actually spend coding in your current job. In many jobs, the work required of you is mundane and may not provide the practice or challenge you need to progress to the next level, so it may be helpful to take on a side project or other means of building your skills. 30 is still pretty young, and "senior" software engineer is in fact a mid-level position, most senior software engineers have not achieved true expertise. So keep plugging ahead, if you want to get better, otherwise you can always switch roles and go into management if you don't want to put in the time.

Only one way to get better, keep at it. Eventually you’ll learn it, who cares if it takes you longer than what you would consider normal. It would be a shame if you gave up just because it is hard. It’s a worthwhile challenge.

Try not to be in a rush too much, and just spend some time on a particular class of problems that you’re struggling with. Watch videos, look at the solution and try to understand it. Sketch out the given solution on paper if you need to. Implement the solution a couple times until you can do it without looking, perhaps in different ways.

If you just get in a habit of practicing (and do without stressing yourself) and you’re patient, you’ll get there. At first it will seem like you’re not moving anywhere but eventually the work will pay off and you’ll have gained a cool skill, and probably improve your thinking skills in general.

Sounds like you can do a bit of everything. Time to become a manager and make leetcode someone else's problem!

There are different kinds of programmers I find. Some are more algorithmically / mathematically minded. Some are less skilled when it comes to writing the low-level code, but great at architecting and building clean scalable solutions. Others are less interested in the tech generally and more product orientated -- they're just looking to build cool things that users enjoy using (often frontend devs).

I think you first need to understand where your strengths and interests lie. I think I'm probably a bit like you in that I just like building stuff (used to love lego as a kid), but my math abilities and technical abilities are nothing that impressive. I'm a full-stack dev, but I find I'm definitely more useful on the frontend. I tend to be the dev who spends a lot of time tweaking buttons and making the general UX improvements that other devs don't care about or have less of an eye for.

I think I've built some really cool things in my time even though many of them haven't been that technically challenging. On the other hand one of the best programmers I know has built some extremely technically challenging things that go way beyond my abilities, but his UI/UX is so bad that everything he builds is basically unusable by anyone but himself and he doesn't seem to think that's a problem.

Do you you really feel you have nothing of value to offer as an engineer? Are there any type of problems that your team tend to come to you first for answers?

I really believe that building a great product requires engineers of all different mindsets and skillsets -- I actually think this is a mistake a lot of companies make when hiring, you probably want some people who are bad "fits" for your team instead of looking for clones of your existing devs. There might even be an argument to make that sometimes great engineers are actually fairly bad engineers. I've worked with guys before who are excellent at documentation and communication but less strong technically. In my opinion they were still really valuable members of the team though, they just focused more on ensuring we had good dev docs, improving tooling and arranging dev meetings to discuss things like tech debt.

I'm yet to meet a engineer with nothing to offer. It might just be that the company you're working for isn't making the best of your skillset.

Some things to think about anyway...

On one hand you don’t have to be algorithm-smart to handle many real world challenges, since software engineering nowadays is mostly business, architecture, product, not math.

On the other - you can and should learn some fundamental CS ideas and algorithms until it’s in your fingers, otherwise you’ll find yourself often missing crucial details and making not optimal decisions in your work.

You don’t have to be a genious to learn most of it. It’s a matter of time, practice and perseverance usually. Not many people i know who get these things quickly and naturally.

People want to pay for backend api apps deployed on a cloud provider.

Some people are autodidactic, it doesn't mean you 'suck' at programming, just canned quizzes don't align with what you are good at.

You can try and get into non programming roles. Those usually pay on the lower end but depending on the visibility, can offer a faster growth path. There are roles like Business Analyst, Data Analyst, Scrum Master, Project Manager, Product Manager. You could also do non-programming certs like AWS, Salesforce etc if you want to get out of programming.

> I'm depressed because I make a decent base salary but I don't really know how to solve some of these tough algorithmic questions.

Talk to a therapist. You're tying your ability to solve fucking Leetcode to your self-worth.

Try to break into Haskelling - leetcode doesn't apply + it's a lot more fun that normal programming. I don't normal program anything large anymore. Waste of consciousness-seconds :)

I'm a full stack dev and I avoid applying to large corporate companies because I hate doing puzzles like leetcode just to please the HR.

Even I can solve it at home, I can't do that during interview.

One of these again?