nieksand's comments

"Tunable spending limit" has consequences that can create other, equally real, problems.

Best effort: Turn off all compute resources, drop dynamically-adjustable persistent resources to their minimums (e.g. dynamo write and read capacity of 1 on every table), leave EBS volumes and S3 alone. In some cases, a user might find their business effectively offline while still racking up a massive AWS bill.

Hard cutoff: Very close to deleting an AWS account. In addition to compute and dynamically-adjustable resources to minimums, this means deleting S3 buckets, Dynamo tables, EBS volumes and snapshots, and everything else that racks up cost by the hour.

The best effort approach sounds reasonable to me. The hard cutoff solution sounds worse than the problem it purports to solve.

Agreed that AWS is poorly incentivized to fix the problem.

Turning off all compute resources (EC2, Lambda, Fargate, etc) seems obvious, but what about systems managing state like S3, EBS, and DynamoDB? Should buckets, volumes, and tables be deleted?

"In 2003–05, Germany undertook extensive labor market reforms which were followed by a large and persistent decline in unemployment. Key elements of the reforms were a drastic cut in benefits for the long-term unemployed and tighter job search and acceptance obligations."

It's easy to say that strategic thinking and planning should be continuous, but in reality there's always a storm of immediate tactical tasks sucking up your attention. That's true for both software engineers (living in Jira tickets, sprints, and one-to-two quarter projects) and the c-suite.

These sessions can force you to make time, put aside the tactical noise, and think.

Title: "Notification - Please visit support team"

Sender: "Sales and Success"

The short body declares that I have to go to their support portal.

I can't tell whether this stems from incompetence or if their aiming for Spam on purpose. Given their behavior, I assume the latter.

An asset tracking the S&P 500 is still a very reasonable bet. For my taxable accounts I use IVV with an expense ratio of 0.03%

https://www.ishares.com/us/products/239726/ishares-core-sp-5...

Another good, diversified choice is Berkshire Hathaway class B shares (BRK.B). Lots of boring but money-making businesses in there. The downside is that both Buffet and Munger will be out of the picture within a few years, so there is a chance of a rocky leadership transition.

https://en.wikipedia.org/wiki/Berkshire_Hathaway#Businesses_...

Even if you only use high level languages, the LPI provides insight on what's happening under the hood. It also gives important context for when you do performance analysis and program optimization. Each chapter has a bunch of exercises at the end.

Also, at what point will the candidate be able to vet whether Canonical is a suitable match? Is that only after this questionnaire, psych test, and take-home assignment?

If you don't feel comfortable talking, consider partnering with somebody who does.

https://www-sueddeutsche-de.translate.goog/wirtschaft/erdgas...

As a follow up you could scope out how familiar the candidate is with alternate encoding options and what the trade-offs and use cases are. (BSON/MessagePack, Protobuf/Avro/Thift, FlatBuffers/Cap'nProto).

I would look for the following in a "fine" question:

1. It demonstrates knowledge of fundamental concepts or techniques.

2. It lets you distinguish the quality of answer/implementation rather than just works or doesn't.

3. It leads to natural follow-up questions that can demonstrate the candidate's knowledge or expertise.

4. It does not require fiddly code. (e.g. linked list pointer twiddling questions: they aren't hard but are easy to muck up with a stranger staring at you.)

5. If its unrelated to what candidates normally work on, the question should not hinge on knowing a specialized "trick" to change difficulty from hard to easy.

Atoi under that criteria:

1. Does not show much interesting besides a basic understanding of decimal numbers and writing loops.

2. It's hard to imagine much variability in the quality of responses. A "real" atoi implementation is not interview material: https://github.com/golang/go/blob/master/src/strconv/atoi.go...

3. I guess you could follow it up with questions on testing and error handling. Nothing super interesting comes to mind, but that could be lack of imagination on my part.

4. It meets this criteria.

5. It meets this criteria.

Perhaps you have some particularly good way of posing an atoi() question.

For me the interesting part was the build process. If you care more about microscopy than tinkering, you are probably better off just buying a pre-made scope.

Perhaps it was the exception that proves the rule.

It sounds like snake oil territory to me.