- > 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.
- 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.
- > Comments should not be answered in line, but by pushing updates to the code.
Hear, hear.
me: This unreadable, needs a comment.
them: <explains the thing>
me: True, but I've meant a source code comment.
them: <explains the thing again, but with more words; push never happens>
- Did you try that? These "remote" jobs that OP is describing filter you out instantly because of geography, so there's nobody to speak to about B2B contract.
These that did not filter me that way, offered both: either regular employment or B2B. These are truly rare, say 2%-5%?
My guess is that in countries like US, B2B contracts for individual SWEs are considered something very special and snowflake'y. Like they fully expect you to disappear three hours in, never to be seen again.
- > Wall wanted a language that allowed for cleverness, suprise, and ingenuity. [...] Having to learn to be a poet to be a good coder was too high a barrier.
To me this just sounds, umm, pathologically eclectic.
- > I don't feel like I'm working when playing leetcode.
This. So, basically it's not "grinding" as OP describes it. Not starting each day with assumption that you'll do K mediums or L hards. More like making a honest attempt when you feel like it, and seeing whether it sticks.
- > to charm, manipulate, and game
There is surely nothing wrong with being charming.
The "manipulate, and game", just per dictionary, would mean in this context something close to "control or influence unscrupulously". What social norms exactly do you see broken/bent by the OP? Because I see none.
Are you trying to influence this comment section unscrupulously?
- > Physical attractiveness is a signal of reproductive fitness when it’s genetic, and not otherwise.
Nay, artificial physical attractiveness is also a signal of reproductive fitness. It isn't a given. It's the subject's genes that made a brain that was able to design (and to arrange to pay for!) the improved attractiveness.
It's not qualitatively different from brushing hair.
- Aren't there any checks for that?
In EU most DMV equivalents check headlights yearly to catch illegal illumination envelopes (along with other safety-related aspects, brakes and whatnot).
- I'd go as far as to say that the height is the issue, and it's becoming global (although, yes, US is the leader).
It's ridiculous that an average SUV has headlights higher than an average semi (my own experience) given the latter's breaking distance is much greater.
- I've caught unbalanced parens:
forkIO (atomically (transfer req.from req.to req.amount) - I took several assumptions to build an argument why some errors should result in process-level termination.
By "corruption" I mean much more than merely a hardware bit error. I mean any situation when data no longer has a meaning for a user.
By "unexpected" I mean that the program has not been prepared to deal with the situation: there is no code there to "fetch the data from the source again", etc.
> you know and control what the graceful stop does
No, in fact I'm exploring here situations when I don't know this with certainty.
- Ah, true. If the var is a part of a long-living state, all good. That's just rarely seen in CRUD apps, more common in games.
- > Using it in a business context, there's more emphasis on ideas
No. It's a cheap trick to make me trust the interlocutor. Since it's not only cheap but effective, it's entirely my choice whether I submit to it and "open up".
In business the other side is anything but your therapist.
- Taking your point of view: you assigned a value1 to a name. Then you assigned a value2 to the same name.
You say that value2 is correct. It logically follows that value1 was incorrect. Why did you assign it then?
The names are free, you can just use a correct name every single time.
- That's subtly different. It's secondary whose fault is this, what primarily matters is whether you should continue with the rest of the process.
There is always a cleanup layer, the trick is to choose well between 1 and 2:
Take for example an unexpected divide by zero, that's a classic invariant violation. The entire process should blow up right there because:1. Some code in the same OS process is able to bring data back to order. 2. OS can kill the process and thus kill any corruption that was in its address space. 3. Hardware on/off button can kill the entire RAM content and thus kill any corruption that spilled over it.- it knows that the data in memory is currently corrupted,
- it has no code to gently handle the corruption,
- and it knows the worst scenario that can happen: some "graceful stop", etc., routine might decide to save the corrupted data to disk/database/third-party. Unrecoverable panic (uncatchable exception) is a very good generic idea, because persistently-corrupted-data bug is a hundred times worse than any died-with-ugly-message bug as far as users are concerned.
- But I'm not offering anything to you. Unless there's a budget, in which case I will make that svn fly in circles over your enterprise, dear sir.
- > So, what am I missing?
Here: git rebase is slightly broken in conflict handling. It can be made simpler to understand with jj.
- Nah. The error is the royal "we". We tolerate <subjective judgement>, We enforce <subjective judgement>. And above all, We require everyone to be nice and cultured.
The actual power-wielder who regulates these things is a government (or rather its justice system), a warlord, nowadays maybe an AGI, but definitely not society and not "We, users of orange social media". These mechanisms work for thousands of years, paradoxes gonna paradox.
Instead of brute-force method of selecting the appropriate test suites by path or similar, have LLM analyze changes and propose the set of test suites that is relevant to the change.
If there are new complex tests added to the change, estimates how many times to run them to ensure they are not flaky to begin with (hundreds? or thousands?).