How to annoy your users featuring Volvo

I've owned a Volvo since 2017 and I would have hoped would have been fixed by a software update at this time, but no. So here are two things that annoy me pretty much every time I use the car. And then a third recent WTF moment.

A coding interview that never happened

I've conducted hundreds of interviews that involve some kind of problem solving and most of them involved writing the solution in code. And most candidates make the same mistake so I figured it was time to share a simple strategy that seems to have worked for me over the years when I was the candidate.

Fire and the US insurance system

It has been a long time since there was something interesting to write about in regards to relocating to the US. And it is a weird coincidence that once I started blogging again - something happened that makes me pick up this topic again. Since I lost a home in the Marshall Fire I'm about to learn a lot about insurance companies in the US.

Yet another tale from an interview - 13 years later

A little over 13 years ago I wrote something short about my Microsoft interview experience (now only available in web archive). Back then the format was a shocker to a naive swede and now 13 years later and several interviews later I figured I'll write something about my experience going through the Google recruitment process.

Rather than me writing a long thing here you might as well read this which pretty much explains my experience in general.

If that blog post is too long here are the important things from my own experience.

• You don't get a yes or a no - you get a yes or not now. Failing a Google interview is not a big deal since there are several reasons a good candidate fails to prove them selves. Get your chin up and try again.
• Be humble - if you are asked to implement Fibonacci with your 10+ years of experience just write the best damn Fibonacci the interviewer has ever seen with a smile on your face.
• Prepare - the cracking the coding interview book is actually a pretty good prep tool. I coded on paper one hour every night for weeks. And don't be over confident if you are asked a question from the book because those problems have more depth than the solutions shown in the book. If you are too lazy for that there is a rule of thumb I realized preparing; if you can solve something with a hash table or graph - you probably should. A lot of problems can be reduced into hash table or graph problems so learn how to identify and solve those.
• Think differently - Google do things on a different scale than almost everybody else. This means that things that are important to other companies don't matter at Google. That is; if you can speed up things by preparing the data for a repeated operation - you probably should, even if it means using thousands of machines and/or huge amounts of memory.

And most important; have fun. Even if I would not have gotten an offer I had a blast interviewing and would have tried again.

Still there?

When I decided to not post regularly, it apparently resulted in never. Well, I've decided it's time to change that after five years of silence.

A new schedule

For a long time I've made sure that there was something happening here on a regular basis. I've decided regular is no longer going to be the case.

All in on async/await

While I haven't been coding in C# for about a year now I couldn't resist reading this recent article. A nice write-up where I only want to make two additions.

Go for C# developers: functions vs methods

I must admit that I often use the words function and method interchangeable. Probably because I was once taught that a method is a function that does not return anything. In the Go vocabulary however there is a clear difference and a nice method gotcha!

Relocation, relocation, relocation

Looking back at March 2009 there is not much stuff that I still find interesting.

Scrum is like riding a bike with training wheels.

Over the years I've grown to dislike Scrum, mostly because I've seen it abused and misunderstood. And an approach that makes it easy to screw up is not a good approach in my opinion.