I’d recommend trying the graded exercises in https://www.coursera.org/specializations/data-structures-alg... or https://www.edx.org/course/data-structures-an-active-learnin... — unfortunately, for the most benefit (online automatic grading), you’ll have to pay either EdX or Coursera, but EdX offers a small sample of exercises to start, if I recall correctly. And there are a few more courses after those.

If you’re anything like me, you’ll learn better if someone doesn’t ask you to do the impossible, but instead leads you through enough solutions that you can get an immediate confidence boost from the first few easy ones, then the intermediate ones require more thought, and if you really get stuck, there are discussions about how to solve some of the problems. Usually you have to think algorithmically, not just write code, and some problems might just be harder for you to understand because you haven’t done as much work in that area. I won’t say it’s a complete look at algorithms—there’s a whole other course on strings if I recall, but it’s a good start.

Also, here’s my cheat to pass those employer questions — if they let you use JS, do EVERYTHING you can with ES6 Map and Set classes. Folks rarely look at the code and don’t care if you’re using for loops or advanced classes, but it’s way easier to use a Set than to worry about how many times you have to loop over some result to reduce duplication, or sort things, or what have you. If you need a unique sorted set, there are faster algorithms, but a simple (new Set(arr.sort())) gets the job done, because Set is insertion-ordered by default and any native JS function is generally faster than you writing your own code, so it’s impossible to mark this solution as wrong unless you exclude native functions (but who does that?). A bonus tip, if you need to figure out the difference between sets, just get creative with .filter and .map. There’s not much to memorize beyond that because there’s not much advanced functionality, just building blocks flexible enough to do anything, relatively expressively. https://exploringjs.com/impatient-js/ch_sets.html#missing-se...

A follow up, if ES6 JS doesn’t come easy to you — pick a language you like best and look for its equivalents to Set, Map, .filter (or select) and .map (or collect). Bonus tip, look for .find or .first, to short circuit looping and stop at the first thing that matches. Yes, you can memorize for loops or why one thing is more efficient than another, but if you start with Set and Map where each makes sense, you’ll solve 80-90% of algorithm questions pretty easily and usually in a way that’s straightforward to read and understand later, especially if you start naming some of your functions to make them a bit easier to read. (Like naming selectors in Redux...)

If writing SQL as part of a quiz, learn the different joins because usually the question is worded in a way where picking the correct join will deliver huge performance benefits by reducing how much data you’re going through or making things more efficient than looping through multiple subqueries. Left vs Inner vs Right vs Outer vs Cross... remember that the less data the server has to go through (the fewer records in the earliest sub query), the faster everything will run, in these quiz scenarios. Yes, in real life how you store data matters, what you index, but it’s rare you’ve any control over the index or schema in these tests.

Agreed, but as OP was alluding to lots of people need solid business logic written that doesn’t have to hyperscale. Just lame that all the shovel-sharing apps interview as if they want to process petabytes of requests :)

I'm taking the princeton algorithms 1 course now, and it is proving helpful. It has automatic online grading and is free.

The only gripe I have is that at the end of the day, the litmus test for whether or not I'll pass an interview really is leetcode.com

While the coursera course is great, and provides fundamentals I'm clearly lacking ... It's tangential to the actual solving of these riddles.

i'm going to be honest with you - if you wrote an app that has never crashed or had a single downtime yet is infinitely/auto scalable based on load, it is either extremely simple, you are a legitimate genius, or you exaggerated. there is just so much that can go wrong there that i'm skeptical, ergo i'm skeptical of other things you wrote.

however, if what you said is generally true, then it's obvious you have some skills gluing stuff together. news flash: this is what a large fraction of people in this industry do on the day to day, it's just that nobody wants to admit it. 90% of my previous software engineering jobs was just figuring out how to get things to talk to each other.

key for you i think will be spinning your skills in a way that makes you attractive.

you'd seem like a good fit as a consultant. clients generally don't care about how you'd write a string matching algorithm from scratch and what the theoretical runtime is in theta notation - they typically appreciate contributions, on deadlines, and clear communication. they pay you to figure out how to make stuff work on a schedule you mutually agree to, and you either give them that and get paid, or don't and don't. put up or shut up, so to speak.

so i'd start there. you have a large pool of knowledge, so just pick whatever interests you the most. then what you think you should get paid per hour, and triple it.

expect 80% to not follow up on leads and 80% to reject your schedule/hourly rate/etc. sort of like interviewing, but at least you're not stooping down to a level of desperation. keep your head up: your skills are worth a large amount of $, so don't take it personally, and don't reduce it just to get scrub-tier work/wages - unless you're legitimately broke, but hopefully after so much working you've got some sort of cushion.

I've thought about consulting before, and my wife actually thinks it's the "right" thing for me (given my recent anger/frustration over the "online assessments" aka algorithm study).

The problem is I'm just not onboard with all the struggles that come with having to find clients, maintain clients, etc. I appreciate (and value) the security and consistency that comes from more-or-less knowing you will have a paycheck next week.

My skillset also lends well (I think?) to a technical manager, or even CTO position at a SMALL company. I certainly know of some great tools, how to glue them all together, and how to do so really quickly. Yet how one makes the jump from "Senior Software Engineer" to fucking CTO is beyond me. I'm not even sure where one would search for CTO jobs. And I'm 32 so, not exactly young but, not quite what you think of when you think of upper management...

The point is - I get your point. Maybe I shouldn't be killing myself with these algorithms. Maybe I should lean into things I'm better at and market myself, gain clients, etc.

> These fucking algorithms are killing me, and making me have a hard realization that maybe I'm just not cut out for this. Yea, I've built shit... but you know what... anyone could.

I wouldn't get too discouraged about this: they couldn't - not necessarily anything of value anyway.

I've worked enough places now where the product the business is built on was written by somebody who wasn't necessarily a great programmer, yet this "bad"[1] code is the foundation of the company's success and may be the sole reason they're able to pay me.

You can build a really successful business on really "shitty" tech.

[1] Inefficient, non-scalable, hard to follow, poorly architected, spaghetti code - call it what you will.

I have news for you:

You can study for technical interviews and get good at doing them. "Cracking the coding interview" is a good start, then there is interviewing.io and other resources.

You can learn to be good at that shit with a bit of practice. You're probably not dumb.

Well, I'm currently taking the Algorithms 1 (Princeton) course on Coursera, while tackling as many problems on leetcode.com as I can. I purchased a Premium subscription on leetcode.com.

I'm just finding that my progress is SLOW. Like, I look around and it seems like everyone can find all these creative solutions to problems... meanwhile, I'm lucky if I can solve the brute force solution.

I’m currently prepping for these kind of questions and “online assessments” as well. I have accepted that my worth as a developer is in most part going to be dictated by how diligently I can game this glorified IQ test.

There are common patterns to these questions and I’ve found that they get more predictable after having done 50-100 of them, with very careful attentiveness to what your mind is coming up with to solve them. All these questions can only vary so much in how they are asked, and unfortunately we just have to do use repetition by numbers to enforce better pattern recognition.

So I recently switched up my approach on leetcode.com to optimize for this naturally.

What I was doing initially was:

I sorted their entire problems database for the most frequently asked questions. Started at the top, and worked my way down.

The problem with this method is that each question can be quite different from the last. Your first question might be an arrays / sliding-window question. The next is a dynamic programming problem. The next stacks. After that, union-find / connected components.

The point is each problem would end up sufficiently different from the previous one that in a given day, or over the course of a few days, you weren't practicing the same (or roughly the same) type of problem.

So as of literally TODAY I've changed my approach to sort the list by TYPE of problem. I will then focus on a specific type (per their categorization) for ~X number of problems (to be determined).

The hope is that by sticking to a specific category of problems, I'll be able to actually learn the commonalities within those problem sets.

I switched to Math from CS at my university specifically because of this. Although the CS field does emphasize a lot of theory, having a more general theoretical background greatly helps with picking up new engineering fields as a hobby.

IMHO the main reason people feel stupid about algorithms and the like is the progress isn't as clear and as linear. I wasn't good starting out. Coursera is great, and probably the most flexible and least frustrating way to expand your skill set.

Outsource things you aren't good at. You think Tim Cook knows how to write the code required for iPhone hardware to communicate? No.

Well, I'll be sure to tell that to the next guy who sends me an 'online assessment'.

Maybe it's time to build something for yourself then. You have the necessary skills, basically a full stack dev + devOps. That's the route I'm taking - also have never studied algorithms or data structures and am mostly self taught.

voilà