My SAP Final Interview (And Why I Didn’t Get the Offer)

Applied for SAP's Software Engineer (CI/CD Application) role, made it to the final HR round, got rejected. Notes on what I think went wrong, mostly for myself; maybe useful if you're prepping for a similar role.

Interview Process Summary

The entire interview process consisted of 3 main stages:

• Phone Screening: JD-based interview, checking understanding of CI/CD role and objectives
• PT + Technical Interview: Presented 'Financial Chatbot' project in English, Frontend questions were fine but showed some gaps in Python/AI deep-dive questions

Interview schedule notification email from SAP

Presentation materials used in PT interview (Project Overview)

• HR Interview: Multi-person interview with smooth communication, but final result was rejection

Analysis of Rejection Reasons (My Hypotheses)

After reflecting on the interview, I came up with several hypotheses:

Hypothesis 1: Insufficient Application Technical Depth

CI/CD engineers ultimately need to understand the applications they deploy, and I may have been insufficient in explaining Python/AI principles or trade-offs. For example, I couldn't clearly answer questions like Why did you choose this model? or What's the trade-off between memory usage and accuracy?

Hypothesis 2: Lack of DevOps Perspective Connection

I failed to explain my project from the perspective of Dockerize → CI (test/build automation) → CD (stable deployment). Instead of just saying I made a project, I should have emphasized how I deployed it and what pipeline I built.

Hypothesis 3: Relative Competitiveness

Compared to other candidates, my direct CI/CD experience may have been insufficient in frequency or depth. Perhaps experience in actual production environments was more important than hackathon or toy project-level experience.

Future Plans

Plans to address the gaps that became clear through this experience:

Strengthening Python & AI Fundamentals

I plan to understand internal mechanisms and architecture-level details to secure technical depth. Beyond simply using libraries, I need to be able to explain why I chose that library and what trade-offs exist.

Making DevOps Perspective Reflection a Habit

I will develop a habit of designing and documenting E2E pipelines with Dockerfile and GitHub Actions workflows, even for toy projects. Instead of just it works, I need to be able to explain why I designed it this way.

Conclusion

Looking back, the gaps were clearer than I expected. The interviewers kept asking _how_ I deployed things, not _what_ I built, and my answers were too vague. Next time, even for a side project, I want to have a full pipeline (Docker → CI → CD) ready to walk through concretely.