stepsav stepsav

Backend • Middle
Node JS
Python
Data Layer & Database: 7/10
API Design: 6/10
System Architecture: 5/10
Active 18 days ago
Invite to interview
Message
Download CVCV
Overview
Technical skills
Roles

Overview

A pragmatic backend/API engineer at an experienced mid-to-senior level who builds small production systems end-to-end. The strongest proven skill is implementing REST services and payment/subscription flows with concrete idempotency and schema-evolution measures (see server/src/index.js and server/src/db.js). The public code lacks systematic testing, advanced distributed-systems patterns, and formal secrets/CI hardening documentation.

Technical skills

Node JS• Middle
Python• Middle
Node JS
Express
Bcrypt
Python
aiogram
Pydantic
Aiohttp
Asyncio
Databases
SQLite
AI/ML
huggingface_hub
OpenAI SDK
Anthropic SDK
DevOps
Containers
Cloud
SRE
Middle Backend Developer Confidence: Medium API Engineer
A pragmatic backend/API engineer at an experienced mid-to-senior level who builds small production systems end-to-end. The strongest proven skill is implementing REST services and payment/subscription flows with concrete idempotency and schema-evolution measures (see server/src/index.js and server/src/db.js). The public code lacks systematic testing, advanced distributed-systems patterns, and formal secrets/CI hardening documentation.
API Design
6/10
How well APIs are designed
API surface shows deliberate design choices: auth middleware, idempotent payment creation, admin guard and health/config endpoints, but lacks formal versioning, explicit pagination and a documented error contract.
Evidence
stepsav/urokio/server/src/index.js: /api/payments/create uses an idempotenceKey and createPurchase stepsav/urokio/server/src/index.js: auth() middleware and adminGuard() protecting admin endpoints stepsav/urokio/server/src/index.js: /api/app/config and /api/health endpoints (app config, health checks)
Data Layer & Database
7/10
Working with databases
Data layer demonstrates conscious decisions for a small-production SQLite deployment: WAL mode, migration-style schema evolution, ON CONFLICT upserts, tuned raw SQL and idempotent payment status updates.
Evidence
stepsav/urokio/server/src/db.js: initSchema() creates tables, indices and performs ALTER TABLE soft-migrations (adding columns if missing) stepsav/urokio/server/src/db.js: db.pragma('journal_mode = WAL') and use of prepared statements / ON CONFLICT upserts (saveProgress, saveDeviceProgress) stepsav/urokio/server/src/db.js: setPurchaseStatus() returns changes to make payment handling idempotent; activateSubscription() extends from MAX(expires_at) to avoid burning remaining days
Scalability & Performance
4/10
Handling load and speed
Some scalability-conscious choices exist (content preloading, WAL, periodic renew task), but no evidence of advanced scaling (distributed queues, cache invalidation strategy, connection pooling settings or load-testing artifacts).
Evidence
stepsav/urokio/server/src/index.js: loadContent() loads course content into memory and /api/content endpoints stepsav/urokio/server/src/index.js: renewSubscriptions() scheduled with setInterval and initial kick-off stepsav/urokio/server/src/db.js: PRAGMA WAL to reduce write contention for SQLite
System Architecture
5/10
Overall system structure
Code is modular and split into purpose-driven modules (auth, payments, content, device-sync, subscriptions); Python project shows orchestrator/worker separation. Overall architecture is pragmatic for a small fleet rather than a multi-service distributed system.
Evidence
stepsav/urokio/server/src/index.js: clear separation of content, payments, admin, webhook and device sync routes stepsav/bot_YO/core/orchestrator.py: Orchestrator/worker pattern and signal handling for the automation service stepsav/urokio/server/src/db.js: encapsulated DB helper functions for subscriptions, purchases and analytics
Security & Auth
4/10
Protecting data and access
Good practical controls are present (bcrypt password hashing, JWT auth, admin-token guard, returnUrl whitelist), but there are some risky defaults (CORS '*' and a dev JWT secret fallback) and limited evidence of hardened input sanitization and secrets handling workflows.
Evidence
stepsav/urokio/server/src/index.js: bcrypt.hash for passwords and jwt.verify in auth middleware stepsav/urokio/server/src/index.js: adminGuard uses ADMIN_TOKEN env and returnUrl is validated with a regex whitelist stepsav/urokio/server/src/index.js: CORS middleware sets Access-Control-Allow-Origin: '*' and JWT_SECRET defaults to 'dev_secret_change_me'
Reliability & Observability
5/10
Stability and monitoring
Observability and reliability features exist (health endpoint, admin stats, concise webhook handling that revalidates payments, structured DB for analytics); retry/backoff and distributed tracing are not evident, but there are sensible operational choices for a small deployment.
Evidence
stepsav/urokio/server/src/index.js: /api/health and fast 200 in webhooks while reconciling payment state asynchronously stepsav/urokio/server/src/db.js: getAdminStats() aggregates usage and progress for an admin panel stepsav/bot_YO/monitoring/logger.py and monitoring/metrics.py: presence of structured logging and metrics collector in the automation stack
Expertise
Node.js• Middle
Python• Middle
Backend AI & LLM• Middle
Microservices & API Architecture• Middle
Industries
Education• Middle
Technologies
Python• Middle
Node JS• Middle
Express
Bcrypt
SQLite
Asyncio
Aiohttp
aiogram
Recommendations
  • Lead development of small-to-medium REST backends (Node.js + SQLite/embedded DB) that require payment/subscription flows and admin tooling.
  • Implement and maintain browser-automation orchestration and AI-provider integration services (Python async workers, orchestration, provider adapters).
  • Harden operational aspects for production: secrets management (no defaults), CORS policy, structured monitoring/alerts and add automated tests and migration histories
Repositories
The developer's experience in this domain has been verified based on AI analysis of the following repositories:
bot_YO urokio f5tts-runpod
Middle DevOps Engineer Confidence: Medium Generalist
A practical generalist engineer at a solid middle level who builds serverless ML inference workers and media-processing handlers. The strongest proven skill is resilient model-serving and runtime orchestration for serverless inference - evidenced by the model fetch/validation (_ensure_model), device-aware initialization, and the ComfyUI boot/polling + GEN_TIMEOUT logic in the handlers. What is not evidenced is CI/CD, Terraform-style IaC, observability pipelines (metrics/alerts/dashboards), or formal infra testing/playbooks in public code.
CI/CD Pipelines
Automated build and deploy
Not evidenced in public code
Infrastructure as Code
Managing servers with code
Not evidenced in public code
Containerization & Orchestration
2/10
Working with containers
Basic container/runtime awareness and environment-driven configuration are present (device selection, startup supervision), but no orchestration manifests, resource tuning, or Kubernetes/Pod-level resilience constructs.
Evidence
stepsav/wan-runpod-worker/handler.py: start_comfy - boot loop with BOOT_TIMEOUT and readiness polling stepsav/xtts-runpod/handler.py: device detection using torch.cuda.is_available and _tts.to(_device)
Observability & Monitoring
2/10
Watching system health
Minimal observability - print/log statements and returned timing (gen_seconds) exist, but no structured metrics, alerts, dashboards, or SLO definitions.
Evidence
stepsav/f5tts-runpod/handler.py: prints on model load and returns gen_seconds in response stepsav/xtts-runpod/handler.py: prints when loading RUAccent and model readiness, returns gen_seconds
Reliability & Incident Response
3/10
Keeping systems up
Concrete reliability primitives are implemented: startup supervision, polling with deadlines, explicit timeouts, fail-fast comments, and defensive error returns — useful for resilient serverless workers but not full incident/playbook coverage.
Evidence
stepsav/wan-runpod-worker/handler.py: wait_result polling loop with GEN_TIMEOUT and RuntimeError on timeout stepsav/wan-runpod-worker/handler.py: start_comfy raising RuntimeError if ComfyUI doesn't become ready stepsav/f5tts-runpod/handler.py: _ensure_model validates presence of checkpoint/vocab and raises RuntimeError if missing
Cloud & Cost Optimization
2/10
Smart use of the cloud
Some cost- and cloud-awareness (boot/gen timeouts intended to avoid long-running expensive jobs, device selection for GPU) but no autoscaling, spot/eviction strategies, or measured rightsizing.
Evidence
stepsav/wan-runpod-worker/handler.py: GEN_TIMEOUT and BOOT_TIMEOUT with comment 'fail-fast: не жечь деньги >10 мин' stepsav/xtts-runpod/handler.py: _device chosen by torch.cuda.is_available (GPU-aware runtime selection)
Expertise
Site Reliability Engineering• Middle
Platform Engineering & IDP• Middle
Industries
Artificial Intelligence• Middle
Media & Entertainment• Middle
Technologies
Cloud
Containers
SRE
RunPod• mentioned only
Recommendations
  • Develop serverless ML inference endpoints and media-processing microservices (model lifecycle, cold-start mitigation, safe file handling).
  • Implement platform glue for model-serving - supervised warm processes, polling-based orchestration, and graceful shutdown/cleanup logic for edge cases.
  • Harden observability and SLO-driven alerts: add metrics, structured logging, dashboards-as-code and burn-rate aware alerting.
  • Expand into repeatable infra: add CI pipeline artifacts, IaC modules for deployment/environment separation, and basic infra tests (smoke/integration).
Repositories
The developer's experience in this domain has been verified based on AI analysis of the following repositories:
f5tts-runpod xtts-runpod wan-runpod-worker
Intern AI/ML Engineer Confidence: Medium Generalist
A pragmatic developer working at a junior level, focused on building production inference wrappers and serverless endpoints for TTS. The strongest proven skill is deploying and operating TTS inference endpoints (evidenced by the runpod handlers: stepsav/f5tts-runpod/handler.py and stepsav/xtts-runpod/handler.py which handle model download, device selection, accent processing and audio file output). There is little-to-no evidence of custom model training, experiment tracking, benchmarking, or research-grade ML engineering in public code.
Model Architecture & Training
1/10
How well models are designed and trained
Minimal model engineering - inference wrappers around existing TTS libraries are present, no custom architectures or training loops.
Evidence
stepsav/f5tts-runpod/handler.py: _make_f5 uses f5_tts.api.F5TTS for inference stepsav/xtts-runpod/handler.py: _tts = TTS(MODEL) and .tts_to_file used for generation
Data Pipeline & Feature Engineering
1/10
How data is prepared for models
Very light preprocessing for text (accentization) only; no dataset pipelines or feature engineering.
Evidence
stepsav/f5tts-runpod/handler.py: _accentize loads ruaccent and calls process_all(text) stepsav/xtts-runpod/handler.py: _accentize with lazy RUAccent loading and _plus_to_acute conversion
Experimentation & Evaluation
1/10
How results are measured and tested
Basic logging and runtime metrics (timings, gen_seconds); no experimental protocol, evaluation suites, or tracking integrations.
Evidence
stepsav/f5tts-runpod/handler.py: prints on load and returns gen_seconds in handler output stepsav/xtts-runpod/handler.py: prints model ready and returns gen_seconds in handler output
MLOps & Deployment
3/10
How models are shipped to production
Practical inference deployment work - serverless handlers, model download/caching, device selection and cold-start considerations are implemented.
Evidence
stepsav/f5tts-runpod/handler.py: _ensure_model uses huggingface_hub.snapshot_download with allow_patterns to fetch checkpoint + vocab stepsav/xtts-runpod/handler.py: runpod.serverless.start entrypoint, COQUI_TOS_AGREED env handling and model instantiation
Computational Efficiency
3/10
How efficiently computing resources are used
Some efficiency and operational choices - device selection for CUDA, lazy loading to reduce cold-start, downloading only needed files; no low-level GPU optimization or quantization.
Evidence
stepsav/f5tts-runpod/handler.py: _device = 'cuda' if torch.cuda.is_available() else 'cpu' and selective download of checkpoint/vocab stepsav/xtts-runpod/handler.py: RUAccent loaded lazily to avoid slowing cold start
Research Depth & Innovation
1/10
Depth of research and new ideas
No research-depth artifacts - no paper reimplementations, no custom layers, no ablations or experimental methodology.
Evidence
stepsav/f5tts-runpod/handler.py: inference-only wrapper, no custom model code stepsav/xtts-runpod/handler.py: uses TTS.api directly without custom architecture changes
Expertise
Audio & Speech Processing• Intern
Industries
Media & Entertainment• Middle
Technologies
Anthropic SDK
OpenAI SDK
huggingface_hub
Pydantic
RunPod• mentioned only
Recommendations
  • Develop serverless inference endpoints and lightweight audio pipelines - packaging, caching, and cold-start mitigation for TTS/voice models.
  • Implement production MLOps for audio models - model versioning with huggingface_hub, automated snapshot downloads, health checks and metrics (latency/cold-start) instrumentation.
  • Build integrations for audio preprocessing and postprocessing tooling (accent/phoneme handling, batching, file format handling) and add unit/integration tests for these paths.
Repositories
The developer's experience in this domain has been verified based on AI analysis of the following repositories:
bot_YO f5tts-runpod xtts-runpod