fredrb's comments

I’m sorry that has been your experience. The culture you’re brought up in is hardly representative for 8 billion people’s experience.

It’s not that bad if you need to deploy at least 3 things and for most cases it beats the alternatives. You can get away with a bootstrapped deployment yaml and a couple of services for most scenarios. What should you use instead? Vendor locked app platforms? Roll out your own deploy bash scripts?

Sure the full extend of Kubernetes is complicated and managing it might be a pain, but if you don’t go bonkers is not that hard to use it as a developer.

I picked this up as a first reference as someone who had no knowledge in DSP and it was an absolute gem. Really helped with the mental model for sound processing. This repository has some amazing resources too: https://github.com/BillyDM/Awesome-Audio-DSP

Location: Berlin, Germany

Remote: Indifferent

Willing to relocate: not at the moment, but open to discuss depending on the job

Technologies: backend/systems engineer generalist. At the moment I work with Go, Kubernetes and Linux. I’m interested in C, Rust and Python as well. Would work in any programming language.

CV: Upon request via LinkedIn or email. I have a outdated one here [1] without much information about my current employer.

Email: fred.rbittencourt [at] gmail [dot] com

Sharing preferences and opinions on code ergonomics certainly has value for me, and I bet it has to other people too. This is, after all, a developer's forum.

I'm certain your opinion on petunias and your possible distaste for orchids will be welcomed in a flower-news type orange site. :-)

I don't work with it either. But I find that learning the abstraction below where you're working at can be quite beneficial to understanding the constraints of your layer, debug, and solve problems.

E.g.: Learn the basics Transport Layer protocols (TCP/UDP) if you work with HTTP

It's interesting to see how many people in this thread have had negative experiences with OOP. As much as I don't do OOP that much anymore, I think it had a positive impact in me. But like every popular practice, there is a lot of bad patterns you have to navigate through.

Things like depending on interfaces as opposed to concrete implementations; or prefer message passing over direct data access are practices that I learned in OOP that I still value. The "Small Talk crowd" from the first team I worked in and influential authors in the topic (specially Sandi Metz) still have a dear place in my heart for how they improved the way I view software design.

That’s usually how human conversations go. It’s not always efficient. You should try it sometime.

Thanks for pointing this out! Should have looked it up before. Fixed in the post.

Thank you for these points. I've made some corrections in the post.

> consider that something like à can consist of either a precomposed "à" code point or an "a" + "` diacritic" sequence

If Unicode provides a precomposed combination doesn't it mean that in fact has a code point for every character? Regardless of offering diacritic combination codes?

Right. Impossible might have been an exaggeration, I will fix that. The point is that if you're reading a file with the text "hello world", you can only make out the characters because you know the encoding. Given two completely different encodings that map the same hex values in the message it would be impossible to determine which is the correct string. There is no such thing as plain text.

So does most templating languages.

My worst experience was when an interviewer told me to stop doing the exercise because time was up, and proceed to say that they could "solve this exercise in 30 seconds by copy-pasting an answer from StackOverflow". They mentioned in the beginning of the interview that I could Google whatever I wanted and then said I "should've taken the hint if I wanted to complete the exercise".

The complete interview was a joke. The person didn't know which position I was applying to; another guy joined the interview halfway through and asked if he should take over; and the worst: the main interviewer was boasting about working 12 hours a day as a contractor and getting double the salary from the actual employees.

They didn't make an offer.

> Well; code review is not QA. My approval means - I'm OK with how the code layer is knitted. It doesn't mean I've tested the changes.

I'm 100% on-board with this. However, I understand were OP's mindset comes from. A few years ago I was working at a development shop in a fairly large project, where we had little to no automated tests. We frequently had PRs that would break main features. At some point developers were required to perform smoke tests alongside code reviews.

There are also other approaches to the problem, like Jump Hash, Multi-Probe and Maglev hashing. Each of them offer a different combination of load balancing, scalability and performance trade-offs. [1] provides a good analysis of the available methods and their tradeoffs.

[1]: https://dgryski.medium.com/consistent-hashing-algorithmic-tr...

This is very interesting. Unfortunately it seems to be closed source and they're still working on a more technical blog post.

I wonder how they encode all the information in the PNG file? Apart from the .zip with the entire ROM I assume they snapshot the current memory state on the beginning of the Quote and all the subsequent inputs.

> How to match "interview kind" to candidate? maybe ask them which they prefer, I guess?

I don't think it's a matter of candidate preference but rather position need.

Some companies need Computer Science / Engineer mindset to solve complex problems. Some companies need XYZ framework developers to deliver customer projects. FAANG companies usually need the Engineering role and developed an interview model to select those.

The problem is when companies that need developers apply the same interview mindset that Google does.

I recently switched jobs and got interviews in 5 big companies for mid/senior Software Engineering positions. All their processes were fairly similar: Two coding interviews, one system design interview and a conversation with the hiring manager. I might be biased because this process was beneficial for me, but here are my 2 cents on it:

It's easier to get a position in a stack you don't have professional experience with. You're tested for your ability to learn CS concepts, not stack specific knowledge. All 5 positions I interviewed to had different technologies. If I had to learn the specifics of each before applying, I would likely not get offered any positions.

Do they avoid all dynamic typed languages or only Python in particular?

Wouldn't a tracing app make more sense than having a rigorous border tests? It takes one miss-tested infected person to start a second wave in the country. So I would assume that the investment to make sure businesses provide the QR pays off testing everyone and risking another lockdown. I'm also not sure countries have the resources to enforce huge amounts of tests at the border.