iOS Software Developer Interview Experience - Amsterdam, Netherlands
Process
First step: receive a formal invitation to the introduction meeting. The last time I applied to the same position, I was rejected with a formal template without explaining why I did not suit them.
The first introduction interview (1 hour): I had a meeting with the iOS developer and Product Owner of one of the projects. We spoke about my experiences and awareness of some frameworks, best practices, and technologies. Communication with other teams. My failed and successes stories. No coding.
The second part: a technical assignment. I spent around 16 hours on implementation, leaving notes about improvements which I will be glad to add if I have more time. I received an invitation to the next step without any technical feedback about my implementation.
The third part (1 hour): a technical interview with two iOS developers. I was very disappointed with that tech interview. It looked like an interrogation of a witness when reviewers were trying to find my weakness. They didn't give me opportunities to finish my idea or chain of logical explanations.
Initially, it was screen sharing from one of the reviewers. He showed me code in the Xcode playground and asked about the complexity of functions, how I could improve it, expected print output, and more. Then we spoke about another playground and then about one more.
I think I answered around 80-100 questions related to iOS frameworks, Xcode, Swift, memory management, multithreading, performance, Core Data, security, the complexity of functions, properties of the class, etc. Sometimes reviewers said it was the expected answer, sometimes they just jumped to the next question. Sometimes they asked something tricky and not common (like using a .map to unwrap optional), sometimes some simple question. Very often I was interrupted by one of the reviewers, and that made me a little bit irritated. I didn't feel comfortable with them.
Questions
- How to use a .map to unwrap optionals.
- How to join a String array to one String.
- How to declare a DispatchQueue.
- How to work with global variables in a multithreading application.
- Etc.
Was this helpful?
Interview Statistics
The following metrics were computed from 1 interview experience for the Adyen iOS Software Developer role in Amsterdam, Netherlands.
Success Rate
Adyen's interview process for their iOS Software Developer roles in Amsterdam, Netherlands is extremely selective, failing the vast majority of engineers.
Experience Rating
Candidates reported having very negative feelings for Adyen's iOS Software Developer interview process in Amsterdam, Netherlands.
Adyen Work Experiences
- 2.0Very bad environmentSenior Software Engineer • Current EmployeeAmsterdam, NetherlandsSeptember 19, 2025Pros: You can learn some things. Some very competent people work there.Cons: own frameworks, you're locked to learn their frameworks that are used nowhere else.
- 4.0Above Average, Room For ImprovementSenior Software Engineer • Current EmployeeAmsterdam, NetherlandsMay 7, 2023Pros: It is for sure above the local average.Cons: Of course, there are better employers in the same region.
- 1.0Nice company, unless you work in techSoftware Engineer • Current EmployeeAmsterdam, NetherlandsDecember 17, 2020Pros: - Most colleagues are really nice and helpful. - Adyen provides a unique opportunity to experience how it was to be a Java developer at the turn of the century. - Despite everything, the product offered seems to work for end users, so job security is not an issue.Cons: Working in the tech department is a grueling experience. If I were tasked to create a work environment that prevents anyone from getting any work done, without making it technically illegal, I would take the Adyen setup and not change a thing. Standard modern Java libraries and frameworks are off the table: no Spring (boot), no testing frameworks, or anything other than plain Java. The monolith was created about 15 years ago, and the technology from around then, plus some homegrown, half-baked additions, are all the tools you get. All tech decisions are made by a group of grumpy old men who have been working at the company since the beginning. Their main job is to prevent any modernization or other improvement from changing the system they invented. The standard arguments are: "it is not secure enough for us" and "it will be too difficult to understand if someone has to fix a time-critical live issue." It is hard to argue that security and maintainability are not important, but I believe the opposite is achieved currently. As senior positions are only handed out to people who have been in the company for a long time, and not to new hires, the groupthink only strengthens, and new ideas are kept out the door. The MacBooks are overworked to run the software locally. They are painfully slow, with a local redeploy of part of the software taking 5 to 10 minutes and a full redeploy around 20 minutes. Both are required many times a day. Due to the monolithic nature of the software and the imperfect CI, it is common that errors are introduced, breaking your local build and/or the CI build of your changes. The laptops are centrally managed, which probably accounts for some of the slowness and certainly for the regular broken updates, forced reboots, and frustration, as installing any software locally is forbidden. Regular engineers have no permissions at all, making it necessary to beg for information or configuration changes from the happy few senior engineers. There is no database access, no configuration access on any test or production machine. Many parts of the code are extra protected, requiring explicit permission from the senior engineers. The "This is fine" cartoon of the dog drinking coffee surrounded by fire is maybe the best description of what's going on here. Everything is up for improvement and modernization, but the old men in charge deny this and are blocking any attempt at that. I genuinely regret ever starting here and would not recommend it to anyone.
