T3 Support Engineer

This role is suitable for a Senior-level T3 Support Engineer or an experienced Middle-level specialist with a background in technical support, SRE, or engineering. Candidates should have strong SQL, code-reading, PHP and/or JavaScript/TypeScript, cloud, monitoring, error-tracking, API, and technical documentation skills, alongside excellent C1-level English. They should be experienced in investigating escalated incidents, analyzing logs and metrics, debugging databases and integrations, reproducing bugs, applying low-risk fixes, monitoring resolutions, and escalating complex issues to Engineering.

How would you investigate a production issue escalated from T1 where users cannot complete a transaction?

I would first clarify the symptoms, scope, timing, and affected users, then correlate application logs, Sentry errors, metrics, and recent deployments. I would reproduce the issue where possible, validate relevant database records with read-only SQL, identify the failing system boundary, and document evidence before applying or escalating a fix.

How would you use SQL to troubleshoot a data-related issue in a production relational database?

I would use safe, read-only queries with appropriate filters, joins, and limits to compare affected records with expected data. I would avoid modifying production data directly, verify query performance, protect sensitive information, and provide the exact findings and record identifiers to Engineering if a correction is required.

What steps would you take when analyzing an error in Sentry?

I would review the exception type, stack trace, breadcrumbs, request context, affected release, frequency, and user impact. I would group the error with related events, correlate it with logs and deployments, reproduce it if possible, and determine whether it is caused by application code, configuration, data, or an external dependency.

How would you use Grafana or a similar monitoring tool during an outage?

I would examine dashboards for traffic, latency, error rates, resource utilization, and dependency health, comparing the incident period with normal baselines. I would use time ranges and service labels to identify when the degradation began and whether it affects one service, region, client, or the entire platform.

How would you troubleshoot a failing REST or GraphQL API request?

I would inspect the request method, URL or GraphQL operation, headers, authentication, variables, payload, response status, and error body. I would compare successful and failed requests, check resolver or backend logs, validate dependent data and services, and use tools such as curl, Postman, or browser developer tools.

What is important when troubleshooting an issue that crosses a monolith and multiple services?

I would trace the request across system boundaries using correlation IDs, timestamps, logs, and service metrics. I would validate each handoff, including authentication, queues, APIs, database operations, and external integrations, rather than assuming that the first visible error is the root cause.

How would you approach a small code fix in PHP or JavaScript/TypeScript?

I would first reproduce the defect and understand the existing control flow, input validation, error handling, and side effects. I would make the smallest low-risk change, test normal and edge cases, review logs or automated checks, and follow the release and rollback process before deployment.

How would you investigate an AWS-related application problem?

I would identify the affected AWS services and inspect relevant CloudWatch logs, metrics, deployment history, permissions, configuration, and service health. I would verify secrets and environment variables without exposing their values, check connectivity and resource limits, and escalate when infrastructure changes or elevated access are required.

How would you debug a problem affecting a React Native mobile application but not the web application?

I would compare app versions, operating systems, device conditions, API requests, authentication state, and feature flags between affected and unaffected clients. I would inspect mobile crash reports and backend logs, reproduce on a supported device or emulator, and determine whether the defect is client-side, API-related, or caused by platform-specific behavior.

What information should be included in an escalation to Engineering?

An escalation should include a concise summary, business and user impact, severity, reproduction steps, expected versus actual behavior, timestamps, affected versions, correlation IDs, relevant logs or Sentry events, SQL findings, and troubleshooting already performed. I would also state my current root-cause hypothesis, supporting evidence, and any safe workaround or rollback option.

SupportYourApp is a global Intelligent Support-as-a-Service company serving leading technology businesses in more than 30 countries, and is hiring a fully remote T3 Support Engineer in the EU. You will investigate escalated backend, database, API, and integration issues, analyze logs and metrics, query production databases, implement low-risk fixes, and document solutions for Engineering. The stack includes SQL, PHP and/or JavaScript/TypeScript, AWS, Sentry, Grafana, REST, GraphQL, and potentially React Native and analytical databases. The role offers a fixed Monday–Friday overnight schedule, USD compensation, a supportive international culture, no time tracking, and strong opportunities for professional growth.