[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.

[Delk]

I haven't looked at leetcode in a long time but if the problems require e.g. rebalancing a tree, I honestly don't remember how to do it and might not be able to reason it out on the spot either. I have no problems with concepts like recursion or computational complexity though.

It sounds like leetcode problems require either memorization of a significant number of algorithm design patterns or seriously sharp algorithmic problem solving skills.

[lelanthran]

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

> 1. To handle trees easily you have to understand recursion.

Well that's the point of the exercises I suggest - to learn recursion :-/

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

Well, that's the other half of the interview, I only promised that my method will cover half the questions :-)

[kubanczyk]

> Well that's the point of the exercises I suggest - to learn recursion :-/

Then we must have been talking past each other. We are considering this problem here:

>> I never took affinity to computer science/math, but I love building real world products with software. [...] I am struggling with all the interviews that have these leetcode problems.

Then your advice to these interview problem is to learn some CS - the useful parts of it? E.g. recursion is CS.

[lelanthran]

>>>but I love building real world products with software.

> Then your advice to these interview problem is to learn some CS - the useful parts of it?

Theory was not my advice.

My advice was to do practical things with trees; I felt it would fit his love of building real things.

I mean, I didn't recommend doing problems out of a textbook, did I?