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

Take an algorithms course, or read an algorithms textbook.

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

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.

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.

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.

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?

"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?

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.

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 :)

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.