A lot of engineering fads go in circle.

Architecture in the 80s: Mainframe and clients.

Architecture in the 90s: Software systems connected by an ESB.

Architecture in the 2000s: Big central service and everyone connects to it for everything

Architecture in the 2010s: Decentralized microservices that communicate with queues.

Current: RabbitMQ and Kafka.

... Can't we just go back to the 90s?

I hate fads.
I hate when I have to get some data, and it's scattered on 20 different servers, and to load a fucking account page, a convoluted network of 40 apps have to be activated, some in PHP, others in JS, others on Java, that are developed by different teams, connected to different tiny ass DBs, all on huge clusters of tiny ass virtual machines that get 30% load at peak hours, 90% of which comes from serializing and parsing messages. 40 people maintaining this nightmare, that could've been just 7 people making a small monolithic system that easily handles this workload on a 4-core server with 32GB of RAM.
Tripple it, put it behind a load balancer, proper DB replication (use fucking CockroachDB if you really want survivability), and you've got zero downtime at a fraction of the cost.

Just because something's cool now, doesn't mean that everybody has to blindly follow it for fucks sake!

Same rant goes for functional vs OOP and all that crap. Going blindly with any of these is just a stupid fad, and the main reason why companies need refactoring of legacy code.

About starting your career at a medium-bigger company that's well-established, versus starting at a smaller company.

That's my point of view:

It's always wiser to begin at a company that's more established (you will also be sure that you will get paid on time). I started at a well-established company, and I managed to buy gear, travel, do stuff, and then I realised that I wanna do more, not only live to work 😎.

Smaller companies are kinda risky, think of it, their goal is to reach the level of a well-established company, which is some levels lower than that. On the other hand, if you do well at a smaller company, your next goal will be to work for a bigger company, which will surely be nicer, more professional and will pay better. So you will have managed to et there with all the skills in your pocket already, which will come in handy later!

Bigger companies are excellent if you have a family (wife and kids), they provide stability, that's the most important thing, but I believe that in order to get "settled" in a company like that, you should at least have tried something else first, like doing your own thing or get challenged in more complicated gigs that require you to up your skills.

In the end, it's all sun and fun, with you code editor by your side 😉. I'm interested to see your opinions.

!rant

Working in a small comoany vs big company?

I always found myself in small companies (they are often more flexible with hours and work patterns) - those who worked in both kinds, have you got any preference and the main difference points?

My vague naive extreme understanding of interview questions are on a spectrum from situation a to situation b.

But what should the industry be doing? Is the industry just going wrong blindly copying big N companies hiring process without the same rationale? (e.g. they need computer scientists able to deal with problems specific to them at their size and that often means creating new tech, unreal problem solving abilities and cuh-rayzee knowledge)

a) stupid fucking theoretical shit that some people argue you won't ever need to be doing in practice for most companies, while giving you no ability to google, leetcode hard problems kind of stuff

b) practical work similar to what you'd be doing on the job, small bugs, tasks, pair programming on site with your potential future coworkers

Lots of people hate option a because it's puzzle/problem solving that isn't always closely related to what's on the job. Whiteboarding is arguably very much a separate skill. (Arguably unless it's like a big N company where you want computer scientists to deal with specific problems that aren't seen elsewhere, and you're making new tech to deal with your specific problems.)

We could go to the extreme of Option b, but it tends to trigger people into shitfits of "NO, HOW DARE YOU MAKE ME DO REAL WORK, BUT NOT PAY ME FOR IT AT THE INTERVIEW STAGE"

That's before we get into how to execute option b whether or not it's being given as a take home assignment (which is a huge pain in the ass and time sink, among other issues) vs a few hours at the potential workplace working with some of the future potential coworkers and soaking in the work environment (you have to figure out how to take the time off then)

Is it really just poor execution overall for the wrong use cases for the majority of the industry? What should the industry be doing in which cases.

Then this is all before HR screening with shit like where they might ask for more years of swift experience than its existed.