Rafael El Shafie

The problem

I worked on technology support for the onboarding area, which helps operations open accounts and update customer records. Part of the tickets we received were usage questions or operational guidance that did not require a technical fix. The goal was to bring documentation, guidance and authorized information together in a conversation, so operations could clear up questions before opening a ticket and support could focus on the cases that needed investigation.

My responsibility

When I joined, there was the idea for the solution. I led the development end to end, with guidance from my manager: understanding the domain, the knowledge base, architecture, backend, interface, AI and database integration, testing, observability and deployment. Later, another intern joined the project, and I helped guide her and organize our work together.

Decisions that made a difference

• I started with a base of Markdown documents instead of an external vector database, to focus the first delivery on structuring the knowledge and getting the application working within the deadline.
• When tests showed that context limits were hurting quality, and usage showed room in the budget, I added a step in which the language model selects the relevant sources among the keyword-search candidates. It was one of the project's main breakthroughs.
• I tested handing more processing steps to the AI: cost went up and quality went down. I kept a combination of application logic, structured queries and language generation, according to what each step needed.
• For recurring queries, I built parameterized SQL templates instead of generating a new query for every question, with read-only execution on operational databases.

What I delivered

• A standardized knowledge base with categories, metadata and cross-references, plus consistency checks to catch broken references, duplicates and gaps.
• A chat with history, structured feedback and progressively displayed answers, plus admin dashboards, usage tracking and knowledge review.
• Corporate authentication, access control, care with sensitive information in logs, AI usage limits and Datadog observability for each step.
• Backend, interface and integration tests, reference question sets to evaluate answers, and delivery with Docker, Kubernetes and Azure DevOps, from development to production.

Outcome

In an internal set of test cases, the changes to document selection and context composition substantially increased both the questions answered and the correct answers. The support team validated the assistant with everyday situations, and it was delivered to production. I followed its early adoption by operations until the end of my internship; reducing avoidable tickets remains the solution's goal.

What I learned

The quality of an AI solution depends on the decisions around the model: what information it receives, how data is queried, how context is preserved and how results are evaluated. I also learned to document decisions and organize the work so others could contribute to the same repository.

Technologies

• Python
• FastAPI
• React
• TypeScript
• PostgreSQL
• MySQL
• RAG
• Text-to-SQL
• Docker
• Kubernetes
• Azure DevOps
• Datadog

Projects from this experience

The technical view, with architecture and technologies, is in the details of each project.

• Atlas

The request

Property research in Manhattan was done by hand across different portals, comparing listings, features and prices. The goal was to bring this information together into an organized view that made the data easier to explore and flagged relevant situations, such as new high-scoring listings, price differences and changes in availability.

My contribution and working in a pair

I built the project with another intern, guided by the team. Data ingestion already existed, along with a draft of the processing layer: we rebuilt most of that layer and developed the analysis preparation, the business rules and the solution's outputs. We worked side by side, splitting tasks by each one's knowledge and interests and making decisions together. My most individual responsibility was the dashboard: I built it in Databricks, drawing on the design of an existing dashboard and adding several features. Later, a colleague carried what I had built over to the bank's own visualization tool.

Decisions that made a difference

• Focus the sources: of the three portals we evaluated, we kept Zillow and StreetEasy, because the third one carried information less suited to the scope and hurt the filters.
• Adjust the scope: we narrowed the property categories to what the requester was interested in, keeping the focus on Manhattan.
• Reconcile without losing reliability: one source filled in the other where possible, conflicts followed a priority rule and records without enough quality were left out of the analysis.
• Track changes: we kept previous records to spot properties that left a source and were listed again, mainly comparing prices.

Outcome

We presented the project in English to its requester, using the dashboard to show how it worked and what it found. The presentation was praised, and the positive feedback also reached our managers. The delivery brought together information previously looked up in different sources and made comparisons easier. I did not follow the project after the internship ended.

What I learned

I strengthened my Python and SQL and got hands-on experience with Spark and Databricks, the Medallion architecture, AWS resources and a messaging-based notification flow. I learned that more data does not always mean better analysis: we had to choose sources, adjust the scope and handle conflicts to reach a coherent view. Working in a pair and presenting in English strengthened my ability to discuss decisions and to explain a technical solution through its value to the business.

Technologies

• Python
• SQL
• Apache Spark
• Pandas
• Databricks
• AWS
• RabbitMQ
• Scrum

Projects from this experience

The technical view, with architecture and technologies, is in the details of each project.

• Manhattan Real Estate

Learning by building as a team

I joined in January 2024 and started with the junior enterprise's training program. The final assignment was a management application built as a team: I contributed to different parts of the backend, with Node.js, TypeScript, NestJS, PostgreSQL and Prisma. It was my first experience building software together with others and learning how a backend application is organized. The project was completed as a training activity, around March, and was never used in operation.

Consulting: understanding the routine before modeling

After training, I started working as a Project Consultant. In a project for a food manufacturer, the management system had grown piece by piece and piled up features that were no longer used. I took part in factory visits, interviews and meetings with employees: I prepared questions, recorded answers and contributed to mapping the processes. From there, the team built the documentation and the data model from scratch, and I took part in each stage. Another company took on the implementation of the new system.

The technology area from the inside

I joined a working group, organized around an OKR, to discuss improvements to Fluxo's technology area, analyzing bottlenecks and strengths and listening to other members. Its outcomes included reorganizing the split between backend and frontend toward full stack work, while keeping a dedicated design track, and supporting technical training with Full Cycle courses. It broadened my view of how the way people and learning are organized shapes what a team can build.

Administrative and financial routines

In the Administration and Finance department, I supported and carried out accounts payable tasks, including reimbursements, and bank reconciliation, with daily meetings to track progress and plan next steps. I used tools such as Conta Azul, Asaas, Podio, Caju and Google Sheets. It was my first contact with the routines that keep an organization running.

Recruiting and mentoring

I took part in recruiting interviews and group exercises, asking questions, observing candidates and taking notes based on interview guides and evaluation sheets. Later, I started mentoring new trainees, answering questions about their tasks and the company and reviewing their work: a way to pass on what I had learned in my own training.

What I took from it

Over eight months, with fronts that often ran at the same time, I brought together software development, user needs, internal processes and collaboration. The training backend was my first team build; the manufacturer project showed me why you investigate the routine before defining a system; and the internal work widened my exposure to different responsibilities within an organization.

Technologies

• Node.js
• TypeScript
• NestJS
• PostgreSQL
• Prisma
• Git
• Scrum
• Kanban

Projects from this experience

The technical view, with architecture and technologies, is in the details of each project.

• Industrial system modeling
• Management system backend