Recruitment Stories - Rasel's Experience at Optimizely

Rasel Hasan is currently a Demo Engineer II at Optimizely, where he works on the presales team, turning customer problems into technical demonstrations. He earned his BSc in Computer Science and Engineering from Sylhet Engineering College and has more than three years of industry experience building scalable web applications.

Before joining Optimizely, Rasel worked at Vivasoft Ltd., where he contributed to AI-powered products. His most recent major project was Novara, an AI-driven recruitment platform. Outside of work, he writes technical articles on frontend security, JavaScript internals, and agentic AI.

Rasel applied for the role through a referral.

The hiring process consisted of four rounds: a recruiter screening, a combined behavioral and technical conversation, a take-home assignment, and a final demo and defense session. One theme ran through all four rounds: how he actually works with AI tools in his day-to-day engineering workflow.

Phase 1: Recruiter Screening

The first call was a short conversation with the talent acquisition team. It began with an overview of the role and the company, followed by a brief introduction from Rasel.

What surprised him was where the discussion went next. Much of the call focused on how he used AI in his engineering work. The recruiter was looking for grounded, specific examples rather than general familiarity with AI tools.

To prepare, Rasel reviewed the job description closely and made sure he could describe his day-to-day workflow concretely. His advice is to treat AI fluency as part of modern engineering practice and be prepared to discuss it from the very first call.

Phase 2: Behavioral and Technical Conversation

The second round was a longer conversation that opened with the team’s mission and what the role looked like in practice before moving into Rasel’s background.

The discussion covered his career path, how he works within Agile teams, his approach to code review, and challenges he had faced on previous projects. Throughout the conversation, the interviewer repeatedly returned to how AI appeared across his software development lifecycle, how he evaluated its output, and how his usage of AI had evolved over time.

The conversation became particularly detailed when Rasel discussed Novara. Having shipped AI features to production rather than simply prototyping them gave him concrete experiences to draw from, particularly when discussing technical trade-offs and how to present AI-generated output to users without overpromising.

For preparation, Rasel recommends having two or three real situations ready where AI changed the way he approached a problem, along with the trade-offs involved. Although the questions may sound conversational, the answers need to be specific and grounded in actual experience.

Phase 3: Take-Home Assignment

The third round involved a frontend take-home assignment with defined business requirements and constraints. What made the round unusual was that AI tooling was not merely permitted; it was expected to play a central role in completing the assignment.

Rasel first scoped the problem, broke it down into milestones, and then used Claude for code generation, refactoring, and reasoning through architectural decisions. He also used Google Stitch for the design layer.

He found that treating AI as a thinking partner produced much better results than asking it to generate an entire feature in a single attempt. After completing the project, he deployed it and submitted it within the deadline.

His advice for this round is to treat a take-home assignment like production work: scope it, plan it, version it, and deploy it. Heavy AI usage does not mean offloading the thinking. The judgment involved in deciding what to accept, modify, or reject is an important part of the process and may itself be assessed.

Phase 4: Final Demo and Defense

The final round was a live walkthrough of the take-home assignment in front of a panel. Rasel presented the project in much the same way he would present a product to a customer.

The panel explored how he planned the solution, which architectural decisions he made and which alternatives he ruled out, the technical and design trade-offs he accepted, the rough edges he was aware of, and how AI factored into each stage of the development process.

Rather than trying to hide the project’s gaps or known issues, Rasel chose to acknowledge them directly. He believes this is a better approach because being transparent about a bug and explaining how it could be addressed demonstrates stronger judgment than attempting to conceal it.

To prepare for a similar round, he recommends being honest about the limitations of the solution and being ready to explain how those limitations could be addressed. He also suggests preparing substantive questions for the end of the interview, such as asking what the most challenging part of the role is.

Overall, Rasel’s interview experience highlighted that technical ability alone was not the only focus of the process. His ability to reason about engineering decisions, communicate trade-offs, work effectively with AI tools, and take ownership of the final outcome played an important role throughout the four rounds.

Special thanks to Rasel Hasan for taking out the time to share his recruitment experience with me. If you have any queries, feel free to contact him at raselhasan.cse11@gmail.com