6. Interview preparation

Having a deployed project is the asset. Being able to discuss it confidently is what converts the asset into an offer. The deployed Music Time Machine sets up a small set of predictable interview questions: why SQLite, why Railway, how does OAuth refresh, how do you handle rate limits, what would you change if you had to scale it. This section gives you the STAR (Situation, Task, Action, Result) framework for those questions, prepared answers for the five you'll be asked most often, a live-demo strategy that recovers gracefully when something breaks mid-pitch, and a practice plan to lock the answers in before your next interview.

The STAR method for project discussion

STAR is a structured framework for answering behavioral and technical questions. It prevents rambling, ensures you hit key points, and makes your responses memorable. Here's how to apply it to your Music Time Machine project:

Situation

Set context. What problem were you solving or what goal were you pursuing? Keep this brief (10-15 seconds).

Example: "I wanted to build a portfolio project demonstrating OAuth, database design, and production deployment. I chose Spotify's API because it offered complex authentication and interesting data for analytics."

Task

What was your specific role or challenge? What technical problem needed solving?

Example: "The main challenge was handling OAuth token refresh in production while maintaining database persistence across deployments. Most tutorials skip these production realities."

Action

What did you do? This is the technical meat. Be specific about your implementation decisions and why you made them.

Example: "I implemented a Config class validating environment variables on startup, preventing silent failures. I chose Railway with persistent volumes for SQLite rather than PostgreSQL because the data access patterns didn't require joins across multiple concurrent users. I wrote retry logic for Spotify's rate limits using exponential backoff."

Result

What was the outcome? Quantify when possible. What did you learn?

Example: "The application handles 100+ Spotify API calls per session without errors, persists data across 20+ deployments, and stays within the monthly usage included in Railway's Hobby plan. I learned that SQLite scales further than expected with proper indexing, and that production OAuth debugging requires careful URL matching."

STAR Response Length

Aim for 60-90 seconds per STAR response. Shorter feels incomplete. Longer risks losing the interviewer's attention. Practice until you naturally hit this range without checking a timer.

Prepare answers for these five questions

Technical interviews about portfolio projects follow predictable patterns. Prepare structured answers for these five questions:

"Walk me through this project"

What they're assessing: Can you explain complex systems clearly? Do you understand the architecture?

Your response: Give the 30-second elevator pitch (problem → solution → impact), then offer to dive deeper into specific areas: "I can explain the OAuth flow, database schema, deployment process, or playlist generation algorithm depending on what interests you most."

"What was the hardest problem you solved?"

What they're assessing: How do you handle challenges? What's your debugging process?

Your response: Use STAR. Pick OAuth redirect URI mismatches, database persistence across deployments, or Spotify rate limiting. Explain your systematic debugging approach: reading logs, isolating variables, testing hypotheses. Show you don't just try random fixes until something works.

"Why did you choose [technology X] over [technology Y]?"

What they're assessing: Do you make informed technical decisions or follow tutorials blindly?

Your response: Explain trade-offs. "I chose SQLite over PostgreSQL because my access patterns are single-user, read-heavy queries on time-series data. SQLite's simplicity meant I could focus on application logic instead of database administration. If I needed concurrent writes or complex joins, PostgreSQL would make more sense."

"How did you handle [specific technical aspect]?"

What they're assessing: Deep technical knowledge. Can you explain implementation details?

Your response: Get specific. If they ask about OAuth: explain authorization code flow, token storage in server-signed Flask sessions (never the database, never logs), refresh token logic, and redirect URI validation. If they ask about database: describe schema design, indexing strategy for timestamp queries, and how you handle migrations. Show you understand the "why" behind your code, not just the "what."

"What would you do differently if you rebuilt this?"

What they're assessing: Self-awareness. Ability to evaluate and improve your own work.

Your response: Discuss legitimate improvements, not fundamental rewrites. "I'd add comprehensive logging with structured log levels instead of print statements. I'd implement caching for frequently accessed Spotify data to reduce API calls. I'd consider async API calls for playlist generation to improve performance. These are optimizations, not design flaws: the current architecture works well for the requirements."

Avoiding "I'd Rewrite Everything" Trap

When asked what you'd change, avoid suggesting you'd completely rebuild the project differently. This signals poor initial planning or lack of confidence in your decisions. Instead, discuss incremental improvements that build on the existing foundation. Frame changes as optimizations or feature additions, not fundamental mistakes.

Live-demo strategy

If you're asked to demonstrate your application during an interview, follow this sequence:

Open with the URL: Share your Railway URL and have the site already loaded. This avoids awkward pauses waiting for pages to load.

Show the happy path first: Walk through a successful user flow: authentication, generating a playlist, viewing analytics. Demonstrate it works reliably.

Highlight technical implementation: As you demonstrate features, mention the underlying technology: "When I click generate, the application makes authenticated requests to Spotify's API using the OAuth token we obtained during login, then filters tracks based on listening timestamps stored in SQLite."

Adapt to their interests:

If they're interested in frontend work, discuss responsive design, Chart.js configuration, or user experience decisions.

If they're interested in backend systems, discuss Flask routing, OAuth token management, database schema design, or how you handle Spotify's rate limits.

If they're interested in data work, discuss SQL query optimization, time-series data modeling, how you calculate "musical evolution" metrics, or the playlist scoring algorithm.

If they're interested in DevOps, discuss your deployment process, environment configuration, persistent volumes for SQLite, monitoring Railway metrics, or your CI/CD pipeline.

Pull Up the Code:

Offer to show specific code: "Want to see how the playlist generation works? I can walk through the algorithm." Share your GitHub repository and navigate to relevant files. This demonstrates comfort with your own codebase and ability to explain technical concepts.

The Demo Advantage

Most candidates talk about projects hypothetically. You can show yours working live, explain technical decisions with concrete examples, and answer follow-up questions by demonstrating features in real-time. This confidence separates you from candidates without deployed projects.

Interview practice recommendations

Preparation transforms nervousness into confidence. Spend 2-3 hours practicing before your first technical interview.

Record yourself: Use your phone or computer webcam to record yourself answering the five interview questions. Watch the recordings critically. Notice filler words ("um," "like"), pacing problems, or unclear explanations. Re-record until you can deliver each response naturally in under 2 minutes.

Practice the demo: Screen-record yourself walking through your deployed application. Narrate what you're showing: "This is the analytics dashboard. I'm clicking the date range selector to show how monthly listening patterns changed over time." Aim for a smooth 3-4 minute demonstration hitting all major features. Practice until you can do it without referring to notes.

Refine your technical explanations: Practice explaining OAuth 2.0, database schema design, or your deployment strategy to someone non-technical. If you can't explain it simply, you don't understand it well enough. Use analogies: "OAuth is like a valet key for your car: it grants limited access without giving away full control."

Time yourself: Most STAR responses should be 60-90 seconds. Longer risks losing the interviewer's attention. Shorter suggests lack of depth. Practice until you hit this sweet spot naturally.

Get feedback: If possible, practice with a friend, mentor, or career coach. Ask them to play interviewer and give honest feedback. Where did you lose them? What explanations needed clarity? What impressed them most?

The Morning-Of Routine

On interview day, spend 10 minutes reviewing your STAR responses and technical decision explanations. Visit your deployed URL to ensure it's working. Have your GitHub repository open in a tab. This preparation takes minimal time but prevents the panic of "what did I build again?" moments during the interview.