lambrospetrou

Exactly this.

DynamoDB is a pain in the ass if you want to do too many relational or arbitrary queries. It's not for data exploration.

It is my favourite database though (next to S3)! For cases where my queries are pretty much known upfront, and I want predictable great performance. As Marc Brooker wrote in [1], "DynamoDB’s Best Feature: Predictability".

I consistently get single digit millisecond GETs, 10-15ms PUTs, and a few more milliseconds for TransactWriteItems.

Are you able to complex joins? No. Are you able to do queries based on different hash/sort keys easily? Not without adding GSIs or a new table. The issue in the past few years was the whole craze around "single-table design". Folks took it literally as having to shove all their data in a single table, instead of understanding the reason and the cases that worked well. And with ongoing improvements of DynamoDB those cases were getting fewer and fewer over time.

But, that's what tradeoffs are about. With on-demand tables, one-shot transactions, actually serverless storage/scaling, and predictable performance you get very, very far.

1. https://brooker.co.za/blog/2022/01/19/predictability.html

What if your company could have only one single advantage over the competition? This exercise will make your positioning and strategy stronger.

Hurl has been a great choice for the platform too. Zero regrets in choosing that so far. I even converted some colleagues at work to use it :)

Looking forward to seeing the more powerful additions to Hurl coming soon!

I have also written about my "worklog" [1], what I call my own changelog at work.

It's a simple Markdown file, versioned on my own Gitea instance.

The worklog contains all notes about everything I spend my time at work. That is project work, meetings, discussions, todos, long-term todos and investigations, and anything I need to be able to check back later.

I cannot count the number of times I went back and searched this file to find information that others forgot, the meeting notes did not capture, and in general things that I need.

Keeping this kind of log makes performance reviews trivial too. Just scroll through the worklog for the period you want, copy paste bullet points, and then spend some time cleaning them up and rewriting them as necessary.

If anyone does not keep a worklog, start now :)

1. https://www.lambrospetrou.com/articles/the-worklog-format-1/

I have built a managed platform automating HTTP API testing, at https://www.skybear.net. The core basis is to run your Hurl files. Automatic report persistence, scheduled runs, and multiple files supported with hundreds of requests per "run/execution".

Soon, I will be adding analytics, insights, and automatic test generation features.

I have been working for a year on it, and will keep working on it for many years to come, since I am using it myself a lot anyway.

Just published a new article about "The CI/CD Flywheel". Why it's such a superpower for teams that embrace it, and how it maps to CI/CD pipelines.

I dive into the different steps of the CI/CD flywheel, including local code authoring, running CI jobs on pull-requests, deploying and verifying on staging (preproduction) environments, and finally deploying and verifying in production.

Then, I try to showcase the business and technical benefits of a proper CI/CD pipeline.

Busines benefits: - Ship value to customers more often - Earn and retain customer trust - Fast experimentation feedback loop - Attract the right talent - Cost reduction

Technical benefits: - Code quality - Comprehensive tests - Automate repetitive tasks for reproducibility - Build once, use everywhere - Controlled rollouts and faster Mean Time To Resolution (MTTR)

I would say that luck in FAANG interviews is much lower than the average tech company. At least in my experience. Don't get me wrong, there is luck involved, and it's a big part of the interview process.

But, at least, you have standardised pools of coding questions, standardised pools of system design questions, and a standardised feedback form.

The interviewer varies a lot though... And makes all the difference when you have an inexperienced one, or someone that doesn't care.

At Amazon you could become an EM1 by switching internally from SDE2 (L4 at Google/Meta). Also, in other companies like Datadog, Cloudflare, the first level of EM (used to be called Team Lead) is parallel to Senior Engineers.

I am the author :)

>I can only assume the author has not interviewed many candidates.

I did more than 100 interviews so far.

>I've lost count of how many tenured engineers I've interviewed who could not write basic code or explain basic programming concepts. Things that a practicing programmer would encounter every week.

Where did I say that I agree with this statement. This is what other engineers claim, and as you pointed out being said many times.

I am totally against this claim as well. I do think that those tenured engineers should be interviewed for basic coding skills too. Just last month I had a staff+ engineer not being able to write a DFS...

That part in the article is ironic, hence why I said that I didn't want to make it a discussion about the fact that we have these coding interviews, and to "Get over it!" :)

>For example, linked list, hash table, DFS and BFS, simple sorting.

These are a given. You should know these.

When I said I cannot memorize solutions, I refer to memorizing solutions to specific Leetcode problems. Doing that for 1-2 problems per main area is doable, but anything more than that is quite hard.

>2) practice communicating with people that have very thick Indian or Chinese accents. It will also help in general day to day life

Absolutely :) I have that item explicitly in my article, since it happened to me as well being on both sides of the interview process.

It's very unfortunate when communication is problematic accent-wise. And it makes judging difficult as well since you are not focusing on the technical merits alone anymore.

>1) don’t expect only questions relevant to the position.

For this, you might have been unlucky with an inexperienced interviewer...

>people don't see me as a manager, for them

Can you elaborate on what you mean by this? Do they focus more on your IC experience and reject with the excuse that you don't have a lot of years being a people manager? Or did you mean something else?

Yeah I thought many times about a standardised interview process. There are pros and cons in such system though. Would the exam be broad or go deep, would it test all kind of coding problems or would there be categories? In a way Big Tech's interview process is this standardised test, but once you go a tier lower, the interview process is a wild west. Much easier questions, and much more conversational interview which introduces a lot more bias and subjectiveness.

In every company I have been, this has been proposed in some form, and the argument is always that the current coding questions approach is a reliable way to filter out a lot of the unwanted candidates, at the cost of also rejecting some very capable engineers. It's an accepted trade-off.

I totally agree that at higher levels System Design is required. That's why I have a whole section about System Design in the article. See https://www.lambrospetrou.com/articles/big-tech-software-int...

I describe all the resources I read outside my day job's material. There are a lot of useful engineering blogs you can use, and with 1-2 books you can go very very far in learning the principles.

Once you have the theory, then you just need to practice on brainstorming designs for any kind of app you want. Then, you can verify that with the real implementation, you can pretty much find information about any big-scale famous system online. Or you can do mock interviews with others, but I am not a fan of these personally.

In my experience, reading, and then trying to come up with designs on your own for well-known products will make you ace these interviews after a few months.

Also, during the interview there is no nearly enough time to verify that you have done in the past all the things you will mention. So, if you understand what you are saying, and your design makes sense, you will pass the interview, even if you haven't practiced these things in your day job.

I have actually seen several colleagues jumping into EM roles (Engineering Manager) with just a year of experience being a manager, or even from just being a team lead (technical leader, not manager).

In companies that have the first level of management at the same seniority level as the Senior Engineer, it's very doable.

I agree with this approach. I cannot memorize solutions at all. I can however learn a few techniques and try to pattern match a given problem into those techniques.

I do admire folks that can memorize more than a few tens of problems though. It's a skill on its own!

That's an interesting approach, and indeed I have seen it happen. In some companies though, the interviews are very similar and include coding as well even for managers, so might not be a silver bullet.

I do think though that if you are OK being a manager for at least a year, it's a very viable path!

I just finished a (long) article about preparing and passing the software engineering interviews in Big Tech companies!

I hope many folks find it useful, and helps them in their next interviews, whenever that is.

I did a brain dump of how I prepare, and what I do as an interviewee, and also as an interviewer in such companies.

Please let me know if you like something specifically, or have any feedback in general.

Enjoy

Hmm, I think I saw them before but didn't try it since it's still in very early stages, judging by their documentation.

I can see it more like Fly.io competitor, rather than a full platform. At least based on what is in their docs now.

The thing is that abstracting away all the resources means you need to recreate everything from scratch (even if you use a cloud provider underneath), and this takes huge time.

In my case, having the nice Developer Experience on existing products offered by AWS (or others) would be a better suited solution I believe.