CBLT

1. Live coding, in Zoom or in person. Don't play gotcha on the language choice (unless there's a massive gulf in skill transference, like a webdev interviewing for an embedded C position). Pretend the 13 languages on the candidate's resume don't exist. Tell them it can be any of these x languages, which are every language you the interviewer feel comfortable to write leetcode in.

2. Write some easy problem in that language. I always go with some inefficient layout for the input data, then ask for something that's only one or two for loops away from being a stupid simple brute force solution. Good hygienic layout of the input data would have made this a single hashtable lookup.

3. Run the 45 minute interview with a lot of patience and positive feedback. One of the best hires in our department had first-time interview nerves and couldn't do anything for the first 10 minutes. I just complimented their thinking-out-loud, laughed at their jokes, and kept them from overthinking it.

4. 80% of interviewees will fail to write a meaningful loop. For the other 20%, spend the rest of the time talking about possible tradeoffs, anecdotes they share about similar design decisions, etc. The candidate will think you're writing in your laptop their scoring criteria, but you already passed them and generated a pop-sci personality test result for them of questionable accuracy. You're fishing for specific things to support your assessment, like they're good at both making and reviewing snap decisions and in doing so successfully saved a good portion of interview time, which contributed to their success. If it uses a weasel word, it's worth writing down.

5. Spend an hour (yes, longer than the interview) (and yes, block this time off in your calender) writing your interview assessment. Start with a 90s-television-tier assessment. For example, the candidate is nimble, constantly creating compelling technical alternatives, but is not focused on one, and they often communicate in jargon. DO NOT WRITE THIS DOWN. This is the lesson you want the geriatric senior management to take away from reading your assessment. Compose relatively long (I do 4 paragraphs minimum) prose that describes a slightly less stereotyped version of the above with plenty of examples, which you spent most of the interview time specifically fishing for. If the narrative is contradicted by the evidence, it's okay to re-write the narrative so the evidence fits.

6. When you're done, skim the job description you're hiring for. If there's a mismatch between that and the narrative you wrote, change your decision to no hire and explain why.

Doing this has gotten me eye rolls from coworkers but compliments at director+ level. I have had the CTO quote me once in a meeting. Putting that in my performance review packet made the whole thing worth it.

I know an equitable grading champion at an LAUSD school, I'll see if I can get material to share. EDIT: I just received [0][1][2][3].

[0] (5 page pdf) https://drive.google.com/file/d/1YO7SQEwisAbHHi6mfgj7XU9FcSB...

[1] (4m30s video) https://drive.google.com/file/d/10eWor4uhSxR8ZITA1w3kzqhTOX0...

[2] (audio interview) https://www.bamradionetwork.com/track/fair-grades-dropping-g...

[3] (article) https://ascd.org/el/articles/taking-the-stress-out-of-gradin...

When AMD launched the Zen architecture, everyone said they were on the up-and-up, and the market gave them a boost. The company's shares only started to climb much higher later on, when there were irrefutable revenue numbers. There was plenty of time to buy and make money. Someone with the domain knowledge like us can definitely have an edge in the market because we understand the product well enough to formulate better odds, then we can profit off the difference between our odds and the market's odds.

Edit: this was actually for cost-based load balancing, not load shedding. You obviously can't load shed based on return code.

    def square_vals(x : list):
        return [val * val for val in x]

    def square_vals(x : list):
        return (val * val for val in x)

    </proc/0/environ xargs -0

Or to grab just a few lines for my later reference:

    kubectl get po/my-pod -o yaml | less
    /* find the lines I'm interest in */
    -N
    |^sed -n 34,35p

> In its illiberal guise, protantalism can be motivated by an ugly ethno-nationalist undercurrent which views pronatalism as a means of avoiding what it perceives to be the evils of mass-immigration, which is seen in catastrophic terms as tantamount to ethnic replacement and racial/civilisational suicide

I don't really understand your point, however. What about the article's views are you objecting to?

I've noticed what I'm creating are DAGs, and that I'm constantly restarting it from the last-successfully-proccessed record. Is there a `Make`-like tool to represent this? Make doesn't have sql targets, but full-featured dag processors like Airflow are way too heavyweight to glue together shell snippets.

Secondly, "physically" is an adverb. This means it is grammatically correct for it to preceed "based" if used as a verb. If "based" could only be used as an adjective, then you're right, "physics based rendering" would be more correct.

Anybody more knowledgeable feel free to correct me!

> Maintain proper footing and balance at all times.

Is this not supposed to be used in deep water? Or am I just swimming wrong?

From reading this, the error with circles appears to be <1%.

Also, obligatory mention whenever horizontal-vertical illusion comes up: https://www.nippon.com/en/japan-topics/c12403/

However they patched this on the Windows side was quite fragile, because it kept breaking after OS updates. After I could no longer get it working with the reinstall and pray method, I switched to Linux because of this issue. I fixed it once with an EDID in the initramfs, and haven't had any issues for the last 6 years.

1. Trying to "put more effort" into artifacts (e.g. note taking) while learning something the first time is counterproductive. Write something lightweight and put your focus on paying attention.

2. Do one intensive review session while you still remember the content. Either teach someone else or write a document that could teach someone else. It's an ineffective use of time to do that more than once, for later review of the material just skim what you wrote on your first review.

3. Everyone who offers advice is just telling you their life story, dressed up as a simple directive. "Work harder" often means they wished they worked harder in some part of their life. Treat it like any other life story: learn the lessons they did, but don't let it become baggage that you irrationally follow.

Back on topic of Polya's How to Solve It, I took a no-credit uni course where the professor taught in Socratic style that expected us to (loosely) follow Polya's process. It was a great experience, and I've always been fond of Polya's steps because of it.

Server state should be exposed through metrics. Metrics have far fewer sharp edges than logs, and it's more obvious how to correctly produce, consume, and alert on them. I've seen (variations of) your 5 action items needed for the logs of every company I've worked at, but they've never applied to metrics.

Executions should be exposed through tracing. I'm kind-of cheating here: I expect the traces to have logs attached. But a well-done tracing system, where a developer can add a flag to their Postman query and their request was traced with the debug level set only for that request is a magical thing.

I half-disagree with this. My take is significantly more top-down: senior management has a deficient concept of how product development works. They believe Manpower is to be spent to achieve revenue, either by directly selling the result as a product (e.g. airplanes selling wifi to passengers) or by it being a differentiating feature for the sales department. This causes every allocation decision (like hiring) to fundamentally be biased around getting a tangible return: by creating new projects, new features, and new buggy microservices.

Further, since management only has two knobs (manpower and timeline) to play with, they like to move them to feel like they're optimizing the project. It's always the same fallacies, too: "we hired more people so we can create explosive growth", "we created ambitious timelines, now we're striving to fill them" etc.

I don't have a solution for this, except to note that it can be mitigated by managing up. Construct your own narrative, and take advantage of the fact that the non-technical people above you govern almost entirely by gut feeling.

https://www.marketplace.org/2021/02/15/public-pools-used-to-...

[0] https://www.2ndquadrant.com/en/blog/what-is-select-skip-lock...