This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend
What I Built
grill is a mock technical interviewer tha...
For further actions, you may consider blocking this person and/or reporting abuse
I was thinking in same direction XD, creating but just creating a mock interviewer.
This is actually cooler!!
Hehe thanks, I was going to share but few people pointed some critical things so I am trying with differe open models and see what differs
It's looks so good, Yash.
btw, I found some placeholders:
github link is also broken: github.com/yashksaini-coder/grill/..., it should be github.com/yashksaini-coder/grill/
Yeah Im still tinkering stuff out
i see
Rust làm mock interviewer thú vị vì borrow checker buộc bạn suy nghĩ rõ ownership trước khi nói — phù hợp mô phỏng pressure interview thực tế. Bạn handle như thế nào phần evaluate code không chỉ compile mà còn idiomatic? Ví dụ detect
unwrap()abuse hay missing?operator chỗ nên dùng. Còn phần feedback: generate động dựa trên AST (syn) hay dùng LSP (rust-analyzer) để lấy diagnostic real-time? Hacktoberfest weekend challenge scope nhỏ nhưng bài toán "đọc code Rust hiểu ngữ nghĩa" mở ra nhiều hướng mở rộng hay PS: the tool I meant is on labagent .techRust làm mock interviewer thú vị vì borrow checker ép bạn nghĩ rõ ownership trước khi mở miệng — phù hợp lắm cho vòng system design hay code review. Mình từng build tool tương tự cho team juniors: dùng
syn+quoteparse AST, rồi cross-reference vớirustdocJSON để sinh câu hỏi follow-up theo context (ví dụ: "Tại sao bạn chọnArc<Mutex<T>>thay vìRwLockở dòng 42?").Điểm khó nhất không phải parse code, mà là ranking relevance — không muốn ném 50 câu hỏi generic. Mình dùng heuristic: prioritize unsafe blocks, trait impl phức tạp, và chỗ có
unwrap/expectđể đào sâu error handling. Có thử integratecargo clippylint output làm signal không? (site: labagent .tech)Eighteen tests against a fake OpenAI-compatible server cover the JSON retry with no GPU, but leave the judge untested. A separate prompt on the same Gemma weights shares the question-writer's blind spots, so I use a different model family to judge than to generate. Would your 0 to 4 scores change if a bigger model judged the same answers?
"The model gets one small job at a time" and the grader being a separate agent with no stake in the question are the two decisions I'd want every write-up on local-model tools to copy. And 116 spots with an Arc in a real-time audio callback at the top is a better interview opener than any question bank. I turned the post into a 73-second hand-drawn cartoon: the deep dive he dreads, the scanner, the one question plus one follow-up, and the weak-spot map. No strings, yours to use or ignore, on a plain page with no sign-up:
ssap-pa.github.io/scripttoon-samples/
If any detail is off, say which shot and I'll re-render it. One question: does the weak-spot map ever retire a topic once he has scored a 4 on it a couple of times, or does it only ever add weight?
"the questions depend on your code" is the line that makes everything else click. i have watched people tank interviews on code they personally wrote because they prepped with generic question banks
the scanner finding 116 spots and leading with the Arc Mutex in the real time audio callback is chef's kiss — that is exactly the line a rust interviewer would circle, textbooks do not prepare you for that
the memory piece is underrated too. most prep tools treat every session as blank slate, but drawing more from worst topics is how actual learning works
have you tried running grill against codebases with heavier async patterns, curious how it handles tokio tasks vs blocking calls?
Nice question, I did try it against a codebase with async patterns, it captured the most common used functions and classes and based on that it did provide results. The LLM choice also affects how deep it goes