Careers in data and AI

Use a combination of full, differential or incremental and transaction log backups based on RPO, store copies offsite or immutable, and test restores regularly with documented timings against RTO. Interviewers want restore testing mentioned.

Check the execution plan, look for missing or unused indexes, stale statistics, locking or blocking, parameter issues and changes in data volume. Test fixes in non-production and measure improvement. Show a systematic approach.

Least-privilege accounts and roles, no shared admin accounts, encryption in transit and at rest, patching, network restriction, auditing of privileged and sensitive access, and protecting backups. Mention avoiding application accounts with owner rights.

Replication keeps copies synchronized for availability and failover, but it also replicates mistakes such as accidental deletes or corruption. Backups provide point-in-time recovery. You need both. This distinction is a common interview check.

Use version-controlled migration scripts, test in staging with realistic data, plan for locking and duration, schedule a window, back up first and have a rollback script. Coordinate with application releases.

Atomicity means all or nothing, consistency means rules and constraints hold, isolation means concurrent transactions do not interfere, and durability means committed data survives failures. Give an example such as a money transfer.

Describe the symptoms, impact, diagnosis, fix, communication and follow-up improvements. Interviewers look for calm, methodical handling and learning.

Track availability, connections, query performance, blocking, storage growth, replication lag, backup success and error logs, with alerts on thresholds and trends. Review capacity regularly.

Use parameterized queries or prepared statements so user input is never concatenated into SQL, apply input validation as a second layer, use least-privilege database accounts and avoid detailed errors to users. Mention ORMs help but can still be misused. Interviewers want the primary fix stated first.

In a secrets manager or vault, injected at runtime through environment or managed identity, never in source code or container images. Rotate them, scope them narrowly and scan repositories for accidental commits. Explain what you would do if a secret was pushed: revoke and rotate it immediately, then clean history.

Check that the change does what the ticket asks, is readable, has tests, handles errors and edge cases, and has no security issues such as unvalidated input or leaked secrets. Give specific, respectful comments and approve only when you would be comfortable owning the code. The interviewer listens for both quality and teamwork.

Static analysis, dependency and license scanning, secret scanning, container image scanning, infrastructure-as-code checks and possibly dynamic testing in a staging environment. Set thresholds that fail builds for serious issues, and protect the pipeline itself with least-privilege credentials and branch protection.

Authentication proves who a user is; authorization decides what they can do. A common authentication mistake is weak session handling; a common authorization mistake is checking permissions only in the user interface instead of on every server request, allowing access to other users' records. Specific examples impress interviewers.

Check whether your code actually uses the vulnerable function and whether it is reachable, upgrade to a fixed version, run tests, and deploy. If no fix exists, apply a workaround or replace the library. Communicate with security and track it. This shows risk assessment plus speed.

Explain the bug, how it was found, how you fixed it, what you communicated and what you changed to prevent similar bugs, such as adding tests. Interviewers want ownership and learning, not perfection.

Use clear names, small focused functions, consistent style, meaningful tests, useful comments explaining why rather than what, and documentation for setup. Keep changes small and reviewable. Showing empathy for future readers is what the interviewer is checking.

Pick a project from your portfolio, explain the problem, architecture, key trade-offs, how you tested and deployed it, and what you would do differently. Be ready for follow-up questions on any part. Depth and honesty matter more than size.

Unit tests check small pieces of code in isolation and are fast. Integration tests check that components work together, such as code and a database. End-to-end tests exercise the whole system as a user would and are slower and more brittle. A good answer mentions balancing them, with most tests at the unit level.

Cover valid and invalid credentials, empty fields, input length and special characters, account lockout, password reset, session handling, error messages that do not reveal which field was wrong, accessibility and injection attempts. Structure the answer by functional, security and usability cases.

A clear title, steps to reproduce, expected versus actual results, environment details, severity, and evidence such as logs or screenshots. It should let a developer reproduce the issue without asking questions. Interviewers value precision.

Compare environments, dependency versions, configuration and data, look for timing issues or test order dependence, check logs and rerun to see if it is flaky. Fix the root cause rather than retrying until green. This shows disciplined debugging.

Automate tests that are repeated often, stable, high value or error-prone to do manually, such as regression suites and API checks. Keep exploratory and rapidly changing areas manual. Consider maintenance cost. Interviewers want judgement, not automation of everything.

Check authentication and authorization on every endpoint, including accessing other users' objects, input validation, rate limiting, error handling, sensitive data in responses, and transport security. Use both automated scanners and manual tests. Mention testing in a safe, authorized environment.

Describe the defect, how you assessed and communicated its impact, the decision made with the team, and how you improved the process to catch it earlier. Interviewers value calm communication and process improvement.

It re-runs existing tests after changes to ensure previously working features still work. It matters because fixes and new features often break other areas, and automated regression suites in CI catch this quickly.

Personal data is any information relating to an identifiable person, such as name, email or device identifiers. Sensitive categories include health, biometric, financial or other data needing extra protection under many laws. Interviewers want awareness that definitions vary by regulation.

Data minimization, purpose limitation, lawful basis and transparency, retention limits, security, individual rights and accountability. Apply them early through privacy by design and a privacy impact assessment.

When a project introduces new processing of personal data, especially high-risk processing. It describes the data flows and purpose, assesses necessity and risks to individuals, and records mitigations and approvals. Show it is practical, not just paperwork.

Verify the requester's identity, locate data across systems, check for exemptions and other people's data, respond within the legal deadline in a clear format, and log the request. Mention having a repeatable process.

Check whether the new purpose is compatible with the original purpose and lawful basis, whether notice or consent is needed, minimize the data used and document the decision. Offer a compliant path rather than just saying no.

Classification identifies personal and sensitive data so the right controls apply. Retention schedules ensure data is deleted when no longer needed, reducing breach impact and legal exposure. Explain enforcing both technically where possible.

Contain it, assess what data and people are affected and the risk to them, involve legal and privacy leads, meet notification obligations to regulators and individuals within required timeframes, and document everything. Coordination with incident response is key.

Describe the need, the requirement, the options you explored and the solution that met both, with the outcome. Interviewers want pragmatic problem solving.

Start from business goals and capabilities, assess the current state, define a target architecture and a roadmap of steps, and evaluate options against cost, risk and value. Involve stakeholders and review regularly. Interviewers want to see business thinking, not just technology preferences.

Consider whether it differentiates the business, total cost including maintenance, time to value, skills available, integration, security and vendor lock-in. Build only what gives competitive advantage. Structured criteria are what interviewers want.

Consistent naming and versioning, clear contracts and documentation, strong authentication and authorization, pagination and error standards, backward compatibility and monitoring. Explain how standards help many teams integrate safely.

Make it visible in a register with impact, prioritize debt that blocks goals or creates risk, fund it as part of the roadmap and prevent new debt through standards and reviews. Show you treat it as a business decision.

Understand the problem it solves, evaluate it against criteria such as security, supportability and cost, consider a time-boxed pilot, and either update the standards or recommend an alternative with reasons. This shows openness with governance.

Identify critical services and their availability needs, remove single points of failure, use redundancy across zones, design for graceful degradation, test failover and backups, and monitor. Link design choices to recovery objectives.

Describe the stakeholders, how you built your case with evidence, addressed concerns and reached agreement, and the result. Influence is central to architecture roles, so interviewers listen closely.

Use diagrams at multiple levels of detail, record key decisions with context and alternatives, keep it versioned and close to the work, and update it when things change. Useful documentation is short and current.