Senior Database Security Engineer Guardium​/Database Activity Monit

Job Title:

Senior Database Security Engineer Guardium / Database Activity Monitoring

Job Location:

Charlotte, NC / Jersey City, NJ / Plano, TX

Job Type: 12+ Months contract

This is a Guardium–specific engineering role within Elina's Database Security Engineering org, sitting on the Database Activity Monitoring workstream. Unlike the org's other two current openings, this one is explicitly about the Guardium product itself: provisioning it, patching it, running version upgrades, and building reporting on top of it. It is not a general entitlement/IAM role and not a general "database activity monitoring automation" role, it's hands–on Guardium ownership.

• Hands–on Python, Unix/KSH shell scripting, Power Shell
• Hands–on Oracle, MSSQL, or other RDBMS
• Hands–on experience with product certifications
• Hands–on process automation
• Jira and Horizon

• Cockroach DB, Cassandra, Postgres
• Cloud database experience (AWS or Azure)
• Git Hub Copilot
• Prompt engineering

Elina's Database Security org splits into two functional areas: IAM/entitlements and activity monitoring. This req sits within activity monitoring, specifically the Guardium tooling piece of it.

Pure engineering team, not operations. No on–call, not staffed 24/7. Builds and certifies solutions, hands off to ops with runbooks once adopted.

Environment is primarily on–prem SQL Server today. Cloud (AWS RDS, Azure) is newer and still being scoped, not a deep production requirement yet, treat as a plus, not a bar.

Heavy Jira usage, PI–planning driven.

Elina wants hands–on engineers who build things themselves, not architects or people who talk strategy. This is the single most consistent filter across every opening she's released. Screen out candidates who lean on leadership/architecture framing unless they can also demonstrate daily hands–on work.

Python is a hard requirement across nearly all of her openings, this one included.

Current baseline consultant, Praful Kapadia, is the reference point for "what good looks like": hands–on, independent, security–minded.

Test Guardium directly and specifically. Ask for a real example: a provisioning, patching, or version upgrade they personally performed, not just "we used Guardium for monitoring." Several candidates screened for the org's other reqs (Sanjay Shilpi, Bharath Bushan Banuka) explicitly stated they have not used Guardium hands–on, they are not fits for this req even though they were viable for others.

Cross–check every required JD line against the resume before the screening call, not just what the resume itself highlights. This has been missed before (a candidate's SQL Server gap wasn’t caught until directly asked, since the resume didn’t draw attention to it).

Push every technical claim for a named tool, named platform, and a real number or outcome. Generic descriptions ("we did entitlements," "we built a monitoring system") without specifics have been a recurring red flag pattern across several resumes for this org, watch for it here too.

Watch for resumes with suspiciously round, universally positive stats (100% success rates, zero data loss across every project, uniform percentage improvements across unrelated engagements). Treat with more scrutiny, not less.

Watch for leftover AI–generation artifacts in resumes (instructional–sounding sentences that shouldn't be in a professional summary, e.g. "X is not overstated"). This has appeared more than once and is a distinct red flag from ordinary resume inflation.