interview_qna.md

🎤 Interview Q&A - Lab 11: Queryable Job History API with Tests

Below are focused questions and answers based on the concepts, implementation steps, and validation performed in this lab.

1. What was the main goal of this API?

The goal was to expose job execution history through REST endpoints that support querying, filtering, updates, and summary statistics.

2. Why was Flask-SQLAlchemy used?

It simplified database modeling and persistence while keeping the lab lightweight and easy to test.

3. What fields make a job-history record useful for audits?

Fields such as job_name, status, start_time, end_time, duration, user, environment, and error_message provide operational traceability.

4. Why are filters valuable on a /jobs endpoint?

Filters let operators narrow results quickly by status, user, environment, job name, or date without manual post-processing.

5. What did the /jobs/stats endpoint provide?

It returned grouped counts by status and environment to summarize operational activity at a glance.

6. Why were pytest fixtures used in test_api.py?

Fixtures created isolated application and database contexts so the API could be tested predictably and repeatedly.

7. What did the 13 passing tests prove?

They demonstrated that create, read, update, filtering, and statistics behaviors all worked as expected under test conditions.

8. What issue appeared in manual update testing?

Supplying an end_time earlier than the generated start_time produced a negative duration, showing where extra validation would help in production.

9. Why was coverage measurement included?

Coverage helps confirm how much of the application logic is exercised by tests and highlights code paths that need more validation.

10. How does this lab support real engineering work?

Teams often build internal APIs like this for job tracking, release visibility, compliance reporting, and operational analytics.