carlosrdrz

Can someone help me understand what is the advantage of using jsonnet, cue, or something else vs a simple python script (or dialect, like starlark), when you have the need of dynamically creating some sort of config?

I've used jsonnet in the past to create k8s files, but I don't work in that space anymore. I don't remember it being better or easier than writing a python script that outputs JSON. Not even taking into account maintainability and such. Maybe I'm missing something?

I think I would enjoy something like this (or pinboard), but with comments. Sort of a smaller version of Hackernews, where I could see what my friends are bookmarking and then write comments on those links, so we could chat about the content not necessarily with random people of the internet but with your smaller community (or maybe with everyone too, but in a different section).

Maybe someone here knows if anything like this exists already? I've taken a look at some of the options out there, but didn't end up trying them because it seemed like they didn't do anything like this, and were more focused on simply storing bookmarks (and maybe sharing them with upvotes, but nothing for conversation).

Funny how they say: "Creators can now also opt their images out from training of our future image generation models." and then the link is just a form to submit a single image at a time.

They mention you can disallow GPTBot on your site, sure, but even if you do, what happens if the Bot already scraped your image? In any case, probably other people would just publish your picture in some other website that does not disallow GPTBot anyway.

> Instead, the reason people go to customer service is because of a question that’s so specific, or complicated, or gnarly in some respect, that there’s no way the app will have the answer: you need a human.

I can see the author probably hasn't done much customer service? I'd say maybe 1% of customer queries go in that direction.

I agree dealing with a bot in that situation sucks, but a big chunk of customer questions can probably be answered without human intervation by LLMs, assuming they have enough data about the organization and its products.

I've played both, and liked BOTW much more, although I also liked Horizon Zero Dawn. I also have the 2nd part of Horizon Zero Dawn (don't even remember the name) and tried to start it twice, but I guess I didn't get hooked into it and dropped it in favor of something else. I guess they're two very different games. Even though both are "open world", I feel Zero Dawn is much more "on rails" than BOTW. I felt there's much more exploration and finding out by yourself on BOTW, while in Horizon is more about "go there, do that. Then go there, and do this other thing. etc".

I don't know the author and I'm not part of Google, but I've also been an interviewer both in startups and bigtech, and I must say that I believe the process in bigtech is much better than what I see elsewhere. Every time I see posts about interviewing practices in bigtech I feel folks are completely missing the point on why things are made like this. No wonder they just default to bash the interview process.

Maybe it is understandable since the article does not clarify any of this, but folks should notice that:

- This type of interview is part of a process, composed of multiple interviews. Not the only one, and not the deciding factor. Questions on behaviors, team dynamics, etc, are also part of the process and covered in other interviews (usually done by managers). You could fail a systems interview and still pass the interview process. The specific interview mentioned in the article seems not too complex, though, so I wouldn't be surprised if it is a screening interview that rejects candidates when not passed.

- People mentioning that the interviewer is wrong on time or space complexity are also missing the point. It doesn't matter. If someone in the interview mentions O(n) instead of O(n2) and can reason that, that's already a good signal. It is not so much about being right or wrong. It is about thinking about those things when coding, keeping them in mind, been able to express that and run someone else through your thought process, etc. Someone plainly saying something is O(n) without any further explanation can give a bad signal, but someone explaining why she thinks so can be a good signal, even if ultimately the solution is not O(n).

- IMO, folks saying that this favors junior engineers and people fresh out of college are wrong. This favors people who ultimately understand the foundations of programming. People fresh out of college had a refresher on that not so long ago, so they've been practicing it more. The thing is, some people in our industry get further away from that as they add seniority to their career, but there's also lots of senior people that are very well versed on this kind of thing. Specifically, the question in this article is extremely simple, so TBH I don't understand why someone senior would fail to know the answer to that question just because that person is senior. Maybe these companies are just not looking for that kind of senior engineer for this specific positions. That's all. There's also a lot of different seniority levels, too. I could see this interview having less weight on a decision as seniority increases, but still important.

- "this does not represent a realistic scenario". That's a given. As a company, you have maybe 8 hours total with the candidate (multiple rounds of interviews plus the on-site). Onboarding into the company and a team, until you're productive, will take weeks/months. There's no way of testing a realistic scenario on an interview. We get the best signal we can with the time we're given.

- Not passing the interview process is very demoralizing, but it does not mean the company thinks you're a bad engineer or that you're not good enough. The process is designed to minimize false positives, so they tend to prefer to reject candidates if there's any question or mixed signal in the interviews.

- I'm not saying the process is perfect, by the way. For example, there's also luck involved, too. It shouldn't, but there is. To give one example: interviewers are people too. They need to be trained in the process of interviewing, what signals to look for, etc. There are good and bad interviewers. Interviewers can have a bad day and judge some answer as unsatisfying when some other day it would be fine, etc.

Surely there is some middle ground? Why everything has to be black or white and everyone needs to give silver bullet rules?

A service that stores something can be called "catalog" and it is descriptive, short and memorable. On the other hand, a service that does too many things can be called "zeus" or "cyclops" or whatever and that's okay too. It's difficult to have memorable and short names when things do too many things, or as mentioned in the post, they might change responsibilities.

Also, when you have something descriptive composed of multiple words (like "data-streaming-analyzer") people will certainly start using acronyms (DSA) and then you're back to short names than don't mean anything.

There's a world where everything is not called "pikachu", "cyclops", "potter" and "tortilla", nor "main-store-red-website", "download-analytics-store-and-processing", "sells-stream-processor". Use both. They are both useful!

Max Howell's tweet gets pasted on every article talking about code interviews as some kind of exemplification of the problem of whiteboard/algorithmic interviews.

What some people might not know is that he reflected on that tweet two years later (3 years ago), in this Quora question: https://www.quora.com/Whats-the-logic-behind-Google-rejectin...

He even explains how he actually did well in the software engineering interviews in the process.

In my experience good developers end up being good because they tend to do a lot of coding, read a lot on how to code correctly, and on how to improve their skills. Most people that I know don't do this because they need it, but because they are motivated to do it. So my question to you would be: do you like coding/developing? Are you up to spending time improving your skills?

You're saying you're not sure what to do about it, but from your post it sounds obvious to me that a next step would be to spend some time learning about CS, practicing coding/maintainability, and such?

I'd also add that not every developer needs to know every single aspect of CS, all the theory behind it, or even be an excellent coder. There are different areas in developing and you might find one that motivates you without needing a lot of any of the specific areas you mentioned.

For me it's been the opposite, actually. I use Mac, Windows 10 and Ubuntu for different use cases, and I keep finding Mac more appealing. I have to work around Ubuntu to make some stuff work sometimes. I really like Windows 10, but I have issues occasionally as well. With OS X, most of the stuff I try to do just work.

A few years back, I'd prefer to buy my own hardware, build my own PC and run Windows to save some cash and have a powerful PC. I would need to work a bit to make it work, sure, but I'd save some money. Now, I'd rather get an Mac, which is more expensive, but for which I have to worry about much fewer hardware and software issues.

I wonder if getting one of those Microsoft Surface Laptops would give me a similar experience with Windows 10, though.

I see what you mean, but I don't really agree. You can introduce that burden and complexity whenever you want. If you spend the start of your project working on this, you will be prepared for scaling (if you ever need it) but you could have used that time on actually working on the project and checking if you actually will need scale at some point.

I don't know about your projects, but I'm my case most (all) of them doesn't really need any kind of scale. Hell, this blog has a tiny 5$ DO machine and is still happily serving traffic from HN. I do understand not all projects are small blog instances, though :)

I guess in my case I prefer to just keep it simple and see how far I go with that setup than spending time working on making the perfectly-scalable project that is never serving more than 2 requests per second. If it ever grows, I will need to work to make it scale, sure, but on the other hand that is a good problem to have.

Anyway, I understand this is pretty subjective and depends on how you think about your projects and your requirements, so I do understand there will be people both in agreement and disagreement.

> Frankly the article is filled with FUD and the author justifies everything with "i think/what if/my way is fine for me".

It is just my opinion after all. I'm just trying to share my thoughts :)

> Yes it is. I wonder if the author has actually tried setting this themselves.

I've used K8s for months in production, maintaining a few clusters at my previous job.

I will also invite everyone to try it and I also believe K8S is here to stay. I think K8S makes a lot of sense for lots of workloads, but I don't think it makes sense to maintain a k8s cluster to run personal projects.

About complexity, what you're saying is true, but I think "once your cluster is running" is making a lot of assumptions about what is actually running in the cluster in terms of infra and what workloads you can run there.

I do agree with you, but I don't think I really missed the point of the original article. From the original article: > However popular wisdom would suggest that Kubernetes is an overly complex piece of technology only really suitable for very large clusters of machines; that it carries a large operational burden and that therefore using it for anything less than dozens of machines is overkill. I think that's probably wrong.

I don't think that is wrong. I do think it is probably overkill, and IMO it does introduce operational burden and complexity. That doesn't mean you shouldn't do it, though, if you're interested in exploring the technology, for example.

Thanks for sharing your thoughts! I wrote about Fargate because I like the idea of having a service that manages both masters AND workers and where you only need to care about the API, but didn't really try it yet. That was my impression as well, though. Even the use cases mentioned in the pricing site are just containers running for a few hours a day, and not long-running services like servers.