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?
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.
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.
> 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.
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.
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.
> 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.
I have a 2-stage agent that analyzes all of the DOM content (including pop up ads). If anything remotely resembles a scam, it passes the DOM content to a second “judge” LLM that’s more powerful and has a ton of criteria for top scam techniques.
The goal of the 2 stage agent is to prevent resource consumption when something isn’t a scam/harmful, and reduce false positives by doing a second pass if something flags.
I’m currently not detecting content from scripts though, just raw HTML at the moment. Good thinking on your side for doing that, I’m gonna throw it in my backlog.
Hi, seems like an interesting course. I haven't studied compilers in my undergrad( I'm an electronics student) but I have been working as a programmer who studied c and bit of low level languages. Is there any prerequisite compiler knowledge required for this course?
On an unrelated Note, I admit I hated the idea of setting up processes because I enjoyed the freedom given to me by my manager to make architectural and code decisions on my own and move fast rather than following rigid practices. I am not sure if that mindset is good.
I agree. I still push things to production occasionally. But testing bigger changes with all edge cases can take a lot of time for me on some projects. Having QA I am left with more time to work on features. A decent QA will find bugs you wouldn’t have and make the product better.
I created a staging setup, the CI/CD pipeline already, I pitched to my Engineering manager to get me a QA. I will push harder from now to smoothen the deployments.
> I take a very large example of real-world data (say 95th percentile of what is actually used in the wild) and develop with that as my backing data. If operations are slow enough for me to be annoyed in development, clearly they will be too slow for the (many more) people who have to work with the project once complete.
Interesting point. Will try to incorporate that.
> Does making a change in one flow tend to adversely affect seemingly unrelated others?
It doesn't happen that much, but because there is a lot of intersection between those flows, they are kind of interlinked(to reduce code duplication). But point noted, I will try to see if they can be separated.
> Lock the `main` branch, only allow commits to it from PR's. Review your own PR's.
Done.
> There are no bad queries, only insufficient validation and/or timeouts.
Validations are huge issue. When you have hundreds of variables and one of them throws DivisionByZero error or invalid data type, those are hard to catch
Loved these suggestions especially the first one. any more ideas?
Not so fast, if you have shared code that is breaking that'd be a perfect place to start introducing automated testing. In general automated UI testing is more work and false-flags than it's worth, but the exception is heavily reused code. That said, if you have code that is technically reused, but there are so many parameters that no use site is the same and changing the way one parameter gets interpreted causes issues with another, yes that'd be a good thing to fix up.
> When you have hundreds of variables and one of them throws DivisionByZero error or invalid data type, those are hard to catch
I will propose automated tests to my manager. Writing tests for shared code is a great idea. But I feel I should concentrate on integration tests as well (like flows spanning multiple lambdas)
In my observation, DE interviews even if they are leet code based have relatively easy compared to that of SDE roles. And it is not like I hate DE, i like it too.
1. No ads
2. Punishing bad behaviour over perma-banning profiles.
3. Unbiased moderation
4. No adult content
5. No alt or bot accounts
6. Some puzzles/activities. Engaging content without sensational news
7. Should have healthy mixture of text content(more) and short videos
reply