Praduman Prajapati
DevOps Engineer
Python
Node JS
Java
Bash
Reliability & Observability: 6/10
API Design: 5/10
Data Layer & Database: 5/10
Active 16 days ago
Invite to interview
Download CVCV
Overview
Technical skills
Timeline
Roles
Overview
Backend / API engineer (mid-level) focused on building REST APIs and background processing with a strength in pragmatic system reliability patterns. The strongest proven skill is designing reliable API + worker pipelines with health/readiness checks, connection pooling and graceful shutdown as shown in hotreloads/api/main.py and hotreloads/worker/worker.py. There is limited evidence of formal schema migration history, advanced API versioning/idempotency strategies, or production-grade rate limiting and caching strategies in public code.
Phone
Technical skills
Languages
4
Python
Node JS
Java
Bash
Node JS
6
Axios
Express
Mongoose
Bcrypt
Nodemailer
Dotenv
Python
3
FastAPI
Pydantic
Uvicorn
DevOps
14
Kubernetes
Grafana
AWS
Azure AKS
Prometheus
ArgoCD
Helm
Azure
GitHub Actions
Amazon S3
Amazon EC2
Amazon EKS
GitHub
Terraform
Frontend
6
React.js
Tailwind CSS
Redux Toolkit
React Router
Bootstrap
Vite
Cybersecurity
4
SonarQube
Trivy
Gitleaks
OWASP Dependency-Check
Other
18
Docker
Nginx
Docker Compose
Ansible
CI/CD
Jenkins
Loki
IaC
Containers
minikube
Calico
cert-manager
GitOps
Harbor
IAM
kubeadm
Shift-Left
Shift-Left Security
Timeline
DevOps Engineer
•
Middle
Osfin.ai
•
Full-Time
Owned production Kubernetes infrastructure and cloud-native application deployments, focusing on reliability and uptime. Built and maintained CI/CD and GitOps delivery workflows using GitHub Actions, ArgoCD, Helm, and Terraform. Operated full-stack observability with Prometheus, Grafana, and related tooling, and supported incident response by improving alerting and diagnostic visibility.
Kubernetes
GitHub Actions
ArgoCD
Helm
Terraform
Prometheus
Grafana
DevOps Engineer
•
Middle
LumayAI
•
Full-Time
Improved production resilience by implementing Kubernetes autoscaling strategies and tuning workloads for stability. Secured CI/CD pipelines by adding static analysis and vulnerability scanning gates using SonarQube, Trivy, OWASP Dependency Check, and Gitleaks. Built and operated monitoring, logging, and alerting using Prometheus and Grafana, and ran GitOps deployments on Azure Kubernetes Service using ArgoCD and Helm.
Kubernetes
SonarQube
Trivy
OWASP Dependency-Check
Gitleaks
Prometheus
Grafana
ArgoCD
Helm
Azure AKS
KIET Group of Institutions
Bachelor's Degree •
Computer Science & Engineering (AI/ML)
Senior Backend Developer
Confidence: Medium API Engineer
Backend / API engineer (mid-level) focused on building REST APIs and background processing with a strength in pragmatic system reliability patterns. The strongest proven skill is designing reliable API + worker pipelines with health/readiness checks, connection pooling and graceful shutdown as shown in hotreloads/api/main.py and hotreloads/worker/worker.py. There is limited evidence of formal schema migration history, advanced API versioning/idempotency strategies, or production-grade rate limiting and caching strategies in public code.
API Design
5/10
How well APIs are designed
API design shows solid, pragmatic REST endpoints with health/readiness checks and pydantic models, but lacks a formal versioning strategy, idempotency keys, or advanced pagination patterns.
Evidence
hotreloads/api/main.py: FastAPI endpoints with pydantic response models and startup logic
StudyNotion/backend/controllers/course.js: custom controller patterns for course CRUD and detail endpoints
StudyNotion/frontend/src/services/operations/courseDetailsAPI.js: client-side usage of a consistent apiConnector to call backend endpoints
Data Layer & Database
5/10
Working with databases
Data layer demonstrates correct use of connection pooling, SQL schema initialization, and Mongoose population usage, but there is no migration history or explicit transaction/isolation-level handling.
Evidence
hotreloads/api/db.py: SimpleConnectionPool usage, init_schema with CREATE TABLE IF NOT EXISTS
hotreloads/worker/db.py: connection pool and specific UPDATE/SELECT statements for job lifecycle
StudyNotion/backend/controllers/course.js: Mongoose .find/.populate usage and multiple model updates (findByIdAndUpdate, create)
Scalability & Performance
5/10
Handling load and speed
Scalability and performance decisions are present (Redis queue, Postgres pooling, background worker), but caching, measured optimizations and rate-limiting are not implemented.
Evidence
hotreloads/worker/worker.py: Redis BRPOP queue consumer and cross-replica metric via redis_client.set
hotreloads/api/db.py: connection retry loop to tolerate Postgres startup
hotreloads/worker/db.py: SimpleConnectionPool configuration and controlled pool sizes
System Architecture
5/10
Overall system structure
System decomposition (web portal, API, DB, queue, worker) and liveness/readiness/heartbeat separation are well thought-out, but service boundaries lack documented contracts and there is limited evidence of multi-service orchestration beyond local choices.
Evidence
hotreloads/README.md: architecture diagram and design decisions describing Web -> API -> Queue -> Worker
hotreloads/api/main.py: clear separation of API responsibilities and startup checks
hotreloads/worker/worker.py: dedicated worker process with graceful shutdown and heartbeat file
Security & Auth
4/10
Protecting data and access
Security basics are implemented (JWT, bcrypt, OTP, payment signature verification, httpOnly cookie), but broader hardening (rate limiting, input schema enforcement across all endpoints, secret rotation guidance) is not fully evident.
Evidence
StudyNotion/backend/controllers/auth.js: JWT issuance, bcrypt password hashing, OTP validation and cookie configuration
StudyNotion/backend/controllers/payments.js: Razorpay signature verification using HMAC with environment secret
backend/package.json: presence of dotenv and bcrypt dependencies (environment and password handling)
Reliability & Observability
6/10
Stability and monitoring
Reliability and observability are strong for a small system: structured JSON logging, liveness/readiness endpoints, DB connection retries, worker heartbeats and graceful shutdown handling are implemented together with a smoke test.
Evidence
hotreloads/worker/worker.py: JSON-formatted logging, SIGTERM/SIGINT handlers, heartbeat file for liveness
hotreloads/api/main.py: /health/ready implementing db and queue checks with HTTPException on failure
hotreloads/scripts/smoke_test.py: an automated smoke test that exercises the end-to-end flow
Expertise
Microservices & API Architecture• Middle
Node.js• Middle
Python• Middle
Messaging & Real-time• Middle
Industries
Education• Middle
Technologies
Node JS• Senior
Express
FastAPI
Bcrypt
Mongoose
Axios
Dotenv
Nodemailer
Recommendations
- Use to build and harden REST APIs with background workers and queue-based job processing (implementing health/readiness, graceful shutdown and DB pooling).
- Deliver EdTech backends (course management, payments, user auth) and integration of third-party services (Cloudinary, payment gateway).
- Implement production hardening features such as schema migrations, rate limiting, caching invalidation, and API versioning for medium-scale services.
- Build end-to-end smoke tests and observability playbooks (structured logs, metrics, alerts) for CI/CD pipelines.
Repositories
The developer's experience in this domain has been verified based on AI analysis of the following repositories:
Middle Frontend Developer
Confidence: Medium App Engineer
Frontend and full-stack MERN engineer (middle-level) focused on building React-driven single-page apps and integration-heavy user flows. The strongest proven skill is implementing SPA data flows and backend integrations as evidenced by StudyNotion/frontend/src/services/operations/courseDetailsAPI.js and backend/controllers/course.js. There is limited evidence of systematic performance benchmarking, automated test coverage, advanced accessibility engineering, or large-scale architecture leadership.
UI Component Architecture
4/10
How interface parts are built
Component boundaries and API/service separation are present with custom hooks and centralized reducers but there is limited evidence of a bespoke design system or advanced composition patterns.
Evidence
StudyNotion/frontend/src/services/operations/courseDetailsAPI.js
StudyNotion/frontend/src/hooks/useOnClickOutside.js
StudyNotion/frontend/src/reducer/index.js
Responsive & Cross-browser
3/10
Works on all screens and browsers
Responsive patterns and viewport declarations exist and a responsive table is implemented, but there is no advanced fluid layout strategy or explicit RTL/i18n readiness.
Evidence
StudyNotion/frontend/package.json - tailwindcss listed
DevSecOps-in-Action/frontend/public/index.html - meta viewport
Capstone-Mega-DevOps-Project/src/main/resources/templates/transactions.html - .table-responsive and overflow-x:auto
Performance Optimization
2/10
Speed of the interface
Some performance-minded dependencies and tooling are present but there is no measured optimization, bundle analysis, or virtualization of long lists.
Evidence
StudyNotion/frontend/package.json - react-lazy-load-image-component and framer-motion
StudyNotion/frontend/vite.config.js - Vite build tooling
StudyNotion/frontend/src/services/operations/courseDetailsAPI.js - centralized apiConnector usage
Accessibility & Semantics
2/10
Usable for everyone
There are pockets of accessibility and semantics (form labels, required attributes, a useOnClickOutside hook) but no evidence of systematic a11y tooling, ARIA usage for custom widgets, or CI a11y checks.
Evidence
StudyNotion/frontend/src/hooks/useOnClickOutside.js
Capstone-Mega-DevOps-Project/src/main/resources/templates/login.html - form labels and required attributes
State Management & Data Flow
4/10
Managing data in the app
Server and client state are organized via a reducer and API layer; there is explicit token handling, multipart uploads and an optimistic-update with rollback pattern in the To-Do app, showing pragmatic state-discipline.
Evidence
StudyNotion/frontend/src/reducer/index.js
DevSecOps-in-Action/frontend/src/Tasks.js - handleUpdate/handleDelete optimistic update with rollback
StudyNotion/frontend/src/services/operations/courseDetailsAPI.js - token, multipart/form-data and centralized apiConnector usage
UX & Visual Polish
3/10
Look and feel quality
UX shows attention to perceived performance and feedback - toasts, loading states and styled templates exist - but there are few skeletons, undo flows or documented UX edge-state patterns.
Evidence
StudyNotion/frontend/src/services/operations/courseDetailsAPI.js - toast.loading and toast.success usage
Capstone-Mega-DevOps-Project/src/main/resources/templates/dashboard.html - styled form controls and feedback
Capstone-Mega-DevOps-Project/src/main/resources/templates/register.html - inline validation via required attributes
Verified artifacts
Expertise
React• Middle
Frontend Architecture & Build Tools• Middle
HTML & CSS• Middle
Industries
Education• Middle
Technologies
Tailwind CSS
Bootstrap
React.js
Vite
Redux Toolkit
React Router
ArgoCD• mentioned only
AWS• mentioned only
CI/CD• mentioned only
CI/CD• mentioned only
Docker• mentioned only
Grafana• mentioned only
Jenkins• mentioned only
Kubernetes• mentioned only
Recommendations
- Develop and extend user-facing SPA features that require API integration, payments and file uploads in MERN-based EdTech or SaaS products.
- Implement and harden optimistic UI flows, error rollback and centralized apiConnector patterns across complex forms and course management UIs.
- Drive incremental improvements in observable performance and accessibility by adding instrumentation, CI a11y checks and measurable before/after benchmarks.
- Migrate or standardize component boundaries and introduce a design-system layer with documentation and visual tests to raise component-architecture maturity.
Repositories
The developer's experience in this domain has been verified based on AI analysis of the following repositories:
Middle DevOps Engineer
Confidence: Medium CI/CD Engineer
Mid-level DevOps / Platform engineer focused on building CI/CD and deployment automation with practical smoke-testing and container hardening; the primary strength is pipeline-driven delivery rather than complex application logic. The strongest proven skill is CI/CD and deploy validation as evidenced by .github/workflows/ci.yaml, .github/workflows/cd.yaml and scripts/smoke_test.py. There is limited public evidence of production-grade k8s tuning, formal SLOs/alerting, secrets/remote state best practices, or advanced cost/scale optimizations.
CI/CD Pipelines
5/10
Automated build and deploy
CI/CD pipelines are present and go beyond trivial copies: unit tests, linting, image build/push, image scanning, and a separate deploy workflow with smoke tests and terraform steps, but lack advanced pipeline engineering (no reusable workflows, signing, matrices, or progressive delivery gates).
Evidence
hotreloads/.github/workflows/ci.yaml: build-and-push job with lint, pytest, docker build/push and Trivy scanning
hotreloads/.github/workflows/cd.yaml: deploy job that pulls images, updates k8s manifests, applies manifests and runs smoke tests
hotreloads/scripts/smoke_test.py: post-deploy smoke test invoked from CD workflow
Infrastructure as Code
3/10
Managing servers with code
Infrastructure-as-code is used (Terraform modules and .terraform.lock.hcl) and the CI triggers terraform init/apply for registry modules, but remote state/locking, environment separation, and infra testing are not implemented or use local file paths in workflows.
Evidence
hotreloads/infra/aws/.terraform.lock.hcl: Terraform provider lockfile present
hotreloads/.github/workflows/ci.yaml: terraform init/apply -target=module.registry in infra/aws
hotreloads/.github/workflows/cd.yaml: terraform init to read outputs from infra/aws
Containerization & Orchestration
4/10
Working with containers
Containerization and orchestration are applied with multi-image build, non-root users in Dockerfiles and healthchecks; k8s manifests are deployed from CI, but there is no visible tuning of resources, probes, PDBs, or advanced k8s patterns in the provided human-authored files.
Evidence
hotreloads/api/Dockerfile: uses python:3.12-slim, creates non-root user, defines HEALTHCHECK and runs uvicorn
hotreloads/worker/Dockerfile: non-root user and HEALTHCHECK based on worker heartbeat
hotreloads/.github/workflows/cd.yaml: updates image tags in k8s manifests and applies k8s/api, k8s/worker, k8s/web
Observability & Monitoring
2/10
Watching system health
Lightweight observability is present via container HEALTHCHECKs and a smoke-test validating the end-to-end flow, but no SLOs, alerting rules, dashboards, structured tracing, or noise-reduction routing are provided.
Evidence
hotreloads/api/Dockerfile: HEALTHCHECK hitting /health/live
hotreloads/worker/Dockerfile: HEALTHCHECK that reads /tmp/worker_heartbeat
hotreloads/scripts/smoke_test.py: end-to-end smoke test used as a post-deploy validation
Reliability & Incident Response
4/10
Keeping systems up
There are concrete reliability decisions such as DB connection retry on startup, health endpoints and heartbeat-based worker healthchecks, plus deployment waits and smoke tests in CD; however, formal incident/runbook artifacts, progressive rollout strategies, and automated rollback steps are not present.
Evidence
hotreloads/api/db.py: get_pool implements retries to handle Postgres startup
hotreloads/worker/Dockerfile and worker healthcheck: heartbeat-based liveness check
hotreloads/.github/workflows/cd.yaml: kubectl rollout status waits and runs smoke_test.py as a deploy gate
Cloud & Cost Optimization
2/10
Smart use of the cloud
Cloud usage and cost considerations are basic: Terraform for AWS resources and pushing images to registries are automated in CI, but there is no evidence of autoscaling strategies, spot/eviction handling, rightsizing, or IAM least-privilege refinements in the human-authored artifacts.
Evidence
hotreloads/infra/aws/.terraform.lock.hcl: Terraform providers for AWS listed
hotreloads/.github/workflows/ci.yaml: tags and pushes images to ECR repositories obtained from infra/aws outputs
Expertise
Infrastructure as Code• Middle
Platform Engineering & IDP• Middle
Site Reliability Engineering• Middle
Technologies
Containers
IaC
Python• since 2024 • Senior
Bash
Terraform• since 2026
Ansible
Docker Compose
Helm• since 2025
GitHub Actions• since 2026
Loki
cert-manager
Prometheus• since 2025
Azure
CI/CD
GitOps
ArgoCD• since 2025
Jenkins
AWS
Docker
Kubernetes• since 2024
Nginx
Grafana• since 2025
Pydantic
Uvicorn
Harbor
Shift-Left
minikube
kubeadm
Amazon EKS
Azure AKS• since 2025
Amazon EC2
GitHub
Amazon S3
IAM
Recommendations
- Move Terraform state to a remote backend with locking (e.g., S3 + DynamoDB or a remote backend) and avoid local TF_STATE_PATH in CI to make infra reproducible and safe.
- Add explicit resource requests/limits, readiness/liveness probes, and PodDisruptionBudget/anti-affinity to k8s manifests and document rationale to improve reliability during rollouts.
- Introduce progressive delivery and rollback automation (canary or automated rollback on failed smoke tests) and consider artifact signing (cosign) to harden the supply chain.
- Add basic SLOs and alerting (Prometheus alert rules + Alertmanager routing) and correlate them with CI/CD gates to reduce alert noise and speed incident response.
Repositories
The developer's experience in this domain has been verified based on AI analysis of the following repositories: