Entry-Level Data Engineer

Srikanth

SQL · Python · PostgreSQL · FastAPI

Building hands-on data engineering projects with SQL, Python, PostgreSQL, FastAPI, and cloud-ready pipeline design.

I'm focused on becoming job-ready for data engineering internships and junior data roles by building real projects, improving my fundamentals, and documenting my progress.

View projects GitHub LinkedIn
About

Early in my career, and serious about the work.

I'm an entry-level data engineering candidate based in Rockville, Maryland, with a Master's in Information Technology from Wilmington University.

My current focus is building strong foundations in SQL, Python, PostgreSQL, data modeling, backend APIs, ETL concepts, and data pipeline design. Since I'm early in my career, I'm using hands-on projects to build real proof of skill instead of only relying on tutorials.

I'm currently building a portfolio around production-style data systems — including event-driven ingestion, API development, database design, validation, duplicate handling, analytics, and future cloud deployment.

I'm open to Data Engineering Intern, Junior Data Engineer, ETL, Data Analyst, and Analytics Engineering opportunities where I can contribute, learn quickly, and grow.

Skills

What I work with — and what I'm learning next.

Grouped honestly: the tools I'm actively building with, and the stack I'm currently learning toward.

Programming & Querying

SQLPython

Databases & Modeling

PostgreSQLRelational DesignData ModelingIndexesConstraintsData Validation

Backend & APIs

FastAPIREST APIsSQLAlchemyPydanticEnv Config

Data Engineering Concepts

ETL / ELTData IngestionData QualityDeduplicationRaw vs ProcessedEvent-DrivenBatch Processing

Tools

GitGitHubVS CodePostman / SwaggerCommand Line

Learning Next

Currently learning
DockerCloud DeploymentAirflowdbtSnowflake / BigQueryAzure / AWS
Projects

Three projects, three domains — one engineering approach.

A flagship pipeline being built now, plus two data platforms in design across local commerce and healthcare. I’m building them one at a time — starting with a defensible MVP rather than all at once.

01 / flagship

DriveLingo AI

In progress · building
Traffic Sign Intelligence · Event-Driven Backend Pipeline

A traffic sign intelligence pipeline that processes traffic sign images and metadata through raw ingestion, validation, PostgreSQL storage, and duplicate handling — designed so future OCR, translation, and driver-alert workflows can build on the same foundation. The database separates raw ingestion events from processed records, so data can be reprocessed later with better models.

What I've built
  • FastAPI backend with GET / POST endpoints
  • PostgreSQL + SQLAlchemy models
  • Pydantic schema validation
  • 404 + 409 duplicate handling
  • Unique index + IntegrityError rollback
  • .env-based config & raw ingestion table
What I learned

Duplicate protection can't live only in the API — the database has to enforce it too, with constraints and unique indexes as the final safety layer. Separating raw ingestion from processed records is what keeps a pipeline reprocessable instead of locked to one model.

Planned next
  • Image upload endpoint
  • OCR + language detection
  • Translation + driver alerts
  • Docker + cloud deployment
PythonFastAPIPostgreSQLSQLAlchemyPydanticSQLGit
View repo
// pipeline
01traffic_sign_eventsraw ingestion table
02validatePydantic + duplicate checks
03PostgreSQLconstraints + unique index
04OCR / translateplanned
05driver alertsplanned
02 / local commerce

LocalLoop

In design · planned
Local Vendor Intelligence · Event-Driven Analytics Pipeline

An event-driven data platform that captures anonymous NFC / QR interactions between households and local service vendors — plumbers, electricians, AC technicians, tiffin services — then validates, transforms, and analyzes them into vendor-retention, service-category, and locality-level metrics. Customer data stays private; vendors see only aggregated, anonymous insights.

Planned scope
  • Ingest raw NFC / QR tap & save events
  • Validate & deduplicate interaction events
  • Separate raw, cleaned & analytics-ready layers
  • Model vendors, localities, events & metrics in PostgreSQL
  • Build vendor-retention & repeat-business analytics
  • Serve aggregated metrics via FastAPI
Privacy-first by design

Customer identities are never exposed — vendors see only aggregated metrics like profile taps, saves, repeat-interaction rate, and locality trends. Questions it answers: which categories and localities see the most repeat activity, what share of saves lead to repeat service, and which vendors grow month over month.

PythonSQLPostgreSQLFastAPISQLAlchemyPandasdbtAirflowDockerGit
Repo coming soon
// pipeline
01NFC / QR tapraw interaction events
02validate + dedupclean tap & save events
03PostgreSQLoperational storage
04ETL / transformdbt · analytics model
05metrics + APIretention · locality · FastAPI
03 / healthcare

MedSignal

In design · planned
Drug Safety & Adverse Event Analytics · API Ingestion Pipeline

A drug-safety pipeline that ingests public adverse-event reports from the FDA’s openFDA API, stores raw responses separately from cleaned records, and analyzes which drugs and reactions appear most often. It’s built entirely on de-identified, publicly reported data — no patient records — reflecting the privacy-first mindset healthcare data work requires.

Planned scope
  • Ingest reports from the openFDA REST API
  • Handle pagination & rate limits
  • Store raw JSON separately from cleaned data
  • Normalize drug, reaction & outcome fields
  • Validate missing fields, duplicates & dates
  • Model & analyze top reactions and trends
Why it’s strong

It adds external-API ingestion — pagination, rate limits, and nested JSON — which the other two projects don’t cover, and it’s built on de-identified public data, showing the privacy-awareness healthcare teams value. Questions it answers: which reactions are most reported for a drug, how report volumes shift over time, and which outcomes appear most often.

PythonSQLPostgreSQLRequestsPandasJSONGit
Repo coming soon
// pipeline
01openFDA APIpublic adverse-event reports
02Python ingestraw JSON · pagination
03parse + normalizedrugs · reactions
04validatefields · duplicates · dates
05analytics modelPostgreSQL + SQL
Learning journey

Building in public, one small lesson at a time.

A running log of what I'm learning as I build. Small lessons, but they're what turn tutorials into real understanding.

Lesson 01

Raw vs. processed data

In DriveLingo AI, raw traffic sign events are stored before any OCR or translation runs, so they can be reprocessed later with a better model, checked for errors, or reused for analytics.

Raw = what the system received. Processed = what the system understood.
Lesson 02

Git feature branches

Instead of committing every change to main, I built the ingestion layer on its own branch. It made me understand why teams keep stable code separate from work in progress.

main = stable version. feature branch = safe workspace for new changes.
Lesson 03

Duplicate protection, two layers

I added logic so the same traffic sign record can't be inserted repeatedly — and learned that this can't live only in the API. The database has to enforce it too.

App validation is useful. Database constraints are the final safety layer.
Lesson 04

Environment variables

Instead of hardcoding the database URL in Python, I moved it into a .env file. Cleaner code, and much easier to move between local development and future deployment.

Code stays reusable. Environment-specific settings live outside the code.
Lesson 05

Request-based vs. event-based

A request-based system waits for an action and returns a response. An event-based system stores what happened so different services can process it later — which is where DriveLingo is heading with camera and dashcam input.

The long-term goal isn't manual upload — it's a pipeline that handles traffic sign events.
This week

Progress check

FastAPI backend, PostgreSQL schema design, duplicate handling, environment config, Git feature branches, and raw event ingestion. Still early, but building a real project step by step is showing me how data actually moves through a system.

Next focus: image ingestion, OCR pipeline, and stronger SQL practice.
Resume

The short version, on one page.

Entry-Level Data Engineer · SQL · Python · PostgreSQL

Entry-level data engineering candidate with a Master's in Information Technology and hands-on project experience building SQL, Python, PostgreSQL, and FastAPI-based data systems. Focused on data ingestion, validation, data modeling, duplicate handling, API development, and analytics-ready database design. Seeking Data Engineering Internship, Junior Data Engineer, ETL, Analytics Engineering, or Data Analyst opportunities.

Download résumé (PDF)
Skills
Languages: SQL, Python · Databases: PostgreSQL, relational design, indexes, constraints · Backend: FastAPI, SQLAlchemy, Pydantic, REST · Data Eng: ETL/ELT, ingestion, validation, deduplication, event-driven pipelines · Tools: Git, GitHub, VS Code, Swagger
Currently learning
Docker · Cloud deployment · Airflow · dbt
Education
M.S. Information Technology — Wilmington University, graduated May 2025
Contact
srikanthdatadc@gmail.com · Rockville, MD · linkedin.com/in/srikanth-b-094646421 · github.com/srikanthbattula9
Contact

Let's talk data engineering.

I'm open to Data Engineering Intern, Junior Data Engineer, ETL, Data Analyst, and Analytics Engineering roles — and always happy to connect and learn from people working in the field.

srikanthdatadc@gmail.com LinkedIn GitHub