I've built a small career platform with a resume builder that supports templates, drag-and-drop editing, live previews, PDF export, and AI-assisted content generation. It also includes an AI voice interview feature: users provide a resume and job description, the system generates interview questions, and users answer through voice to receive basic scoring and feedback.
I'm worried the project will look like a standard CRUD application wrapped around an LLM API, especially since many of these features can be reproduced with a general-purpose AI tool. I'd like to add genuinely technical capabilities that would interest software engineering interviewers and give me meaningful engineering problems to discuss. What should I improve or build next?
4 Answers
The most impressive part may not be another feature—it may be the quality of the implementation. Treat the platform like a real product: isolate users properly, encrypt sensitive data at rest, avoid exposing personal information in logs, validate uploaded resumes and job descriptions, defend against prompt injection, and make account deletion remove all associated personal data. You could also document your security decisions, testing strategy, architecture, and any privacy or compliance considerations.
A strong direction would be a local voice-activity detector and streaming speech-recognition pipeline instead of uploading raw audio to an external API. That gives you real-time engineering challenges such as chunked audio processing, latency management, buffering, interruption handling, noisy input, partial transcripts, and efficient resource usage. Those are more substantial discussion points than simply calling an LLM endpoint.
Consider whether the platform produces useful outcomes rather than just generating resumes and questions. For example, track interview performance over time, identify recurring weaknesses, generate targeted practice plans, and show measurable improvement. The key is to define how feedback is evaluated and avoid pretending that an LLM’s score is automatically objective. A thoughtful evaluation system, explainable metrics, and experiments comparing different feedback approaches would give you much better material to discuss.
If you’ve already invested heavily in this project, you don’t necessarily need to throw it away. Pick one difficult subsystem and take it seriously—real-time audio, privacy and data deletion, scalable document rendering, or evaluation quality. A polished, well-tested system with clear trade-offs is usually more convincing than a long list of shallow features.
That makes sense. I’ll keep the existing product but choose one subsystem to develop deeply and document properly.
That’s helpful. I’ll focus more on security, privacy, and maintainability instead of only adding more visible features.