It seems like this policy would lead to shortages in less common sizes of clothing.
1,113 karma · joined July 12, 2012
"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.
It is really great stuff if you enjoy building things.
Cape Analytics uses machine learning on aerial imagery to characterize property risk and value for the insurance industry. We have offices in Munich and Mountain View.
We are hiring backend engineers to work with geospatial data at scale. Candidates should be comfortable with parallel and distributed programming techniques.
Full job description: https://jobs.lever.co/capeanalytics/249c055c-1dc6-46c3-8a2d-...
Feel free to send questions to niek@capeanalytics.com
Cape Analytics uses machine learning on aerial imagery to characterize property risk and value for the insurance industry. We have offices in Munich and Mountain View.
We are hiring backend engineers to work with geospatial data at scale. Candidates should be comfortable with parallel and distributed programming techniques.
Full job description: https://jobs.lever.co/capeanalytics/249c055c-1dc6-46c3-8a2d-...
Feel free to send questions to niek@capeanalytics.com
The quality of the documentation is phenomenal. Very competent people clearly put serious effort into making it great.
Another stand out is the Programmable I/O feature. Basically, you have eight separate, programmable state machines that can manipulate I/O pins and do DMA. This lets you offload bit banging from the main cores. Details are in Chapter 3 of the C API docs: https://datasheets.raspberrypi.org/pico/raspberry-pi-pico-c-...
I'm a total amateur when it comes to embedded development, so I have no idea how the RP2040 sits in the competitive landscape.
Much of the content is obvious in isolation, but put together it helps orient your outlook.
Here is my distillation of arguments for keeping the USPS:
* USPS is required to service areas which may not be covered by other carriers. A handful of commenters note, from first hand experience, that rural inhabitants may have to pick up mail from centralized depots away from their homes.
* USPS transactional mail serves those without internet access. The internet is effectively controlled by a handful of private entities. If internet access was universal and treated like a public utility, it is unclear if this second argument still holds.
Interestingly, nobody brought up mail-in voting and its importance to democracy. Nor is the environmental impact of the USPS apparently worthy of consideration.
My biggest takeaway is that the USPS is a sacred cow. Like the topics of gender and race, it's unwise to ask questions.