evercast

> Usually this isn’t necessary and its better to just return the error unwrapped.

This is a terrible advice. Wrapping is extremely helpful in providing additional context for the error travelling up the call stack. Without wrapping, one typically ends up with software logging generic errors like "file not found" , which you can't act on because... you don't know where it's coming from. If you skip error wrapping, better be ready to enjoy quality time when production crashes.

I believe the idea is that 'panic' is considered something fatal. If it happens, the application should die unless you have a strong reason for it not to. If you can recover e.g. by returning HTTP 500 for a single request, it should be handled by returning errors up throughout the call stack, i.e., by error handling instead of panicking.

It's definitely an opinionated approach though.

> There's a reason why most FAANGs developed their own packages management and deployment system and keep using them. They are simpler, less bloated, easier to debug.

Most FAANGs developed their computing infrastructure before Kubernetes gained popularity. After all the investment into building it and fine tuning for their software services (like ads), they probably have a lot more reasons to not migrate to something different. Not just because their systems are "simpler, less bloated, easier to debug".

It doesn't work like this. If there is a hiring freeze in place, it means that internal headcounts are also limited. The "desperate team elsewhere" must have money to pay for the new engineer.

It is not harder, it is different. They just ask more system topics, while focusing less on coding. There is, however, a catch. If you get hired as a SRE-SWE, you can easily switch to a regular SWE. If you get hired as a SRE-SE, you may have to reinterview to change your job ladder. SE is okay, but you clearly have more possibilities as a SWE.

Counterpoint: I have a HomePod mini in one of my rooms and it reacts easily to any mention of Siri in other rooms. So I am actually impressed with how good it is in reacting.

iCloud and Google storage plans are overpriced? I have always thought they are cheap storage plans. 50GB of iCloud costs $0.99 per month. 2TB costs $10 which is similar to other solutions such as Dropbox or OneDrive.

+1 on this. Homebrew is so smooth to use that I never felt like I am missing something compared to Linux package managers.

I'm certainly far from finding excuses for Google, but I have strong doubts when reading stories like this. I wonder how is this possible? If you check their support packages at https://cloud.google.com/support/, they provide different options based on how much you are willing to pay. The premium package gives you 15 minute response time and a personal TAM. What am I missing here? They promise a service, but it doesn't work?

AWS seems to also have support packages: https://aws.amazon.com/premiumsupport/plans/, and their response times are also not supposed to be instant.

What finance jobs? The only companies in software engineering paying more than FAANG are trading companies like Jane Street. And AFAIK they have harder interview loops than Google.

As engineers, we all know that there are different circumstances. Sometimes they are technical, sometimes political. I would say we should always assume goodwill, unless proven wrong. This is irrespective of whether we talk about Apple, Google, Microsoft, Facebook or any other company.

Calling Uber just "a taxi app" is IMHO like calling Facebook just a website. Sure, that's what the end user gets, but there is plenty of engineering involved such as maps service (I believe they have their own, but I might be wrong), geo searching for locations, batch processing for data analytics, ML experiments etc.

I believe Uber is also well known for building everything in house as opposed to using common cloud services. So they need to run their stuff.

Interestingly, this is not some random app, but something that has been featured in Wired: https://www.wired.com/2015/09/turn-handful-phones-speaker-sy...

This is their webpage: https://ampme.com/. It says ©2019 Amp Me Inc. which could mean it was not updated since then. This is also when the app started charging money. Could it be that the authors sold the app and the developer account to scammers?

Also, not sure how to treat the accusation about easy to subscribe and hard to cancel. It seems the subscription can be canceled in iOS like all other subscriptions?

The app is also in Google store.

Umm... This is a US-based job, right? As someone based in Europe, I find it absolutely shocking you have been requested to work ahead of your start date. This is not even eligible for asking if it's a red flag. It's insane.

edit: I see other commenters are like "well, standard practice, not necessarily that terrible". Am I living in a bubble or is it just Europe?

Well….. it should be clear by now that this is not just about “resetting a password”. The instructions at https://support.apple.com/en-us/HT204106 provide quite a lot of options to follow, with the support call being last resort. Bugs happen, so why not tell them and let them help you first?

@OP Since the machine is new, I wonder if you talked to Apple support on the phone? Did they tell you to visit the service in person? Also, out of curiosity, how can you have multiple personal/professional Apple IDs? AFAIK you need to provide a separate phone number for each. It is not very easy to create multiple ones.

Just casually wondering here... how do you evaluate the voice assistants to claim that Alexa is improving, Google Assistant is getting worse and Siri is terrible? I used all three and honestly I don't feel a whole lot of difference between them. They all control the lights and set the timers/alarms just alright, with similar "error rates".

I don't see this mentioned by other commenters so let me provide another perspective. Namely, I think OP is doing it wrong.

OP claims to have done 400+ LC problems over a couple of months. Let me say it out loud here: this is simply crazy. It strikes me as an attempt to not learn how to tackle these challenges, but to actually brute-force through them. To anyone preparing for an interview: don't do this! Grab a book like Elements of Programming Interviews (EPI), maybe follow some online courses on programming puzzle patterns, and then start grinding LC. Maybe interleave grinding with learning? Your end goal should be to develop deep understanding of what you are doing, not memorise the solutions.

Also, while going through LeetCode, it is very important to realise that the problem classification there is a bit wild at times. Don't stress that you cannot solve a medium sometimes as they are mislabeled. I did mediums that could be hards, hards that could be mediums, and hards that were just impossibly hard. Typically a very hard problem is not something you should expect in an interview setting as most interviers* don't expect you to implement KMP on the spot. Doesn't hurt to know it and impress the interviewer with knowledge, but if you think memorising KMP is the way, you're mistaken.

* - there is still luck involved and you can have a crazy interviewer. It can happen, so just accept it and move on. Don't treat it as a personal defeat.

Source: I grinded and I had offers from most of FAANG letters.

My bet is that K8s will not only be worth learning in 2022, but also easily beyond. It is now a common infrastructure component of projects I participated in (some always used it, some are starting to). IMHO Kubernetes is quickly becoming the standard infrastructure API. Even if you don’t use all features, it’s just simpler to deploy a cluster and have everyone work on the same subset of abstractions. I am not sure if there is anything on the horizon stopping it anytime soon?

Works perfectly fine for me. Safari 15.1 on Monterey. Same on iPad with iOS 15.

Precisely this. If the management is willing to put an unexperienced person at the steering wheel of the company's IT infrastructure, it is a clear red flag. This is not to depreciate OP's talents. Instead, it sounds like the management has no idea what they are doing. Start looking for another place.

Comments like this make me wonder if people really expect engineers to be fired because of an outage? I do not work at Google, but none of my workplaces would fire engineers because of a failure. Mistakes happen. As long as they are not repeated, everything is good.

If your company fires people in situations like this, run away and never look back.

I think "Effective Java, 3rd edition" is a good book to have a look at. It is not entirely up to date but covers Java 8 features which are a must.

In general, I'd heavily recommend studying the usage of lambdas & streams. And Optional<T>. ;)

I do not think an advice like this is applicable to any programming language out there. For example, I find it hard to apply to languages which have long history and change a lot over time, like Python or Java (or C++ as mentioned in other comments). I can easily imagine parts of the standard library being written long time ago, with many modern features not available back then.

For example, I do not think it is possible to learn modern Java by reading Java Collections code. You won't see Optional<T> being used there. Instead, your takeaway might be that it is perfectly fine to return nulls all over the place.

When looking at the GoF design patterns, I believe one should also note that they were created not only to solve a bunch of design problems, but also to deal with the limitations of the programming languages back in the day. For example, if you learn about them in the Java context, they make perfect sense as they are well aligned with the language features required to implement them. Try however putting them in Python context and they often result in unnecessary complexity.

You can actually see this in the article. The Python examples are awful (not very idiomatic). This is just Java written in Python, even with non-Pythonic camelCase naming.

OpenJDK serves as the upstream for many Java distributions (maybe all?) and it has no notion of LTS. LTS is just something to which vendors commit as outlined at https://openjdk.java.net/projects/jdk/17/ : “JDK 17 will be a long-term support (LTS) release from most vendors.”.

In other words, OpenJDK does not follow any LTS/non-LTS release cycle. Hence there is nothing special about Java 17 vs 16 when it comes to stability.

You have "like 20 different credit cards"? I live in Europe and I don't know anybody who would have more than 4-6 cards total. Granted, it's an anecdotal proof, but I really have hard time imagining any of my friends having more than 8 cards in their wallets. Is it somehow a US thing?

I have some doubt with respect to whether what author claims is "medical data" is indeed medical. Practically speaking, the data he mentions seems like the things collected by Apple Watch and stored in the Health app. There is indeed heart rate tracking, but can we really label this data as medical? IMHO "medical" would relate more to professional diagnosis, treatment etc. which according to Apple is stored in an encrypted form [1]. Garmin devices also collect heart rate, sleep stats etc. and I have never thought of these as medical (health-related yes, but not medical). The line is thin though.

Since you work in the industry, perhaps you could share your opinion how such data should be treated?

[1] https://www.apple.com/healthcare/health-records/

According to my understanding of GDPR, the data would need to contain personal information i.e. something that allows you to link it to an identifiable person. Quick search on google gives the following definition of personal data [1]:

"Personal data are any information which are related to an identified or identifiable natural person."

So if there is no personal data in the logs, it should not be a GDPR breach.

[1] https://gdpr-info.eu/issues/personal-data/

I believe the key element here is "if they promised to comply with the rules". Since Epic has already filed an appeal, they don't seem to express a lot of willingness to comply with the rules.