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.

Tokio mutexes are only useful if a lock needs to be held across suspension points. Since futures can migrate threads between suspension points and most regular mutexes on most platforms do not support being unlocked from a different thread, tokio’s mutex has a very narrow but a well defined use case.

Another use for tokio's mutexes is that they won't block a thread while waiting to acquire the lock (as awaiting a tokio mutex is itself a suspension point). For some use-cases this might not matter, though.

This technique is good for job interviews, when they ask me to solve leetcode problems. I was inspired by the blog:

https://aphyr.com/posts/342-typing-the-technical-interview

and related to Rust, the solution

https://github.com/insou22/typing-the-technical-interview-ru...

Or Typescript https://www.richard-towers.com/2023/03/11/typescripting-the-...

I hope that soon LLMs will generate such notebooks for any scientific paper you ask. That would help to eliminate fake and unrealistic results ones.

Python, the language with global interpret lock, Is not the 2nd best language for everything, especially in the age od multicore processors.

Python is the practical language for when you do your cpu intensive tasks outside of it as a feature, since the GIL isn’t a problem with io parallelism.

You’d do better complaining about still nascent, compared to alternatives, async support or lack of jit in the official implementation.

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've drank C++'s kool aid. I believe in the vision and think of everything in C++ terms.

...I think I could last about 3 months in another language before I'd forgotten too much to go back.

I doubt that's true. I haven't used C++ for many years now. I was in your boat a few years ago (C/C++ since 1990) but now 6+ years Python then Rust centric. I still think in C++ terms when writing rust, although most of the time it's "I would need 10 lines to do this 1 line of rust code were I still using C++."

I dabble in C++ occasionally as a contractor. No problem picking up the new features and making useful contributions.

C++ maps pretty directly into Rust. I found it useful to understand the underlying data representation in memory. For instance https://doc.rust-lang.org/nomicon/repr-rust.html

I moved into managed compiled languages back in 2006, still dabble in C++ pretty much ok, and code is relatively modern (enjoying modules in VC++ nowadays).

same here. I've pounded C++ and C code for 20+ years. Rust is the right tool to replace both of these. Long live Richie (well maybe not him but his work), Kernighan and Stroustrup.

long time C++ programmer here too, 30ish years, but I don't use it for much anymore. While I like that the language has improved, it's just a nicer experience coding in other languages.

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.