anchochilis

Because people who become high-achieving outliers tend to distinguish themselves in their adolescence. It's the start of a virtuous cycle where talent + hard work leads to admission into elite institutions (universities and, later, companies) which lead to positive network effects which amplify the ongoing application of talent + hard work.

It's rare for a previously unremarkable 36-year-old to suddenly turn in to Jeff Bezos (for a lot of reasons, not least that cognitive power peaks at age 25 so learning and adapting to novel situations gets harder with age).

I think a hybrid format is the right way to do take-homes. The candidate is less likely to resent the time invested in the take-home if they have a chance to discuss or "show off" their work. It also gives candidates who have less free time to complete a polished solution the chance to say "if I had more time, I would [add tests, optimize this function, ...]>"

I still struggle with the "observer effect" during live extension exercises, but it's less pronounced than when starting with a problem from scratch. If I prepare a high quality solution in advance and do well in technical discussions, that's usually enough to offset any fumbling around during the live programming session due to interview jitters.

It actually is, because the interview process influences the size, diversity, and caliber of the pool of candidates who apply to your organization, complete the interview loop and accept offers.

If you have an unlimited engineering budget or a big, attractive name then by all means, force candidates to jump through as many hoops as you'd like, you'll still be able to fill open reqs. But the majority of companies are not in that position and in fact struggle to attract and retain technical talent.

As a candidate, I vastly prefer a take-home to live whiteboarding or pairing. That background sensation of being observed and evaluated greatly interferes with my ability to concentrate and perform at my best.

(I'll note that I have no problem pairing in real-world work scenarios! I love discussing problems with my team. It's the artificial pressure injected by the interview process that really gets to me)

My mid-sized shop uses managed offerings for MySQL and Postgres but we run several stateful workloads, including ElasticSearch and MongoDB, in GKE.

I personally haven't experienced the issues the OP is describing. It might be that StatefulSets and PVCs are more stable now then when OP tried them. Of course using managed/hosted K8s makes a big difference.

> it is also not rocket science to take words literally and not look for subtext

Has it occurred to you that just as it is difficult for you to adapt to the communication styles and thought patterns of allistic people, your manager experiences the same difficulty adapting to those of autistic people?

While I believe organizations and managers should try to accommodate neurodiversity and help all types of people be successful in the workplace, it's not unreasonable to expect you to expend some effort adapting as well.

In all your follow-up comments you seem to have some excuse or clarification for why you don't need to adjust your behavior and the problem is obviously that your manager isn't trying hard enough.

When your manager asks a casual question, he is not asking for a formal document describing pros, cons. He's looking for you to make a judgment call, express an opinion, or for you to say "hmmm, I might spend some time this week looking in to that."

Reacting to a two-sentence exchange by spending a week working on a doc is a communication anti-pattern.

Yep. If my manager asks a question like that, there are three appropriate responses:

(1) Unfortunately that would be challenging for us because X.

(2) We've been talking about that for ages, because X, Y, and Z. I'd love it if we could make time for a rewrite next quarter.

(3) Hmm, interesting. Can you share the blog post? (Buys me time to think and follow up later).

What neither of us have time for is for me to walk him through my thought process via the Socratic method.

My wife almost died earlier this year giving birth to our very much wanted child. She was in great health and had a normal pregnancy, then developed HELLP and related complications (DIC, kidney injury) while in labor.

This took place at a world-class hospital in a major American city. We both believe she would have died had she been anywhere else.

No should be forced to carry a pregnancy to term, ever.

I'm obsessed with the stuff! The crushed ginger is also excellent for curries and stir -fries.

I always resisted garlic in a tube or jar because it tasted a little off to me. (And, sure, maybe because I was a bit snobby.)

But my supermarket started stocking Doro frozen minced garlic (and ginger!) and it's a game changer. Tastes the same to me, and so much easier. Haven't bought a head of garlic in months.

Your management style sounds like it would rapidly kill creativity and innovation, psych safety, and codebase quality.

I hold myself to high standards and have been described as a top performer by every manager I've ever had.

I am disciplined and work extra hours as needed to ship. I am constantly thinking about the product and the engineering challenges we face outside of working hours. But sometimes things take longer than expected, sometimes complexity estimates are off, every so often I have a bad week due to personal reasons. Having to conduct a team-wide postmortem every time a ticket rolls over into the next sprint sounds exhausting and I'd start looking for a new job stat. At a minimum it's a huge amount of communication overhead when you should trust me to get my job done, especially considering my track record.

About what year did this take place? It sounds like the employees would have had a solid basis for an age discrimination lawsuit.

The solution I know for this one involves topo sort and a trie, once you have brushed up on those concepts it's not so bad.

I'll also note that I think it's difficult for managers to transition from managing mediocre teams to high-performing ones. The job changes from "telling people what to do and making sure it gets done" to "advocating for my people and empowering them to execute independently." And some managers struggle to recognize that, feel superfluous, and double down on what they know (Jira! Scrums!) in order to feel effective.

I agree with this (and that manager sounds awful). But want to note that having a successful remote/async team has a few prerequisites:

(1) Skilled, engaged contributors. Most high touch management processes (frequent 1-1s, agile ceremonies) exist in order to motivate, guide, and create accountability for mediocre/disengaged employees. High performers can execute successfully in a process vacuum (in fact, they often do their best work with maximal freedom), but unfortunately not all teams are composed exclusively of high performers.

(2) Team members need to have shared values and a baseline level of trust and respect for each other. If they don't trust each other, disagree about technical approaches, or there are power struggles within the team, frequent meetings are often necessary to resolve disagreements that can otherwise spiral and bog everyone down.

It's not.

But elite schools select for (1) students who will enrich the experience for their classmates and (2) who are likely to have an outsized impact on the world as adults and bring prestige to the institution.

There are some people who are so quantitatively intelligent that a lack of social skills/intelligence doesn't matter (geniuses), but these people are so exceptional they can't be really measured by a test like the SAT. It's too easy to get a perfect score.

Instead they'll distinguish themselves by excelling at STEM competitions (eg. Math Olympiad, programming contests, the Putnam).

Studies have shown that later sunsets lead to worse health and economic outcomes. People who live on the western edge of a timezone earn 3% less and have higher rates of lifestyle diseases than those on the eastern edge, because they go to bed later but wake at the same socially-prescribed time, and therefore get less sleep. [1]

So why make DST instead of eliminating it entirely? It seems earlier sunset would be much more beneficial for society.

[1] https://www.washingtonpost.com/business/2019/04/19/how-livin...

Yeah, for a few years in my 20s I was bike commuting 24 miles/day and running 6-10 miles/day on top of that, with longer runs or hikes on the weekends.

I was in the best shape of my life, felt great and ate whatever I wanted without thinking about it. BUT I was spending 4 hours per day exercising.

Now I have a 6 week old baby and WFH... I manage a 30 minute Peloton a few times a week. Maybe. Even though I try to pay attention the pounds have crept on because there's so little margin for error on 1500 calories/day.

Calorie counting is no way to live, IMO. I miss the days of a long run and guilt-free cheese and beer after :)

Posts like this make me feel like an idiot, TBH.

Signed, Underpaid conscientious tryhard

I love it! Artificially constrain the labor supply with licensing. It would be incredibly lucrative for programmers. As a bonus, it would increase the prestige of our profession. Of course it would be a terrible deal for companies and quite bad for the economy.

The fact is that there are many types of applications where a high level of expertise is not needed. Eg. websites for small businesses. The client/end user doesn't care how cleanly architected or efficient or even bug-free the codebase is, and it's a better deal for management to pay some freshly-minted bootcamp grad 50k/yr to hack away than drop 6 times that on a 10xer.

I've never had a manager who "owned" anything, let alone to an "extreme" degree. It's ICs who are responsible for shipping quality work on time, sometimes at the expense of their health and personal lives. And it's ICs who take the heat when projects go off-track.

Yeah but it's also not unusual to have shared accounts for manual testing in prod, or to write automated smoke tests that run in prod after a deploy...

I'm not sure how to get around this, actually. Any production service of a certain scale is going to have some amount of fake activity caused by debugging, monitoring, testing, feature demos to clients/investors/internal stakeholders... It seems naive to tell an engineering team "no test accounts in prod ever because it makes analytics harder."

> Instead, we talk about how sexism is the biggest problem. Sure, sexism might be annoying, but in the west, it is hardly something that creates a genuine barrier for women.

This is something I've heard a lot of talented young women say at the beginning of their careers. With all due respect... give it a few years.

Sexism plays out in really subtle ways, often unconsciously. After a while though you start to notice patterns: who is hired and promoted, who is mentored and fast-tracked, which people are given high-profile projects and which aren't, who is noticed by leadership and who isn't.

You'll also become more aware of aggregate effects. I.e., "because boss at company X mentored me, I was able to get a senior position at company Y, which paved the way to my current job at fast-growing company Z."

That said, as an individual woman in the industry, devoting much energy to thinking about sexism is a losing game. In fact I think it's better to pretend it doesn't exist and focus on what you can control: the quality of your work, your skills, relationships with coworkers, and so on.

Nope! We went from not having a container orchestration system to having one.

If you're determined to be skeptical of the value-add from Kubernetes, my random post on HN ain't gonna convince you :) The developer experience improvement is obvious to people actually interacting with K8s.

I do want to clarify that this isn't the only thing we accomplished in the past year. Just the thing we shipped that was our biggest priority and had (by far) the biggest impact.

Helm isn't great (god, Go templates, shudder), but I love being able to bundle all the manifests for an application together with well-documented parameters/values... If you want do something like conditionally switch from a LoadBalancer service to Ingress in a test environment... I have no idea how you'd handle that in Kustomize, but it's straightforward in Helm. Ultimately it seems like you end up with the same complexity, just expressed via 100 layers of Kustomize transforms instead of with a conditional in your template.

Oh man, I can't believe we didn't think of migrating our mature 20-service stack with complex hardware, security, and compliance requirements to App Engine. Dang it. I should've known to consult HN first!

It's not the only thing we've been doing, just the most important.

I think it's great you guys have 2.5 dedicated people operating 6 services across 12 prod instances, with that kind of ratio our team would be 15 people!

There already are a number of platforms that make deploying and operating apps very simple! Heroku, AppEngine, Lambda, so many others.

Your 5-person startup does not need a DevOps engineer. Your 50-person org should start thinking about it. Your 500-person company probably needs multiple DevOps engineers -- having every dev team independently figure out how to handle things like deployments, reliability, and security is chaotic and wasteful. There are a lot of details that only start to matter at scale, and both Kubernetes and dedicated infrastructure teams are for this use case.

I don't know what to tell you except that with years of experience implementing this infrastructure outside Kubernetes, letting Kubernetes handle it is cheaper. That doesn't mean Kubernetes is a good fit for every organization or workload.

You can roll your own anything with enough time and manpower. Whether it makes sense to do so depends on your circumstances.

Updated original comment to clarify :)

Although, to be fair, the article is about GKE.