ingvul

> Refactored our front/end experience using React.

vs

> Increased user engagement 27% by refactoring our front-end experience in React.

Do tech interviewers actually prefer the second description over the first one? To be honest, I find the second one out of context (and a bit robotic/pedantic). Reasons:

- sure, 27% may look like a decent increase, but what was the metric you guys used? How many users you have? One cannot put all of this info in a resume of course (because it's a resume!) so please don't just drop a 27% there as if it means a lot

- I can imagine that the goal of the team/company was to "increase the user engagement", even perhaps "increase the user engagement by X%" and the product team thought "alright, let's refactor our front-end in React; no idea if it will bring an increase of X% or X/2%, but let's do it". But it's impossible to say that React (or any other tech) will bring you an increase of engagement in %X exactly. You just don't know that number, the number comes after; you may have some hypothesis but that's all. So, what you are actually telling me is this: "hey, we wanted to increase our user engagement by some percentage and so we refactored our front-end in React. Later on, our analytics tool told us that the user engagement increased by 27%." Again, you weren't aiming for that number, it just happened.

- you are not going to get hired for that 27%. Imagine there's another candidate that says "Increased user engagement 89% by refactoring our front-end experience in React". What now? Is him better than you? Again, context is king, but you cannot put that much context in a resume.

Your question seems to imply generality ("systems design"), but the description of your question seems to imply specific tooling (e.g., Kafka).

Many people have mentioned really good books (e.g., DDIA). Such books are good for gathering a general knowledge about "systems design", but you will be still clueless about the differences between Kafka and Rabbitmq until you actually read their documentation manuals.

There is no shortcut I'm afraid. If you want to "understand seemingly endless options when it comes to data handling on backend side" you will have to read the corresponding seemingly endless documentation manuals. How else would you know about the advantages or disadvantages of, let's say, InfluxDB over Postgres if you don't read their manuals?

Explanation here https://spdocs.github.io/texme/

Thanks for this. I was looking for something similar last month.

Well put. It took me around a month to get into the WFH mood (point 1). I have a dedicated room and I don't see (at least for me) WFH feasible without one (point 2). Regarding point 3: unfortunately, I cannot control that.