[AdityaSanthosh]

Hi, I am one of those code monkey you mentioned. I never took affinity to computer science/math, but I love building real world products with software. I built some really hard and interesting products. Basically, I love playing with tools and building tools from programming paradigms I know. Right now, I am struggling with all the interviews that have these leetcode problems. What sort of career in IT do you think would be best fit for me?

[Neywiny]

Well what I'll say is this: my job never had leetcode. Embedded engineering, especially if you do FPGA work, is very different from what leetcode has. Honestly if recruiters are using it for jobs like mine, they really don't get it. But I don't know you nearly enough to know. There are so many different fields up and down the stack. Front end, backend, embedded, cloud, edge, consumer, IoT... The list goes on. I would cast a wider net, I guess.

[whateverboat]

There are three parts of building products in software just like everywhere else:

1. understanding what product needs to be built

2. Having the technical expertise to build them

3. how much effort is needed to build it

And all three things can be hard in themselves. The product can technically be just straightforward (even if somewhat tedious) but you should know what to build because you should know what the customers need.

The product can be technically so challenging that without the theoretical background, you would not even know that such a product would be possible. (An example here would be something say that requires distributed and independent time clocks).

Finally the product can be something that is technically simple, obvious in its customer demand but requires quite a bit of effort and therefore requires you to be good at procuring resources and managing them.

You need to figure out which of these three things made you successfull with the product you call really hard and interesting and pursue that line of industry (even if it is not software!). And then slowly try to become good at other two things.

[lelanthran]

> Right now, I am struggling with all the interviews that have these leetcode problems.

There's no need to struggle with them. You'll cover fully half of them simply with experience with trees. Build them. Traverse them top-down. Then bottom-up. Search it, Balance it, then rebalance on modification. Invert it, prune it, Roundtrip it to JSON, etc.

After mastering that, given a problem of "develop a flood-fill algorithm to this specification" should be a walk in the park.

[kubanczyk]

Off the top of my head, possible problems here might be:

1. To handle trees easily you have to understand recursion. Somebody with no CS experience (and no parser experience) might never ever used recursion in anger, even if they launched zillion commercial projects.

2. No Big-O notation. Interviewers usually ask questions about time/space complexity.

And the elephant in the room is that leetcodes are getting trickier and trickier, that's LLM era for you.