What I Learned from My Software Engineering Internships
By Kisho Jeyapragash
My internships gave me practical experience across backend services, frontend applications and database-driven workflows. At SoftwarePlus (Pvt) Ltd, I worked as an AI-Enabled Software Engineer Intern from June to December 2025. At Jepsoft, I worked as a Software Engineering Intern from September 2025 to March 2026. The roles overlapped in dates and exposed me to different application stacks.
Connecting services to the screens that use them
At SoftwarePlus, I developed FastAPI backend services and worked on React and Next.js interfaces for government information and citizen-service applications, including Smart Citizen LK. I used PostgreSQL and MongoDB and worked on OpenAI and Gemini API integrations. Seeing both the API and the interface made the request and response contract a practical concern.
An endpoint is only one part of a user workflow. The screen also needs to know how to submit valid data, show an error and display the returned result. That connection is why I pay attention to API shape alongside backend implementation.
Working across PHP and JavaScript applications
At Jepsoft, I developed backend features with PHP, Laravel and CodeIgniter and worked with React and Next.js frontends. My work included REST API development and integration, database-driven application workflows, responsive UI improvements, testing and debugging. The projects included Premium Rent & Ride, EV Circle, YM Trading Japan and Carbon Ceylon.
The frameworks differed, but the application questions were familiar: where is data validated, which layer owns a rule, and what should the interface do when a request fails? I could apply those questions across both Python and PHP services rather than rely on one framework's conventions alone.
Debugging across a request boundary
- Check what the interface actually sends.
- Check the API validation and returned status.
- Check the database operation and the data the API reads back.
- Check how the frontend handles loading, success and error states.
Working within an existing application
Responsive design and UI improvements at Jepsoft also involved preserving existing behaviour while making screens clearer. I carry the same principle into my portfolio and personal projects: understand the existing flow before changing it, then check the parts that depend on the change. That applies to a form as much as it applies to a backend endpoint.
Two stacks, similar engineering questions
At SoftwarePlus, my work covered backend APIs, full-stack applications and AI integrations. At Jepsoft, I worked across PHP-based backends and JavaScript frontends. I value that range because it makes the application workflow the common reference point. A request still needs understandable input, an appropriate access decision, a database operation and a result that the frontend can present, whether the implementation uses FastAPI or Laravel.
My SoftwarePlus work included government information and citizen-service applications, including the Government Information Service System and Smart Citizen LK. At Jepsoft, the projects included Premium Rent & Ride, EV Circle, YM Trading Japan and Carbon Ceylon. These names provide the context for my experience; I do not attribute an entire company product or an unsupported business result to an internship description.
An API is used by a screen, not only an HTTP client
Working with React and Next.js alongside backend services gave me a practical reason to care about response structure. An interface needs a loading state while a request is running, a usable success result and a clear failure message. If an endpoint returns a field in an unexpected form, the problem can appear in the browser even though the backend request itself completed.
I now approach a form and its endpoint as one interaction with separate responsibilities. The frontend helps the person enter data and understand feedback. The backend validates the actual request and applies the application rule. A database write is not the end of that flow: the returned representation must let the interface display what was saved. This is an engineering principle I take from full-stack work, rather than an invented story about one workplace bug.
Database-driven work makes relationships visible
I used PostgreSQL and MongoDB in my SoftwarePlus work, and worked on database-driven application development at Jepsoft. That experience keeps me attentive to the difference between an interface field and an application relationship. A form may display a name, but the backend may need an identifier that refers to an existing record. The API contract needs to make that distinction clear.
When I describe a database-driven workflow, I ask which record changes and which later reads depend on that change. This is also useful during debugging. If the interface displays stale information, checking the returned response and the subsequent read can be more informative than changing the rendering code immediately. The purpose is to locate the boundary where the observed behavior stops matching the expected workflow.
AI integration still has ordinary software responsibilities
My SoftwarePlus experience included OpenAI and Gemini API integrations. Calling a model does not remove the need for request validation, application context or understandable error handling. I treat an AI service as a dependency with a specific responsibility, while the application continues to own its users, data and workflow. My personal reporting and automation projects give me additional examples of that separation.
For another developer, the useful question is what should happen if the integration does not return a usable answer. A screen should be able to explain that state. A stored application record should not be confused with generated text. These are the same kinds of integration questions that arise with other external services, even when the output from a model is less predictable than an ordinary API response.
Responsive UI work is part of the interaction contract
At Jepsoft, I worked on UI improvements and responsive design as well as backend development, API integration, testing and debugging. A responsive screen needs more than narrower styling. Inputs must remain understandable, feedback must stay near the action it describes, and a person must be able to reach the controls at a smaller viewport. Those concerns connect visual work with the behavior of the application.
I carry a practical sequence into my own work: identify the existing flow, make the change, then check the affected request and interface states. That helps me preserve working behavior while changing a form or service. It also makes my explanation of the change clearer: what the user can do, what the backend accepts, and what evidence shows the interaction behaves as expected.
The experience I bring to the next application
The common lesson across these internships is connecting layers rather than treating them as independent deliverables. I have hands-on experience developing APIs, integrating frontends, working with databases and adding AI-assisted functionality. I can explain those responsibilities in concrete terms without claiming workplace incidents or numerical outcomes that I have not documented. That is the experience I bring to backend and full-stack engineering work.