I guess to be more specific about that situation. There are a few layers of memory:

-- The total memory allocated to the database

-- The total memory allocated to each block. Even if the total memory is large enough to allocate the database, the indexes can be limited by the memory allocated to each block. This is a fancy way of saying how many rows can fix in a section of an index. The entire index does not always fit into a single block of memory.

-- The total allocated blocks for the entire database / each query that can run at the same time.

The challenge is balancing quantity of block sizes -vs- the sizes of the indices. For example, if you allocate 1g to each block and you need 10 blocks to run an indexed query, you have to be sure that you have enough space allocated to the blocks, and you have to be sure that you have enough blocks available to use all of the section of the index in the query you are running. Either of these numbers can cause the database to do a disk sort of they are too small.

Counter-intuitively, bigger numbers aren't always better, but I'm sure AWS has the allocations sorted out just fine.

derail but

so there's lots of situations in communication between front end and back end where I have a back end function that needs to only happen if x y z are false. Do you prefer a style of:

or

"bar && baz" seems way clearer to me than "!bar || !baz". Curious if other people feel differently.

+1

100%

I think it's almost always better to say:

rather than:
Although sometimes the x is more easily readable in the latter, it seems that's not the case with this example anyway?

usually you want your early return to come first because you save an indent on the rest of the code (where most of the logic lives)

so yeah (!bool || !bool) is worse than (bool && bool) but in this special case since you early return i'd go with the former

+1

Early exit FTW (with some exceptions). E.g:

is more readable for large do-stuff blocks than:

I agree and also if there's more than 2 or the conditions are kinda long I like

if !foo1 { return }
if !foo2 { return }
... rest of code

Same goes in while or for blocks, using continue

IMO it's especially important in python, to avoid having to figure out which "if" an else goes with by counting spaces.

I have a big interview tomorrow. Meeting with 6-7 people for 30 mins each. Some very senior technical folks. They have someone from a similar program to mine (same place but different region) and all calls/meetings have gone great, they have made clear they like me a lot.

Any random advice is appreciated. I'm spending the day today over preparing for technical questions I probably won't be asked, but want to feel ready. I'm just super excited to get on a scrum team writing code and the tech stack they use is exactly what I'm looking for. They also seem to have a great mix of different types of people, so it's gonna come through how excited I am and it should seem like a great fit.

Yup.

Sent from my SM-G920P using Tapatalk

Good luck!

You can pick up e-books on interview questions for xyz on Amazon.

If you have time find someone to interview you, asking you typical interview questions so you get used to talking about yourself and your background. If it's in the next couple of hours just relax, you're going to do great!

Yea doing that with a friend tonight

Congratulations, Larry Legend.

The only thought I can say is that no interview I've had has went as I expected it to go. The advice and articles on HN are 100% wrong, never been my experience, etc.

Expect the unexpected, have fun, and sell who you are.

+2. That takes priority for me over expressing the boolean logic more clearly.

I find your guys take interesting (just in a general sense - clarity is very much in the eye of the beholder).

The early return doesn't take precedence over the much clearer if condition to me in this case. I'm tempted by what Rusty wrote, but I think even then I don't like the negations and double if conditions just for an early return.

I've been trying to remember the rule about double negatives with and/or and can't so I prefer the positive logic. Seems like something the compiler would fix anyway.

The issue isn't performance, it's readability, which the compiler can not fix.

The rule for negation is called Demorgan's Law and you just negate them and toggle or/and.
!(a and b) = !a or !b
!(a or b) = !a and !b

And I think reasonable people can disagree which readability problem to prefer - you're trading off one for another.

However, it gets cleared the deeper you get imo. I rewrote some functions a year ago where someone had if statements 6 or 7 levels deep. They are now 1 level deep. It is very clear what gets to the end of the function and what does not.

Another principle I like but don't enforce is "all early returns should return an error condition, the only Good return should be at the end of the function"

Like in python you'll often be returning "None" for all your short circuit returns. Your real return will be, say, a dict of stuff. Return that at the very end and only there so people can know "this will return None or it will return a dict like this" and they won't have to reason about what state the return value might be in.

If you are using a recursive function doesn't this not work?

I suppose it might depend on what you're trying to do, but not necessarily?

Short circuit condition first, return condition last. This is a pretty simple example, but... I'm not seeing the problem. What's an example of a case where we couldn't make the return last?

If you want to keep placing on the stack until you execute. Perhaps this will show how bad I am at coding, but I was working on deleting a singular linked list designed in C, and I started to go down that path at one point, and purchased 21st Century C by Ben Klemens (really digging it, btw). But that's a use case.

Got segfaults though, so... ya know. Don't know if this caused it.

add: Towers of Hanoi? wiki: https://en.wikipedia.org/wiki/Tower_of_Hanoi

On reflection I could do it this way

But the first way seems neater given a list that is medium to small in size.

Over a million views in this thread, wowzers.

btw decided to go with an array to a linked list to avoid malloc problems all-together. It wasn't necessary to use a linked list.