A strong ML engineer JD specifies the exact ML problem domain (classification, forecasting, recommendations), the specific frameworks required (scikit-learn, PyTorch, XGBoost), the MLOps stack (MLflow, Kubeflow, SageMaker), and the pipeline ownership scope. Vague requirements like “experience with ML” attract the wrong candidates and inflate your screening volume significantly.
Why Generic Machine Learning Job Descriptions Fail
Most machine learning engineer job descriptions are written too broadly. Listing Python, TensorFlow, and “experience building ML models” attracts every data analyst who has run a scikit-learn tutorial, every research scientist who has trained models without ever deploying one, and every data engineer who has pre-processed features but never written a training loop. As a result, the screening funnel fills up with candidates who look qualified on paper but cannot do the specific job.
The templates below are written for precision. Each one specifies the problem domain, the exact tooling stack, the pipeline ownership scope, and the production experience expected. Copy the template closest to your use case and swap in your specific frameworks and business context. Three variants are included: a mid-level ML engineer for applied modeling work, a senior ML engineer for cross-system ownership, and an MLOps-focused ML engineer for teams that need infrastructure and pipeline depth.
What Makes a Good ML Engineer Job Description
Five elements separate effective ML engineer JDs from ones that generate noise.
Specific problem domain. State the ML task: churn prediction, demand forecasting, fraud detection, recommendation systems, NLP classification, computer vision, anomaly detection, or time-series forecasting. Candidates with genuine production experience in your domain will self-select in. Generalists without it will still apply, but your screen completion rate improves when the JD signals what you actually care about.
Named frameworks, not categories. Write “XGBoost and LightGBM with SHAP explainability” rather than “gradient boosting experience.” Write “PyTorch with custom training loops and Lightning for experiment management” rather than “deep learning frameworks.” The specificity filters out candidates who list framework names on a resume without having used them in production systems.
Pipeline ownership scope. Describe what the engineer will own end-to-end: feature engineering pipelines, training orchestration via Kubeflow or Airflow, model evaluation and registry via MLflow, serving via FastAPI or SageMaker endpoints, and drift monitoring via Evidently AI or custom statistical checks. Candidates who have only trained models in notebooks cannot own production pipelines, and the JD should make clear that pipeline ownership is expected from day one.
Collaboration, Timezone, and Seniority Signals
Collaboration and timezone context. For nearshore roles, state explicitly that the engineer works within US business hours (Costa Rica UTC-6, Colombia UTC-5), participates in daily standups, and communicates primarily in English. This filters for candidates who operate in an async-light, real-time collaborative environment rather than candidates accustomed to fully async offshore arrangements.
Seniority signals, not years. Instead of “5+ years experience,” describe production system ownership signals: “has deployed at least one ML model to a production endpoint serving live traffic” or “has managed a model retraining pipeline that runs on a scheduled basis without manual intervention.” These signals are more predictive than years of experience and attract candidates who understand what production ML actually requires.
Mid-Level ML Engineer Job Description Template
Use this template for engineers with 3 to 5 years of experience who will build and maintain production ML models under the direction of a senior engineer or ML tech lead. Adjust the problem domain and specific frameworks to match your environment.
About the Role
We are hiring a Machine Learning Engineer to build and maintain production ML systems for [your company], a [brief company description]. You will own end-to-end development of models for [specific domain: e.g., customer churn prediction, demand forecasting, fraud detection], from feature engineering through model deployment and monitoring. You will work directly with our data and product teams in a daily-standup sprint environment and will be based in Costa Rica or Colombia, working US Eastern / Central business hours.
Responsibilities
- Design and implement feature engineering pipelines for [specific data types: tabular transaction data, clickstream events, CRM activity logs]
- Train, evaluate, and tune supervised ML models (XGBoost, LightGBM, or scikit-learn) for classification and regression tasks
- Package and deploy models as REST API endpoints using FastAPI or BentoML on [AWS/GCP/Azure]
- Instrument model monitoring for input feature drift and prediction quality degradation using Evidently AI or equivalent
- Maintain experiment tracking and model registry in MLflow, ensuring all training runs and model versions are reproducible
- Write unit tests for all feature transformations and model evaluation components
- Participate in daily standups, sprint planning, and model review sessions with US-based team members
- Document model design decisions, evaluation results, and known limitations in shared team documentation
Requirements
- 3 to 5 years of Python experience with at least 2 years building production ML models on real user-facing data
- Hands-on experience with scikit-learn, XGBoost, or LightGBM on tabular data with more than 100,000 rows
- Experience deploying at least one ML model to a production endpoint serving real traffic, with working knowledge of FastAPI, BentoML, or a cloud-managed serving endpoint
- Familiarity with MLflow or an equivalent experiment tracking and model registry tool
- Strong English communication skills, written and spoken, at the level required for daily collaboration with a US-based engineering team
- Reliable home office setup with high-speed internet; experience working remotely in a sprint team environment
Nice to Have
- Experience with Airflow or Kubeflow for ML pipeline orchestration
- AWS SageMaker, GCP Vertex AI, or Azure ML experience
- SHAP or LIME experience for model interpretability and stakeholder explanation
- Exposure to deep learning frameworks (PyTorch or TensorFlow) for NLP or image classification tasks
Skip the JD Process Entirely
Share your ML use case with us and we will match you with pre-screened engineers in 72 hours.
Senior ML Engineer Job Description Template
Use this template for engineers with 5 to 8 years of experience who will own cross-system ML architecture decisions, drive model quality standards, and mentor more junior engineers. Senior ML engineers should have full ownership of at least one production model lifecycle.
About the Role
We are hiring a Senior Machine Learning Engineer to lead our applied ML efforts for [company name]. You will own the full lifecycle of production ML systems for [specific domain], from business problem framing through feature design, model development, deployment, and ongoing quality management. You will make key architecture decisions, define evaluation standards, and work closely with product and engineering leadership to prioritize the ML roadmap. This is a fully remote role based in Costa Rica or Colombia with daily US business hours collaboration.
Responsibilities
- Define and own the feature engineering strategy for [specific data domain], including feature store design, reusability standards, and data leakage prevention protocols
- Design, train, and deploy production ML models using [PyTorch / XGBoost / ensemble methods] for [specific tasks]
- Architect model retraining pipelines in Kubeflow or Airflow, including automated evaluation gates and rollback procedures
- Define model evaluation frameworks covering business-relevant metrics, offline evaluation protocols, and shadow deployment testing before production releases
- Own model monitoring infrastructure: feature drift detection, prediction quality tracking, and automated alerting with defined retraining triggers
- Review junior ML engineer code and provide structured technical feedback in code reviews and architecture discussions
- Collaborate with data and product teams to translate business requirements into ML problem frames and evaluation criteria
- Maintain model cards and system documentation for all production models to support audit, regulatory, and business review requirements
Requirements
- 5 to 8 years of Python and ML engineering experience with at least 3 years of production system ownership
- Proven track record of deploying multiple ML models to production endpoints with documented business impact
- Strong depth in at least two of: gradient boosting (XGBoost, LightGBM, CatBoost), deep learning (PyTorch or TensorFlow), NLP (Hugging Face Transformers), or time-series forecasting (Prophet, statsmodels, or custom LSTM architectures)
- Experience designing and maintaining ML training pipelines in Kubeflow, Airflow, or AWS SageMaker Pipelines
- Hands-on model serving experience with latency and cost optimization under production traffic constraints
- Experience with model drift detection and retraining automation in production environments
- Strong English fluency for daily technical discussions, written documentation, and product stakeholder communication
Nice to Have
- ML platform or feature store design experience (Feast, Tecton, or custom implementations)
- Experience with model interpretability at scale (SHAP, Integrated Gradients, or counterfactual explanations)
- Exposure to causal inference, uplift modeling, or treatment effect estimation
- MLflow Model Registry and multi-environment model promotion workflows
MLOps-Focused ML Engineer Job Description Template
Use this template when your team’s primary gap is in ML infrastructure, pipeline reliability, and model serving operations rather than new model development. MLOps-focused engineers typically have stronger software engineering depth and may have less research-style modeling experience than generalist ML engineers.
About the Role
We are hiring a Machine Learning Engineer with a strong MLOps focus to own our ML infrastructure and training pipeline operations at [company name]. You will design, build, and maintain the systems that allow our data science team to ship models reliably and operate them in production without manual intervention. This is an infrastructure-first role that requires both ML engineering depth and strong software engineering reliability practices. Remote, based in Costa Rica or Colombia, US business hours.
Responsibilities
- Design, build, and maintain automated ML training pipelines using Kubeflow Pipelines, Airflow, or AWS SageMaker Pipelines for multiple model types
- Build and maintain model serving infrastructure using FastAPI, BentoML, or cloud-managed endpoints (SageMaker, Vertex AI, or Azure ML), including canary deployment, traffic splitting, and rollback automation
- Implement model monitoring systems covering input feature distribution drift, prediction quality degradation, and upstream data quality checks with automated alerting and retraining trigger logic
- Own the MLflow model registry workflow: experiment tracking standards, model version naming conventions, staging and production promotion gates, and automated evaluation gates
- Build reusable feature engineering pipeline components and integrate with existing feature stores or data warehouse tables
- Implement CI/CD for ML workflows: automated testing of data pipelines, model evaluation gates in deployment pipelines, and infrastructure-as-code for ML environments
- Define and document runbooks for production ML incidents, including escalation paths and rollback procedures
Requirements
- 4+ years of Python engineering with at least 2 years of ML infrastructure or MLOps-specific ownership
- Hands-on experience building and maintaining automated ML training pipelines (Kubeflow, Airflow, or SageMaker Pipelines) that run reliably in production without manual intervention
- Production model serving experience including latency optimization, horizontal scaling, and failure mode handling
- MLflow or equivalent model registry experience with structured model promotion workflows
- Strong software engineering practices: unit testing, CI/CD integration, infrastructure-as-code, and code review participation
- Solid understanding of ML model evaluation methodology sufficient to build evaluation gates that catch model quality regressions before production deployment
- English fluency at a level required for documentation, incident communication, and daily collaboration with US-based teams
Nice to Have
- Terraform or Pulumi experience for ML infrastructure provisioning
- Feature store experience (Feast, Tecton) or experience designing feature tables in a data warehouse for ML consumption
- Kubernetes-based ML serving experience (Seldon Core, KFServing/KServe)
- Experience with distributed training (Horovod, PyTorch DDP) for large model training jobs
Adapting These Templates for Nearshore Hiring
When posting these job descriptions for nearshore candidates through a staffing partner like Kore BPO, four adjustments improve candidate quality and reduce screening time.
State the timezone explicitly. Write “You will work Costa Rica (UTC-6) or Colombia (UTC-5) business hours with daily overlap with our US East Coast / Central team.” This filters out candidates in other time zones who might otherwise apply and sets clear expectations for candidates who prefer async-heavy work arrangements.
Specify English fluency level. Write “Strong English is required for daily standup participation, written technical documentation, and direct communication with US-based product and engineering stakeholders.” In Latin American ML engineering markets, English fluency varies significantly. Being explicit about the level required prevents mismatches that surface after placement.
Remove compensation ranges that assume US cost structures. If your internal JD format includes a US salary range, remove or adjust it for the nearshore version. Nearshore ML engineers in Costa Rica and Colombia command significantly different market rates from their US counterparts. Including a US-calibrated range attracts the wrong candidate expectations or signals that you have not done your research on Latin American market rates.
Describe the remote collaboration setup. Mention the tools your team uses for collaboration (Slack, Jira, GitHub, Notion, Zoom), the sprint cadence (two-week sprints, daily standups), and whether the role is fully remote or involves any in-person expectations. Nearshore candidates in Latin America who have worked with US clients understand this setup, but making it explicit reduces misaligned expectations on both sides.
Common ML Engineer JD Mistakes
Four patterns in ML engineer job descriptions consistently produce poor candidate pipelines.
Listing every ML framework ever invented. JDs that require “experience with TensorFlow, PyTorch, Keras, scikit-learn, XGBoost, LightGBM, CatBoost, Hugging Face, LangChain, OpenAI, AWS SageMaker, GCP Vertex AI, Azure ML, MLflow, Kubeflow, Airflow, Spark, and dbt” communicate that the hiring team does not understand what the role actually needs. Every experienced ML engineer immediately recognizes this as a list-everything JD, which signals poor internal alignment on requirements and low hiring process maturity.
Requiring PhD or research publications for applied engineering roles. Production ML engineering is primarily a software engineering and systems design discipline with ML-specific skills layered on top. Requiring a PhD filters out the most qualified applied engineering candidates, who typically have strong industry experience without research publications. Research publications predict research output, not production system reliability.
Conflating data science with ML engineering. Data scientists build and analyze models to answer business questions. ML engineers build and operate the systems that run models at production scale. A JD that mixes these descriptions produces a candidate pool that skews toward model explorers rather than system builders. If you need both, write two separate JDs.
Omitting pipeline and serving requirements entirely. Many ML engineer JDs describe only model development (train, evaluate, tune) without mentioning deployment, serving, monitoring, or retraining. Engineers who read this description correctly infer that the role is notebook-oriented rather than production-system-oriented. If production pipeline ownership is a core expectation, the JD must say so explicitly with specific tools named.
Frequently Asked Questions
Positioning and Scoping the JD
Should I write a separate JD for nearshore ML engineers vs US-based ones?
Yes, with targeted adjustments. The core technical requirements stay the same, but the nearshore version should explicitly state the timezone overlap requirement, the English fluency expectation, the remote collaboration tools and cadence, and the compensation structure (which differs significantly from US market rates). Using a US-calibrated JD without these adjustments creates misaligned expectations on both sides of the hiring process.
How specific should the framework requirements be in a ML JD?
Specific enough that a strong candidate can read the JD and know immediately whether they have relevant production experience, and a weak candidate can read it and self-select out. Named frameworks (XGBoost, LightGBM, PyTorch, LangChain) with production context (“deployed to a live serving endpoint”) are more useful than categories (“gradient boosting experience” or “deep learning frameworks”). The goal is to calibrate the inbound candidate quality, not to list every tool the team has ever touched.
What is the difference between an ML engineer and a data scientist in a JD?
ML engineers own the production systems that run models reliably at scale. Data scientists own the analytical and modeling work that produces insights and model designs. In practice there is overlap, but the clearest distinction is production system ownership: an ML engineer is expected to own the training pipeline, serving infrastructure, monitoring, and retraining automation. A data scientist is expected to own the model design, feature selection, and business interpretation of results. Conflating these in a JD produces a candidate pool that is misaligned with what the role actually requires.
Adapting and Reusing the Template
How do I attract production-experienced ML engineers rather than notebook users?
Three JD elements signal production experience requirements clearly. First, name specific serving infrastructure (FastAPI, BentoML, SageMaker endpoints) as requirements rather than nice-to-haves. Second, require documented experience with model monitoring and retraining pipelines rather than just “model deployment.” Third, ask for production system ownership as a stated requirement: “has owned at least one model serving real user traffic for a minimum of 6 months with all retraining and monitoring responsibilities.” Production-experienced engineers recognize these requirements as aligned with real system ownership. Notebook-focused candidates typically cannot truthfully meet them.
What if I do not use all the tools listed in the template?
Replace the template tools with your actual stack throughout. If you use Prefect instead of Airflow, write Prefect. Swap in TorchServe instead of FastAPI, and write TorchServe. If your monitoring is custom statistical checks rather than Evidently AI, describe what you actually do. The templates are designed to be adapted, not copied wholesale. The structural logic (problem domain, specific tools, pipeline ownership scope, collaboration context) transfers directly even when the specific tools change.
Related Articles
FIND YOUR NEARSHORE ML ENGINEER
Get pre-screened machine learning engineers from Costa Rica and Colombia on your desk within 72 hours.
GET STARTED TODAYNo upfront fees | 90-day replacement guarantee