remoteorbust

First off, the author of fasthttp has made some great packages that I do use in production.

However, last time I looked fasthttp was great if you don't care about http2 support or streaming bodies. Unfortunately I do.

I once ran an "embedded" Linux on a $10 marvel SOC. It was a pretty vanilla kernel running a basic Debian install. 10MB out of 128MB RAM used most of the time.

Obviously you can go much slimmer, but a $10 board is surprisingly capable.

I once worked at a company with no product management experience. Because of this they hired a string of toxic Steve Jobs wannabees because they simply didn't know what they didn't know.

They lacked experience in many areas. Ironically they ended up firing their only experienced executive (CTO). It's too bad, they had passionate engineers who could have built some amazing things (as evidenced imo by the amazing things they later built for Netflix/Google/Facebook/Amazon/etc) but they were stuck at a company that sort of wanted to be a tech company but didn't want any of those annoying "IT people" involved in decisions.

Easy: recruiter asked me if I wanted to work remote. I said writing go and working remote and getting paid bay area comp sounds good.

But of course becoming the person that recruiter reached out to involved several years of study, betting on a brand new language, taking a risk on a startup with no money and a few other things.

I promise you. If you ignore the churn and learn the fundamentals, your skills will have an order of magnitude longer shelf life.

If you know js and web standards then anything on the frontend is just a new application of the same ideas. If you know a bit of networking and a bit of operating systems then web development in python/django/Scala are all just interesting new ways to say basically the same thing.

If you know the specs then you don't need to find out about technology by following 100 different blogs.

Occasionally there will be new fundamentals to learn but you'll be ready because you won't have a backlog of relearning framework X's new way of saying "hello, world".

In case you didn't know the author has built the programming language that formed the backbone of some of the original multithreaded web servers that reached an incredible scale for their time. He is currently involved in research on "core aware thread management", "nanosecond-scale logging".

This causes me to interpret statements like "Programmers tend to worry too much and too soon about performance." more charitably. I think he does care about real performance.

> she was then deemed a "fixated person", which involved incarceration without charge, being taken to a mental institution and forcibly injected with anti-psychotic drugs for months. Eventually a judge decided she could go home. All media coverage of it is banned in Australia until the trial is finished, which has been postponed at every hearing for over a year now

Holy shit. Maybe I'll stop complaining about the US plastering the names of the accused all over if this is the alternative.

Terrible idea: could you write a transpiler for rust that basically auto-wrapped everything in a Gc<> type and auto-dereferenced?

Sure. If you are a CDN right now you can host multiple customers on one ip. If you are using TLS there are 2 ways to do this:

1. Have a big SAN cert with lots of names.

2. Use SNI to select the correct certificate for that client and route to the correct customer config (and therefore correct origin)

If SNI didn't exist we'd be back to the bad old days of every TLS site requiring a dedicated IP. As ipv4 exhaustion has gotten worse this has gotten more expensive. However if we're using ipv6 then hosting N listeners for N ip addresses, each with their own dedicated cert, is much more scalable.

Thanks for the heads up. I've made some proxy software that routes on SNI. If TLS1.3 drops SNI then I feel like that will accelerate ipv6 adoption because we're going to need a shitload more IP addresses.

> It's bizarre to me that you think that whiteboard coding tests "communication", in any way. It's not like a presentation, or anything.

I feel like we're probably at an impasse if I can't convince you that a whiteboard is a decent medium to communicate ideas around datastructures and algorithms, but I appreciate your point of view.

I can only say my experience, which I hope you will take into account as one anecdote. I don't read books about "cracking the coding interview" or do leetcode or hackerrank. I left school 14 years ago or so my stash of cs trivia/secrets/gotcha isn't particularly full. I've done whiteboard interviews where I come up with at best a naive solution.

And yet I've received offers for fairly senior engineering positions at Amazon and Twitter and (hopefully tomorrow) from Google. Most of the whiteboard interview isn't even around the code, although that's a small part. Most of it is analyzing the problem, discussing constraints, discussing tradeoffs, walking through data structure manipulations, drawing arrows and boxes, that kind of stuff. Some code, maybe 30% of the interview. I just keep having this experience where nobody wants to play the gotcha game, they want to know how well I can communicate while solving a problem and they think they get that information out of the interview (I agree with them).

That experience makes it hard for me to understand a viewpoint that believes that whiteboard interviews are about memorizing secrets in advance.

That's an excellent idea. I'm in no way saying the existing method is perfect. Just that some of the things it tests around communication and being put on the spot and analyzing a problem in a way that is understandable to the rest of the room is actually a really good engineering skill. There can be other great ways to measure those skills.

I know my opinion is unpopular, but I sometimes do think I've figured out something other people miss. I think when it comes to whiteboard inteviews, candidates are often playing the wrong game. They think it's about gotcha questions and they think they fail because they didn't leetcode hard enough. I don't think that's true, they are just trying to game the thing that's easy to measure.

In my experience with the "terrible" FANG companies, it's not about gotcha questions. I get the offers even though I don't often find a non-naive solution. The people I'm in the room with really do want to see my thought process and they really do want me to communicate the tradeoffs with them. People don't fail the gotcha questions because they don't know trivia or because they forgot a detail from their CS classes. They fail the whiteboard interview because they see an unfamiliar question and say: "I don't know that trivia" instead of drawing out possible solutions and having a conversation with their interviewers.

> Whiteboard interviews test one thing well: How well does a candidate code on a whiteboard.

What if you consider part of someone's job to be communicating concepts to people, possibly with the help of visual aids and diagrams?

I hate this concept that if it's not typing code into an editor then it's not "real work".

I absolutely communicate with my coworkers using a whiteboard and pseudocode. I reject the idea that being put on the spot is necessarily "artificial". To the contrary, I think that the number of engineering jobs where you can assume you'll never be put on the spot or have to communicate complex ideas verbally or visually is relatively low.

Now if this particular skill isn't interesting to an employer and they'd rather spend the time talking about some other candidate capability, that's a whole different story.

Yeah that's already happened and it's discoverable enough that I wandered onto one of those pages by accident when signing up.