Hello, my name is Haythem Rehouma. I hold a Ph.D. in Applied Engineering from ETS Montreal, and I have a broad background spanning programming, engineering, and education. I'm passionate about developing robust software solutions and sharing knowledge to empower the next generation. It's great to introduce myself to you today.

I am a Canadian citizen based in Montreal, with 18 years of professional experience in the technology field. My academic journey includes a Master's degree in Artificial Intelligence from UQAM and another Master's in Communication Systems. This diverse education has given me a strong foundation in both theory and practice.

Throughout my career, I've worked as a software engineer, a researcher, and an educator. I believe that the best engineers are those who can not only write code, but also communicate clearly, collaborate effectively, and continuously learn. These are values I try to embody every day.

SonarSource is known for tools that help ensure code quality and security. Their most popular product is SonarQube, which analyzes source code to detect bugs, vulnerabilities, and code smells. It supports a wide range of programming languages and integrates seamlessly into CI/CD pipelines, helping teams continuously maintain high-quality code.

In short, Sonar is all about clean, maintainable, and secure code. The company was founded with a simple but powerful mission: to help developers write better code. Today, their products are used by over 7 million developers worldwide, including teams at Microsoft, NASA, and MasterCard.

What I find particularly inspiring is Sonar's commitment to the open source community. SonarQube started as an open source project, and this spirit of transparency and collaboration remains at the heart of the company's culture.

I want to join Sonar because I genuinely believe in the mission. I have been using SonarQube in my own projects for years, and I've seen firsthand how it improves code quality and helps teams catch issues early. The idea of contributing to a product that I already use and trust is incredibly motivating.

I'm also drawn to Sonar's CODE culture, which stands for Smarter Together, Excellence, Innovation, and Delivery. These values resonate deeply with me. I believe that no one is as smart as all of us working together, and I strive for excellence in everything I do.

Finally, Sonar wants to be a human enterprise, a place where people come first. That's the kind of company I want to work for. I'm looking for a place where I can grow professionally while also contributing to something meaningful.

On the backend, I have extensive experience with Java and Spring Boot. I've built REST APIs, microservices architectures, and integrated various AWS services. I follow clean code principles and design patterns like Repository, Service, and Controller to keep my code maintainable and testable.

I write unit tests with JUnit and Mockito, and I write integration tests for my APIs. I use Maven and Gradle for build management. I integrate SonarQube into my Java projects to track code coverage and catch issues early.

For databases, I have experience with PostgreSQL, MySQL, and NoSQL databases like DynamoDB. I understand how to design efficient schemas, write optimized queries, and ensure data integrity. I also have experience with database migrations and versioning.

I've been teaching React since before 2019, so I experienced the era of class components and lifecycle methods. After 2019, the shift to functional components and hooks, like useState and useEffect, brought a more streamlined, declarative approach. I've guided students through that transition—from class-based patterns to the modern, hook-based paradigm we rely on today.

I work with TypeScript for type safety. I build responsive and accessible user interfaces. I follow component-based architecture and understand state management patterns. I write unit tests for my React components.

I work closely with UX designers to implement features. I understand the importance of a good user experience and focus on delivering polished products. I've taught React to hundreds of students, which has deepened my understanding of the framework and its best practices.

I have solid experience with AWS, where I've designed and deployed robust cloud architectures. I've worked with services like EC2, S3, and Lambda, and I've automated infrastructure through IaC tools like CloudFormation and Terraform. This hands-on experience has given me a deep understanding of cloud-native development.

I hold four AWS certifications, including Solutions Architect Professional and DevOps Professional. But more than certifications, I have real-world experience building and deploying production applications on AWS.

I am also an AWS-Authorized Instructor. This is a restricted certification from Amazon—only qualified professionals who meet strict requirements can obtain it. I teach official AWS courses, which has deepened my understanding of the platform and best practices.

In my projects, I've used services like VPC, RDS, Elastic Beanstalk, SQS, SNS, and API Gateway. I set up CI/CD pipelines with CodePipeline and implement security best practices with IAM and KMS. I understand how to build secure, scalable, and cost-effective cloud architectures.

This experience with AWS aligns well with Sonar's cloud offerings. I understand how to deploy, monitor, and scale applications in the cloud, and I can contribute to building robust cloud-native solutions.

I am a strong team player. I believe that the best results come from collaboration, not isolation. When I work on a project, I make sure to communicate clearly with my teammates, share knowledge, and support others when they need help.

I understand that in a team, prioritization is essential. Even though I am a perfectionist by nature, I have learned that we cannot do everything at once. We need to focus on what brings the most value first. I always ask myself: what is the most important task right now? What will have the biggest impact?

I also believe in transparency. If I am stuck or if something is taking longer than expected, I communicate early. I don't wait until the last minute. This way, the team can adjust and we avoid surprises.

For me, being a good team player means putting the team's success above personal achievements. When the team wins, we all win.

One area I'm working on is my tendency to be a perfectionist. Sometimes I spend too much time trying to make something perfect when "good enough" would be acceptable. I've learned to balance quality with delivery. I now set clear deadlines for myself and focus on what truly matters.

Another thing I'm improving is delegation. In the past, I sometimes took on too much because I wanted to make sure everything was done correctly. I've learned that trusting my teammates and letting them take ownership is better for everyone. It helps the team grow and prevents burnout.

I can also be too direct in my communication. I value honesty, but I've learned to balance directness with diplomacy. I now take more time to consider how my words might be received, especially in written communication.

I see these as areas for continuous improvement. I'm aware of them, and I actively work on getting better every day.

Let me share how I would handle a difficult situation. Imagine a colleague goes on vacation and leaves some work unfinished. The deadline is approaching, and we need to deliver.

First, I would not call them during their vacation. Everyone deserves to disconnect and rest. Interrupting their time off would damage trust and morale.

Instead, I would assess the situation. What exactly needs to be done? Is there documentation? Can I understand the work from the code or notes they left behind?

Then, I would take ownership of the task. If it's within my capabilities, I would complete it myself or ask a teammate for help. The goal is to meet the deadline without creating stress for the person on vacation.

When my colleague returns, I would have a calm conversation. I would explain what happened, not to blame them, but to understand how we can prevent this in the future. Maybe we need better handoff processes. Maybe we need to plan better before vacations.

The key is to focus on solutions, not blame. We're all human, and things happen. What matters is how we handle them as a team.

You should hire me because I bring a rare combination of deep academic expertise and practical experience. I've built robust solutions, led teams, and taught future professionals, so I know how to both deliver results and empower others. I'll contribute not just with technical depth, but also with a commitment to quality and innovation.

I have the technical expertise you're looking for—over four years of Java experience, over three years of React and TypeScript, and deep AWS knowledge with certifications and teaching experience. I understand the full stack, from database design to user interface.

Beyond technical skills, I bring communication abilities that come from years of teaching. I can explain complex concepts clearly, mentor junior engineers, and collaborate effectively with cross-functional teams. I understand the importance of documentation and knowledge sharing.

I also bring a genuine passion for code quality. I don't just write code that works—I write code that is clean, maintainable, and well-tested. I've used SonarQube extensively, and I understand its value. I would be proud to contribute to a product that helps millions of developers write better code.

Finally, I am committed and reliable. When I take on a project, I see it through to completion. I take ownership of my work and hold myself to high standards. I'm ready to make a strong commitment to Sonar and contribute to the team's success.

I am genuinely impressed by SonarSource. In the era of artificial intelligence, where tools like Copilot and ChatGPT can generate code in seconds, the need for clean and secure code has never been more important.

AI can write code quickly, but it cannot fully replace human expertise when it comes to verifying quality and security. That's where Sonar comes in. Your tools help developers catch bugs, vulnerabilities, and code smells that AI might introduce. This is critical in today's fast-paced development environment.

I believe Sonar is positioned at the intersection of AI and human expertise. As more code is generated by AI, the demand for quality analysis will only grow. Sonar's mission to help developers write better code is more relevant than ever.

What also impresses me is your commitment to the developer community. Over 7 million developers trust your tools. Companies like Microsoft, NASA, and MasterCard use SonarQube. That's a remarkable achievement.

I want to be part of a company that is shaping the future of software development. Sonar is doing exactly that, and I would be honored to contribute.

Thank you for taking the time to learn about me. I'm genuinely excited about this opportunity to join Sonar and contribute to the Storefront team in Geneva.

I believe my skills, experience, and values align perfectly with what you're looking for. I bring technical depth in Java, React, and AWS. I bring teaching experience that translates into mentorship and clear communication. And I bring a genuine passion for code quality.

What excites me most is the opportunity to work on products that help millions of developers write better code. In a world where AI is changing how we develop software, Sonar's mission is more important than ever. I want to be part of that mission.

I am ready to make a strong commitment to Sonar. I am ready to learn, to contribute, and to grow with the company. I look forward to the next steps in the process.

Thank you again for this opportunity. I hope to speak with you soon.

Once, my colleagues and I disagreed about a project email that was sent out. They felt it wasn't clear, while I thought it was fine.

We sat down and discussed how it was interpreted. I listened carefully to their perspective. They explained that some phrases could be misunderstood by the client, and I realized they had a valid point.

I acknowledged their perspective, and we adjusted the wording together. Instead of insisting I was right, I focused on what would produce the best outcome for the team and the client.

The final version had a much better impact. The client responded positively, and the communication was clearer for everyone. It was a good reminder that collaboration always leads to better results than working in isolation.

What I learned from this experience is that being open to feedback is not a weakness — it's a strength. When we combine different perspectives, the result is always stronger.

Early in my career, around 2010, I was working on the backend for an HR module. A colleague on the frontend needed my API to finish his part. We had a demo the next morning.

I ran into an unexpected issue and delivered my part about 30 minutes later than planned. It was tight. My colleague had less time than expected to integrate, and he raised a concern about the timing.

The demo went well. But afterward, we had a good conversation. He explained that even a small delay can create pressure when people depend on each other. I appreciated his honesty.

That conversation stuck with me. Since then, I always build a buffer before deadlines and communicate early if anything takes longer than expected. Today, this kind of situation doesn't happen anymore. If I see any risk, I warn the team right away.

What I learned: good communication and planning prevent most problems. When people depend on your work, giving them a heads-up early makes all the difference.

I was working on a platform built with Java and Spring Boot. Some pages were only for paying users. If you didn't pay, the system should block you and say "access denied".

During testing, I noticed something wrong. I was able to access a paid page without paying. The door was supposed to be locked, but it let me in. That was a security problem.

I looked into it and found that the protection was only on the client side. It was easy to bypass — anyone with basic knowledge could skip it and access the paid content. The real security check on the server side was missing for that page.

I fixed it right away. I added the security check, made sure unpaid users are now blocked, and verified all other paid pages to make sure nothing else was open.

I also added automatic checks — so every time someone adds a new paid page, the system will verify it is properly protected. This way, the same mistake cannot happen again.

No user was impacted because I caught it before it went live.

What I learned: bugs happen, but what defines a senior engineer is how quickly you respond, how honestly you communicate, and what systems you put in place so it doesn't happen again.

As a supervisor, I was responsible for the database program in my department. Two professors who were supposed to work together on the same course had a disagreement. They had different views on how to teach the material, and they stopped collaborating. The program was stuck.

I decided to step in. I talked to each of them separately first. I listened. I wanted to understand what each person really cared about — not just the method, but the reason behind it.

One wanted to teach everything with PostgreSQL — he said it was modern and open source. The other preferred Oracle — he said it was the industry standard and students needed it for jobs. They couldn't agree on the course plan or the tools.

I brought them together and said: "You actually want the same thing — students who are strong in databases." I suggested we teach the core concepts first, then use PostgreSQL for one part and Oracle for another. Students would learn both. Each professor would lead the tool he knew best.

They both agreed. The course went well, students got the best of both approaches, and the two professors started trusting each other. They even collaborated on the next semester's material together.

What I took away from this experience: when facing a challenging situation, the key is to stay calm, listen to both sides, and find common ground. Most conflicts are not about who is right — they are about people caring about different things. A good mediator helps the team see that.

One thing I learned while preparing is that at Sonar, the People and Culture interview is extremely important. A candidate shared that he passed all the technical stages, finished the coding task, covered it with tests, and got positive feedback. But he was rejected after the People and Culture stage.

That tells me something clear: at Sonar, who you are matters as much as what you can code.

I respect that. I believe a strong team is not just about skills — it's about trust, communication, and shared values.

Here is how I see culture: I am someone who listens before speaking. I don't need to be the smartest person in the room. I want to be the person who makes the room work better together.

I value honesty. If I make a mistake, I say it. If I disagree, I say it respectfully. If a teammate needs help, I help — even if it's not my task.

I also believe in continuous learning. I teach, but I also learn from my students, from my colleagues, from every code review. Nobody knows everything, and that's okay.

Sonar's values — Smarter Together, Excellence, Innovation, and Delivery — are not just words on a wall for me. They describe how I already work every day.

I am ready to bring my energy, my humility, and my commitment to the Sonar team.

I want to join Sonar because I believe in what you do. I have used SonarQube in my own projects. I have seen how it catches problems early and helps teams write better code. I want to work on a product I already trust.

I also love the mission. In a world where AI generates more and more code, the need for quality and security analysis is growing fast. Sonar is at the center of that.

Beyond the product, I am drawn to the culture. Sonar values collaboration, excellence, and putting people first. That's how I like to work. I want to be somewhere I can grow, contribute, and be proud of what I build every day.

And honestly — I want to be part of a team that cares about clean code as much as I do.

Once, my colleagues and I disagreed about a project email that was sent out. They felt it wasn't clear. I thought it was fine.

We sat down and discussed how it was interpreted. I listened. They showed me that some sentences could confuse the client. I realized they had a good point.

I didn't insist. We adjusted the wording together. The final version was much clearer and the client responded positively.

What I learned: being open to feedback is not a weakness — it's a strength. When you combine different perspectives, the result is always better.

I think they would say three things about me.

First, that I am reliable. When I say I will do something, I do it. If there is a problem, I communicate early. People know they can count on me.

Second, that I am helpful. I don't just focus on my own tasks. If a colleague is stuck, I help — even if it's not my responsibility. I believe the team's success is more important than individual performance.

Third, that I am calm under pressure. When things go wrong — a bug in production, a tight deadline, a last-minute change — I stay focused. I don't panic. I find the solution first and discuss the process after.

And if I'm being honest, they would probably also say I can be a bit of a perfectionist. But I've learned to balance that — deliver first, improve after.

— What does career growth look like for engineers at Sonar?

— What do people enjoy the most about working at Sonar?

— Does the team do any team building activities or events to connect outside of work?