Production Support Engineer

VBEST Software Inc
United States
9 days ago
Apply on www.dice.com
Prepare application

Role details

Contract type
Permanent contract
Employment type
Full-time (> 32 hours)
Experience level
Experienced
Experience required
3 years minimum
Working hours
Regular working hours
Job source

Tech stack

Application Programming Interfaces (APIs) CA Workload Automation Ae Unix Databases Database Connection File Systems Apache Hadoop Oracle (Applications) Shell Script SQL Databases Splunk Dynatrace

Requirements

  • 3 to 5 years hands on application production support
  • Strong Autosys
  • Strong Unix and Shell scripting
  • Working SQL, Oracle, Hadoop or similar DBMS
  • Ability to juggle and prioritize multiple concurrent issues
  • Fast independent learner

Required, confirmed from team member

  • Command level Unix fluency, not tool familiarity. Interviewers ask for the actual syntax: du and df for disk space, top and uptime for system load, find with -type and -mtime flags for locating files by age. A candidate who can describe what a command does but can’t produce the flags will get caught here.
  • Ability to distinguish failure types precisely. Interviewers specifically probe whether a candidate conflates a data issue with a Unix file system issue with a database connection pool issue. These are three different diagnostic paths and the interviewer will correct and re-ask if a candidate blurs them.
  • SQL depth beyond basic querying: index behavior and why a query runs slow, truncate versus delete, join types used in production troubleshooting, not just writing selects.
  • Autosys job state knowledge beyond scheduling, specifically the difference between a job marked inactive versus on hold versus on ice, and why a team would use each.
  • Splunk and Dynatrace used together, and candidates should be able to explain why a team runs both rather than just one. Splunk gets tested as a log search and correlation tool, not described as monitoring.
  • Noisy alert management. Interviewers ask how a candidate would handle an alert threshold that’s firing too often, for example tuning a CPU alert from 70 percent to 85 percent to cut false positives.
  • Incident severity fluency: candidates should be able to define P1 through P4 without hesitation and describe how communication changes at each level, including whether they’d post to a status page versus direct email during an outage.
  • Basic API and auth troubleshooting exposure, specifically JWT or token related login failures, came up as a possible scenario topic.
  • Shell scripting for automation of repetitive work, for example disk cleanup or log rotation scripts, should be a real example the candidate has done, not something on the resume without a story behind it.

Apply for this position

This job is hosted externally. Click below to view the full posting and apply.

Apply on www.dice.com
Prepare application

Good distractions

Talks and stories from around this role — technically off-topic, practically not.

2:16 min

Structuring technical interviews to evaluate candidate culture and observability

Tejas Chopra Tejas Chopra ¡ LIVE

3:04 min

Database evolution and the funding behind vector databases

Erik Bamberg ¡ LIVE

2:38 min

Establishing comprehensive monitoring and log management

Michael Eder +1 ¡ LIVE

2:03 min

Microsoft integrating native Unix coreutils into Windows environments

Chris Heilmann +2 ¡ LIVE

4:01 min

Managing application isolation via pluggable database models

Wei Hu Wei Hu ¡ World Congress 2022

3:10 min

Correlating dispersed logs using structured request tracing

Michael Eder +1 ¡ LIVE

Videos

See all

Related articles

See all