Introducing My Latest Project: An AI Interview Assistant for Job Seekers
So, I've been working on something... interesting. It's an AI assistant that can actually represent candidates in the first round of job interviews. Yes, you read that right—because apparently, we've collectively decided that showing up to your own job interview is so last decade.
Here's how this magnificent creation works:
The system ingests everything about a candidate—CV, professional experience, cover letter, LinkedIn, GitHub, portfolio, and any preferences they've specified (salary expectations, location, contract type, the usual existential career questions). Then, armed with this treasure trove of personal data, my AI conducts automated interviews directly with HR departments or their equally soulless chatbots.
In real-time, it generates responses as if the candidate themselves were speaking—complete with soft skills, communication style, and structured answers. Because nothing screams "hire me" like algorithmic authenticity. If it encounters a question beyond its training data, it politely pings the candidate: "Hey, need some input here before I completely botch your career opportunity."
What this technological marvel offers: 24/7
Availability – Candidates can "attend" interviews while sleeping, working their current job, or contemplating the futility of modern employment practices. The AI never sleeps, never complains, never has a bad day.
Personalization – Responses tailored to each candidate's actual experience and skills. It's them, just... optimized. Debugged. Free of human error like nervousness or accidentally mentioning you follow your passion for underwater basket weaving.
Performance Analytics – Post-interview analysis of how well the candidate matched job requirements. Because self-awareness is overrated—let the machine tell you how you did.
Training Mode – Candidates can practice various interview scenarios and get feedback. Think of it as rehearsing for the day when neither interviewer nor interviewee is actually human anymore.
And yes, the circle closes beautifully.
I'm building a system where AI talks to AI about human employment while humans... what? Watch Netflix? It's efficient. It's scalable.
It's absolutely ridiculous when you think about it for more than thirty seconds.
But hey, if companies are going to screen candidates with automated systems and generic chatbots, why shouldn't candidates fight fire with fire?
Welcome to the employment arms race nobody asked for.
I'm either solving a real problem or hastening our irrelevance. Probably both.
I can compare programming and refactoring large code bases in C and C++, Rust, and Python, from system and parsing and protocol libraries to asynchronous multi-threaded servers in the mentioned languages.
Refactoring Rust projects is clearly the easiest because the compiler and type system ensure the program is correct at least in terms of memory access and shared resource access. It doesn't protect me from memory leaks and logical errors. But since Rust has a built-in testing framework, it's quite easy to prepare tests for logical errors before refactoring.
C/C++ refactoring is a nightmare - especially in older projects without modern smart pointers. Every change in ownership or object lifetime is a potential disaster. In multi-threaded applications it's even worse - race conditions and use-after-free bugs only manifest at runtime, often only in production. You have to rely on external tools like Valgrind or AddressSanitizer.
Python has the opposite problem - too much flexibility. You can refactor an entire class, run tests, everything passes, but then in production you discover that some code was dynamically accessing an attribute you renamed. Type hints help, but they're not enforced at runtime.
Rust forces you to solve all these problems at compile time. When you change a lifetime or ownership, the compiler tells you exactly where you need to fix it. This is especially noticeable in async code - in C++ you can easily create a dangling reference to a stack variable that an async function uses. In Rust, it simply won't compile.
The only thing where Rust lags a bit is compilation speed during large refactors. But that's a small price to pay for the certainty that your code is memory-safe.
Another area where Rust absolutely excels is when using AI agents like Claude Code. It seems to me that LLMs can work excellently with Rust programs, and thanks to the support of the type system and compiler, you can get to functional code quickly. For example, Claude Code can analyze Rust programs very well and generate documentation and tests.
I think Rust with an AI agent has the following advantages:
Explicit contract - the type system enforces clear function interfaces. The AI agent knows exactly what a function expects and what it returns.
Compiler as collaborator - when AI generates code with an error, it gets a specific error message with the exact location and often a suggested solution. This creates an efficient feedback loop.
Ownership is explicit - AI doesn't have to guess who owns data and how long it lives. In C++ you often need to know project conventions ("here we return a raw pointer, but the caller must not deallocate it").
Fewer implicit assumptions - in Python, AI can generate code that works for specific input but fails on another type. Rust catches these cases at compile time.
You can use the parking_lot mutex implementation crate, which includes support for deadlock detection. Personally, I also try to avoid using Tokio's async mutexes.
Rust uses fat-pointers to references and raw pointers to dynamically sized types (DSTs) – slices or trait objects. A fat pointer contains a pointer plus some information that makes the DST "complete" (e.g. the length, or in the case of trait objects, the additional data is a pointer to the vtable).
Generally, you have, under control, where you store your fat-pointer.
I was a C++ programmer for 25 years. Last 3 years, I'm using Rust language in my daily job and for all my hobby projects. I will not return to work in C++ again. No money can make me to change my decision. Nowadays, programming is a pure joy for me again. This was not the case when I had to work with C++.
I started learning piano a year ago. I'm 36 year old. Unfortunatelly piano is my third instrument which I play. First instrument i started with was accoustinc guitar almost 25 years ago. Last three years I'm trying to learn how to play bass guitar. When I switched to bass guitar I took the learn process very seriosly and study what ever I have found (music theory, notation - sight reading). This book really helps me a lot with piano: http://www.pianopractice.org/ since there are not study pieces and notation but it describe how to learn and how to practice smartly.
I'm self taught and I believe that you can learn on any instrument at any age you start. You have to learn smarter not harder. There are so many interesting videos and online teacher on youtube nowdays it makes learning easier.
Especially with my rules:
- Prefer simple, boring solution
- Before adding complexity to work around a constraint, ask if the constraint needs to exist.
- Remember: The best code is often the code you don't write.