Saaf Finance interview questions

**Interview Experience with Saaf Finance — DO NOT DO THE ASSIGNMENT for this company** I’m sharing my experience interviewing with Saaf Finance so other engineers understand what they may be signing up for before investing serious time and effort. My interview process stretched across multiple rounds and ultimately ended in complete silence after significant unpaid work. --- ### • Round 1 – HR Screening The process began with an HR discussion that felt largely unprepared. Basic questions were asked, but the HR representative seemed to have zero clarity about the actual role, responsibilities, or expectations. Most questions about day-to-day work or technical scope could not be answered clearly, which was the first sign of misalignment. --- ### • Round 2 – Technical Interview (with Ritvik Singh) This round briefly touched on backend and system design concepts. However, the interaction felt rushed. There was minimal interest in my past experience, projects, or engineering decisions I had worked on previously. The primary focus appeared to be quickly assigning a take-home task rather than evaluating candidate fit. The interview concluded rapidly, and I was immediately given a take-home assignment related to designing a **loan underwriting processing workflow**. During this discussion, it became clear that the expectation was not just conceptual design — I was encouraged to build a **working prototype involving agents**, essentially a functional implementation rather than an interview exercise which they can use within the company. They never asled my current salary, didnt check my expectation, because they are not taking interviews to hire people, they take interviews to steal ideas from enginner and try to execute themselves. --- ### • Take-Home Assignment The assignment required substantial effort. This was not a short coding task — it involved: * Understanding a complex financial domain * Designing system architecture and workflows * Implementing logic * Thinking through scalability and production trade-offs * Preparing detailed explanations of decisions At this point, the scope felt closer to building a reusable product boilerplate than completing a candidate evaluation exercise. --- ### • Decision to Decline Building a Full Prototype Before proceeding further, I came across similar interview experiences shared online by other candidates describing ghosting after deep assignment discussions. Given the expectation to build a working prototype and fully explain implementation details, I became uncomfortable continuing at that level of effort without hiring clarity or safeguards around how the work would be used. I therefore **politely declined to build a full production-style prototype** and limited my participation to conceptual discussion. --- ### • Assignment Deep Dive Discussion I still had a follow-up discussion where I walked through my approach — architecture choices, trade-offs, implementation reasoning, and possible production improvements. The conversation felt less like an evaluation and more like a detailed walkthrough of how such a system could be built and improved in practice. --- ### What Happened Next After investing significant time and effort: **Complete silence.** No feedback. No rejection. No closure. Multiple follow-ups went unanswered, and the role continued to remain open afterward. --- ### Why this was frustrating * Candidates are expected to invest serious unpaid effort. * Discussions go deep into production-level system thinking. * Communication stops entirely afterward. * Basic professional courtesy — even a rejection email — was missing. Regardless of hiring decisions, candidates deserve transparency and closure after committing this level of effort. --- ### Advice to Engineers dont do the assignement, they will fake commit that they will reply in couple of days, but they never do. Personally, I would strongly reconsider committing significant time to the assignment stage. Sharing this so other engineers can make an informed decision before investing their time.