I wouldn't wish my enemies to go there - Software Engineer Amadeus Employee Review

One should guess from the start of the recruitment process, that this is the place to avoid. A place which hires, regardless of which team you would work for, means your individual skills just don't matter. The technical content of the interview is just the online test, which is a cake walk compared to other companies. After that a team leader telephone chat is briefly technical, and then the only face to face, is with a senior manager, who stopped being technical more than 10 years ago! Agents will tell you to just show that you are keen to work in the airline industry and you will be hired! Besides, who you interview with, has no bearing on who you will work for. I never saw the manager or the team leader I interacted on the phone for the 2 years I worked there. Just before joining, one random manager gets given a new joinee, based on who requires a new robot to do the button pressing work that's all that goes on in this company. It has the most antiquated tools and process, which are so cumbersome and slow, one sometimes wonders if pushing paper between desks might be quicker than their processes. A one line code change can taken you a week to locate, a minute to do, and another 2 weeks to take through the laborious SDLC using a 19th century like bug tracking tool, which should be consigned to the history books. You make the code change, regression test it, get it code reviewed, submit a pull request. If that succeeded, you manually mark the change in the bugtracker as "Approved". Then you must remember to mark the code review state to "Submitted", otherwise the bug-tracker won't have the right state later on. Then a week later, when the code is loaded in UAT (thankfully not by you), you have to remember to mark your issue as "Loaded test". Then if you or some BA actually cares, you verify the fix works, or like many people asked me to do, just hit the next button on the issue "Verified in test"! Then you may have to wait 2-3 months and come back to this issue again when the code is loaded in PROD (after several fallbacks), to mark the issue as "Loaded in Prod"! Again, if you don't do it, some other tracking will fail which will annoy some managers. A lot of manual labour for a 1 line code change. Imagine this being your job on a daily basis! Then the less said about the software the better. One encounters 1000 line C++ functions on a weekly basis. Yes, 4 digits, it's not a typo! People are too scared to refactor old code "incase it breaks". Well, given the recent public fiascos seen in the massive failures, it is no surprise such things are now falling apart. How can one possibly trace such long functions and make sense of the code. Recently, a massive failure was attributed to the lack of code reviews. Then, code reviews became the new mantra of the day. The problem is senior management has no clue about how modern software should be written. They wrote and left this mess some 10 years ago, and now they are too late to modernise. Often they send emails reminiscing in the failures at past cutovers, almost as if celebrating failure. On a daily basis there are issues with the tools that are taken for granted elsewhere, for example disk space for development, doing builds. There is never enough disk space to check out all the code to work on and it takes hours to build if you do manage to checkout all the code. Even after that the tool chain is so bad, that you can't tell if a build failed or passed without significant effort. The intranet pages also are terribly flaky, one or the other set of pages breaks several times a day. The company doesn't have a test team! It relies a completely non-deterministic regression test framework, written by developers, which if they fail one night, the boss will tell you just wait one more day, it will pass tomorrow. Right enough the nightly failures would have passed the next day! It is a well known fact that there are scores of these regression tests which pass, but don't test anything of value. Many failures are blindly accepted as false positives when actually code remains broken, but the effect of it isn't seen till much later. If a test which used to "pass" before started failing, quite often, people put a sleep in the regression test to make it pass! Some people have been making efforts to push unit testing of code, but it is a huge struggle with attitudes of old and new staff not being receptive to the idea, so it remains a pipe dream to make this a formal part of the process, which is what may actually add value, besides investing in an independent test team! Whoever works there and leaves, doesn't say anything bad about the company at exit interviews, because, everyone who's been there realises that this is the place of last resort! If you can't find a a job elsewhere, you can always come back here, as the bar is so low!