This is a tech review, so I'll focus on that.
Booking's scale is big. So if you're into large amounts of data, interesting A/B testing, or scalable architectures, then Booking has a lot of potential. Be aware though that almost all of this is made a lot less interesting by the mediocre and half-baked approach to almost everything in technology.
If you like getting paid for 40 hours but only want to work 32, then Booking is also great. Show up at 10:30? Leave at 17:30? Fine. This happens all the time.
If you love Perl, then this is also a great company, because like in Perl, there's more than one way to do it. So prepare to see every arcane Perl operator you ever knew, have three chat clients open (because there's more than one way to reach someone), prepare to work on lots of technologies that don't work together well, and prepare to see many different management styles or ways to organize teams.
The engineering quality and technology is mediocre. A lot of teams are very business-focused, which is great in principle, within their particular domain but without anyone maintaining any kind of overview.
This means that the default strategy is to just cram a feature into the existing code in the fastest way possible. That is, look for the piece of code that needs to change and add an "if (my_cool_feature_enabled) {} else {}" construct.
Rinse and repeat until you have Perl functions that span 5000+ lines. No kidding. By that time, everybody and their mother have touched that code, so no one owns it anymore.
Meanwhile, of course, some people have gotten frustrated with the spaghetti Perl codebase that is impossible to navigate and is an archeological record of two decades of mostly uninspired hacks and copy-pasting code (the latter happens to the extreme). So, new technologies have been added.
Which ones? Well, it's booking, so no one owns this process. So there's Java, which is the only 'official' second language for that matter. But of course, the data scientists use Python. And R. And there's Go, which is cool. And Kotlin, because it's also cool. Within the Java world, most popular (web) frameworks are being used. And so are all protocols you can think of. Same on the frontend: React, Angular, it's all there in various places.
This freedom is nice on the one hand, but it just doesn't work. It also leads to resentment between teams. "Why do they do their own when they could have used Spring boot?", "Why do they do this in Java when 3 lines of Perl would have been fine?"
Because no one takes ownership or dares to make decisions, people do what suits them best. This is very pragmatic, but it leads to loads of islands of different standards and tensions between these islands. Standards not only in technology but also in quality of people.
Pointing this out invariably leads to an explanation along the following lines: "Well, yes, but in order to understand this, you need to know the context," and then a war story comes to defend the mess. And that's fair enough, but no one cleans up after themselves.
Make people accountable and own their code.
Improve the engineering culture.
Set standards for technology. Allow new technology experiments, but make sure that if they don't add value but only maintenance, they are killed.
Have a long-term view on Perl versus Java and invest in people mastering their tools as engineers, so improve engineering standards.
You could probably do with 40% fewer people in tech if HR didn't hire for quantity but for quality. That would also give more than enough room to be (more) financially competitive on the hiring front.
Last but not least, improve your middle management.
I didn't touch upon that, but it is inexperienced. Some team leads are more like trade union foremen that will only work in the interest of their reports, no matter how incompetent they are. They should work for the company and its shareholders first.
Team leads also talk badly about other team leads or their managers too often. This breaking of ranks is disastrous for morale.
And an immediate 5% performance boost: cut down on the crap on Workplace.
The interview process will begin with an HR call, followed by a technician interview, then a team call, and finally a manager call. HR will reach out to you. If selected for the role, these interviews will follow.
The technical test was challenging. It included two multiple-choice questions and two longer questions. The phone call was good; the person calling was really nice. They asked about my experience. I am now trying to prepare for the in-person assess
1. The first round was a coding round with a third party where they asked a dynamic programming question. This wasn't an elimination round, though. 2. The second round was a coding round where they had their own problem statement. It wasn't very dif
The interview process will begin with an HR call, followed by a technician interview, then a team call, and finally a manager call. HR will reach out to you. If selected for the role, these interviews will follow.
The technical test was challenging. It included two multiple-choice questions and two longer questions. The phone call was good; the person calling was really nice. They asked about my experience. I am now trying to prepare for the in-person assess
1. The first round was a coding round with a third party where they asked a dynamic programming question. This wasn't an elimination round, though. 2. The second round was a coding round where they had their own problem statement. It wasn't very dif