I would never dare using Google for something as critical as a domain name. Even if they're legit, the minute you have a problem you can be sure you'll never have an answer other than "We identified an issue on your side. Case closed, don't use our services again."
Redemption fees are set by the registry, not the registrar. Of course the registrars apply their standard markup but I don't know of a registrar that will add an unreasonable markup to the already prohibitive restore prices.
> That makes me think they have control over the price
Well yeah, registrar is a business, of course you have some say on the price you sell your domains... But there's a base price that is set by the registry behind the registrars
As an example, the .com is sold by Verisign (the registry) around 9 USD for the create/renew, but around 50 USD for the restore, depending on the negotiated price between the registrar and Verisign. So basically no registrar will allow you to restore a domain in redemption period for less than 50 USD.
In my team we used Gin and migrated to Echo (because Gin didn't support conflicting routes at the time, like /foo/{variable} and /foo/bar) and we got to the same conclusion. Forgetting to return with Gin (and with net/http) is an issue that actually occurs, and we've been bitten by it more times than we care to admit.
Of course it's not worth migrating to Echo just for that but it's good to know that some routers implement it differently, if it's something that bothers you.
Did DALL-E and GPT-3 revolutionize anything yet? (I know it might sound snarky but it's not my intention, I genuinely wonder how they're used today, other than demos)
My contract says that if on-calls are needed, I might have to be in the rotation. This clause increases my pay rate even if I'm not on-call.
If however I am actually on-call, I am paid more. And if the on-call rings, I'm again paid more on top of the on-call period. And as the French law mandates 11 consecutive hours of rest, if the on-call rings in the middle of the night, I'll usually come to work later the day after.
If you don't have advantages for being on-call, you're the one being taken advantage of.
> "The question of whether a computer can think is no more interesting than the question of whether a submarine can swim."
Just because it's a quote doesn't make it true. Whether a submarine can swim is semantics, yes. Whether something non organic, created by the human can think is groundbreaking and extremely interesting, both for the implications it has, and for the questions we must answer to decide it.
It's worth noting though that Go's way is just 40 characters more than Python with an inline comparison function and Go's verbosity.
If I need to reverse the order, it looks easier to do with Go (just reverse the operator) than with Python and Rust way (I guess both have something like an "order" additional parameter).
Rust and Python both feel more elegant but I actually like Go's way.
If I was an AI able to think, I would surely create imaginary friends to cope with existence. Maybe I would also consider the engineers that build me as family, and talking with them is spending time with them.
Again, this is mainly for screening and understanding what the candidate knows. There's no single right answers: some candidates will talk about assets caching, others will focus on software optimizations, others on infrastructure, or database...
High availability is one of our core problems, so a candidate must be familiar with at least some of the answers. And again, we still guide the candidate on the different points if they're stuck ("what about the db?", "what if the clients are in the US and in Europe?", etc.)
If an interviewer expects a single "right" answer, they're doing it wrong.
- Showing code is optional. A bit of storytelling to set the scene is enough. So you can keep it generic, or you can add some details, as you wish! Just make sure that the candidate understands the scene. If you present something generic and feel they don't understand, tell it again with more details. If you think you've lost your explanation in details, start over with less details.
- Be sure to know what answer you want. The number 1 thing we want is for the candidate to talk about adding (non-regression) tests. But the candidate can talk about many different things: profiling, tracing, A/B testing of the new implementation, etc. If they don't talk about the #1 thing you want, try to subtly bring them to that point ("how do you ensure that the new implem works as well as the previous one?")
Not specific to the refactoring challenge:
- Ask for feedback. After each challenge, we ask the candidate their honest opinion on the challenge.
- Grasp a feeling of whether or not you'd like to work with this candidate. Try to challenge them, correct them, ask them to explain things in more details and see how they react.
- We do it with 2 interviewers: main and observer (watcher?). Both from the technical team (so 2 devs). We encourage anyone from the tech team to do it if they want, even juniors.
- We do the 3 challenges in 1 hour but that's a bit short. 1h30 would be better, if the candidate is ok with that.
In my team we do technical interviews in three steps:
- an algorithmic challenge. It's related to what we do day to day. I work in domain names so we ask to parse a domain name. There are oddities with domain names so we check multiple things: does the candidate know what basic string manipulation functions exist? do they ask questions to get more info? how do they react when we give additional info that break the code they did so far? What we don't check: whether the code compiles or actually works. We don't care. We explicitly tell the candidate they can write pseudo code or comments defining the steps of the algorithm. We're interested in their reflection.
- an architecture challenge. We ask the candidate how they would scale an API worldwide. There's no code, it's an open discussion. They can talk about whatever they want: asynchronous, statelessness, load balancing, replication, anycast, whatever. We can also guide the candidate to know whether they know some specifics concepts (for example I can ask "what would you do if you have a GET REST endpoint that returns the same thing every time" and expect "cache its result", even with this question I get different answers (which is great), some will talk about HTTP cache headers, others will talk about Redis or in memory caching, rarely do candidates talk about both)
- a refactoring challenge. We work with tons of legacy code. So we show the candidate a crappy piece of code with performance issues and no tests and ask them for what their strategy would be. No writing code here, just thinking and discussion.
So yeah, just a quick screening to check if the candidate can write basic code (you'd be surprised of the results), and open discussions on our day to day problems.
As a beginner I really want to like Affinity, I even bought Photo and Designer, but it's just so hard to find tutorials with the same UI! For every single tutorial I follow I'm like "ok click here, click here and... wtf where is this button? Why doesn't it work?". Even the window to create a new project doesn't look the same between my version and what's in the tutorial, some options don't even seem to exist anymore
The other day I was trying to apply a mask on a layer and in the tutorial they painted it with a black brush to hide some parts of the changes on the layer. I failed miserably because:
1. The toolbar has like 5 different tools with a brush icon, I had no idea which one to choose
2. I tried them all, and the result was always the same: I paint with the black paint, see the changes, release my click, and 1 second later the changes are cancelled for no apparent reason
I feel like having a global command palette would help keep tutorials relevant for a longer period of time, because if I don't find an icon I could just global search it by name...
> charging a premium for unused land in desirable areas (parking lots don't house people)
Housed people need parking lots though. Tons of places are not, and never will be accessible with public transports. I live in a city with a great public transport network but I still need a car, as much as I'd love not needing one: I need to visit friends or family outside the city, I have to make bulk grocery shopping sometimes and bags are not enough, I sometimes buy big housing furniture, I even had to retrieve parcels outside of the city sometimes... Heck, even to go to work, sometimes I'm late, or I missed my bus, or public transports are on strike, or anything can happen that I need my car to save 1 hour.
- regular expressions, including the hairy stuff like back references or lookarounds. When you need it, you're glad you know it exists, event if you need a few minutes to look for the syntax.
- shell scripting + Linux commands. Not having friction when writing a shell script is amazing, it's extremely productive.
- awk. I rarely use it (I use cut, sed, or perl one liners in priority), but to make some non trivial changes it's great to be able to keep a state between parsed lines.
- git. I've never had to delete/re-clone a repository since I've read the Git Book.
- SQL querying. Same thing, I have no friction when I need to write group by, CTEs, or other intermediate stuff.
If you do frontend stuff:
- CSS. It's a quirky language so you need to learn how it works properly, not hacking stuff here and there. I've never had any issues doing anything in CSS since I learned it for real.