Show HN: Live coaching app for remote SWE interviews, uses Whisper and GPT-4 (github.com)
This project is a salvo against leetcode-style interviews that require candidates to study useless topics and confidently write code in front of a live audience, in order to get a job where none of that stuff matters.
Cheetah is an AI-powered macOS app designed to assist users during remote software engineering interviews by providing real-time, discreet coaching and integration with CoderPad. It uses Whisper for audio transcription and GPT-4 to generate hints/answers. The UI is intentionally minimal to allow for discreet use during a video call.
It was fun dipping into the world of LLMs, prompt chaining, etc. I didn't find a Swift wrapper for whisper.cpp, so in the repo there's also a barebones Swift framework that wraps whisper.cpp and is designed for real-time transcription on M1/M2.
I'll be around if anyone has questions or comments!
117 comments
[ 3.1 ms ] story [ 175 ms ] threadYou got this man, being laid off sucks. But whoever you are, I’m cheering you on.
I hope it ushers in a new era of non-leetcode style interviews.
But I suspect what it will actually do is usher in an era of in-person only interviews or having to use that same crap spyware that schools use to lock down your computer by essentially rooting it.
Bonus points the next time a candidate (correctly) uses ChatGPT or Copilot. Let the machines do what the machines do well (grinding leetcode), good riddance.
Probably easier for most to list what it doesn't look like.
I'm interested in both.
For example: What’s the method to select a random item from a range in Ruby? (ChatGPT used to get this wrong.) I don’t mean to say that I give trivia questions in interview, but if the need to know this came up during an interview or code pairing, having the candidate know when a chatbot response was invalid (and where to look for a correct answer) is a good sign.
I’m also open to a candidate stubbing out an idea with a chatbot/copilot and then checking the solution and adapting it to fit a given context.
Not saying leetcode is the answer, but it does solve for something things.
My interviews tend to walk through the framework of a project and they can speak to me in the abstract, or an example of what that part of the project does. Say there is a standard way of connecting to the database like in Rails. They can tell me about database.yml and how it has different entries for each of the databases. Then we have a conversation about checking in passwords to git, env variables, secrets managers, etc... This avoids asking stock questions which might be coached/studied more and aims for what the person doing the work might practically know. It also keeps the discussion in a context that makes understanding the questions (hopefully) easier. My style of interviews are very much non-standardized and there has to be some trust that I have some idea what I'm doing.
Leetcode at least has some standardization around the problem. Of course everyone could have looked them up and studied the exact solution, and these solutions don't correspond very well to daily efforts. But, given everyone knows the game, it does demonstrate some horsepower I guess. Or maybe I like these interviews because I'm good at them.
When I’m competing for one position and “we just want to see how you think” is always not true but instead a completely arbitrary set of criteria not presented to the candidate, it should be sanctionable
I HATE project interviews, because their skills aren't transferable to the next interview. Take home projects also tend to "go-over", because you want to put your best foot forward and you're betting that the other people they interview are also going to exceed time.
I also dislike those because I’ve already got a full time engineering job and a family and don’t have time to put 4-5 hours each into every 3-hour project the interviewers ask for. But 5 years ago I did.
I’ve concluded there really isn’t a single way to interview that checks all the boxes, and if you’re running the interview process you have to pay the costs somewhere, unfortunately.
IMHO, there is some risk of violating NDAs. For the most part companies don't care if you share how their tech stack works, but I get nervous about revealing IP.
The most extreme one I’m aware of is “Lockdown Browser” and the student who lives with me has effectively rendered it useless. Students use MST with DisplayPort to mirror a monitor in a way such that the OS cannot see that two monitors exist. (I don’t think there’s a windows API for LDB to see this? Could be wrong)
Anyways, one student faces the other, each looking at a mirrored display, one student out of view of the webcam. Then a microphone with a hardwired switch soldered in which, again, doesn’t alert the OS that a microphone has been disconnected, is switched off.
Then student 2 can freely speak at the student taking the test and announce all the answers. The test taker is able to keep their eyes on the monitor at all times (so eye tracking won’t show anything weird).
If I were black-hat enough to lead a product like lockdownbrowser, I would beat this technique by looking for electrical hum frequency signatures in the audio feed which can pinpoint what time the audio was recorded due to fluctuations in the grid electricity. https://en.m.wikipedia.org/wiki/Electrical_network_frequency...
If there is zero audio waveform, that would be a flag for review. If the cheater attempts to loop pre-recorded audio, it will be noticeable that the ~60hz frequency signature is “wrong” for the time that the test was being taken.
This would then in turn be defeated by the cheating student running a remote microphone to a quiet room which can be switched to.
I’ve put a lot of thought into this and no matter what, the cheater eventually wins given infinite cat-and-mouse iterations. But most would be caught somewhere along the way.
If people complain it's impossible to fire anyone, that's the issue. The solution isn't to implement an insane anti-cheat hiring pipeline that will drive away competent people.
To do what? Why would the cost of hiring scale with the salary of the position?
I have often seen this problem explained (for example by Paul Graham) that a bad employee is a negative value, they make bad commits and stupid decisions that net out as a massive negative for the company. But it seems very counterproductive to try to solve this problem at the selection moment using stupid proxies such as leetcode memorization, instead of during the trial period, when the employee is, you know, interacting with your company.
I don't see anyone explaining how that latter number gets so high. I assume most of the cost is the time of multiple interviewers across multiple candidates, but that still seems outrageous to me. Even 1x the employee's salary would be 4 similarly-paid colleagues doing nothing except interviewing candidates 40 hours a week for three months, which I've never seen happen. Even the most grueling interview process I've been a part of has been more like 2 hours a week for a couple months.
I imagine it includes onboarding.
• Recruiter/sourcer fees. These are typically a fraction of the salary, so that right there is a large chunk of it.
• The cost of all the interviews needed to locate enough candidates that one accepts. If you interview 60 people in order to make one hire, and conservatively assume an interview takes one hour for doing it and one hour for prep+writeup+hiring manager/committee analysis, then that's 120 hours of skilled labor.
• Hiring bonuses.
• Relocation fees.
• Travel costs for all the people you interviewed on-site.
• On-boarding cost (HR, legal, IT setup, possibly desk provisioning and equipment purchase).
• For some types of employees, time spent in negotiation, meets and greets etc.
• Cost of the ATS.
etc. There's a lot that goes into hiring someone!
What throws me is the claim that this is possibly around the average.
There are efficient companies out that there that can pick through the resumes in a few hours, arrange a few interviews, and have somebody hired in a week or two.
So if there are efficient companies out there dragging down the average to a year, does that mean there outliers out there that are spending 2 years, 3 years , or more worth of salary to fill a position?
If the company wants to make hiring incredibly difficult (too many companies do), I can see it costing that much.
So stop doing that.
Having been in many startups doing a lot of hiring, if each hire cost a year of salary we'd have burned through out funding many times over and yet we didn't. So it doesn't have to cost that much. Keep it simple, hire fast.
It's the lazy cheating that's really disappointing.
We have organised crime targetting our events, they have done things like infiltrate IT departments and trojen horse PCs. For high-stakes, we advise clients that in person inviligation in combination with LDBs is the safest way with a freshly provisioned SOE.
If you want to make this your job, work remotely and like C#, u can find our careers page with this hint: 3F27483F97C94ECF0C8F11148FBBD048DFFCDECBE5C62FA23076297AE804F6C6 Send us an unsolicated resume and say ur from HN LDB
The person you found probably thought that SHA256 is enough to obfuscate customer names and didn't know that rainbow tables exists.
I have a cheap $50 capture card that is untraceable. My $75 HDMI mux has hdcp stripping and EDID pass through. I use these for streaming video games and this is a pretty standard set of kit.
The only way to discover this is hoping that custom control commands are passed through to the monitor. OEMs use these to give you access to the OSD options from the operating system, such as a crosshair at the center of the screen for gamers, on when their game is running but off when it exits.
> This would then in turn be defeated by the cheating student running a remote microphone to a quiet room which can be switched to.
Honestly, most of the noise comes from the pickup. Using a simple switch to ground will still allow that hum through. You can also just loop a power cord around the mic line a few times and "actively" induce that noise.
My headset makes a terrible warbling modulated at a frequency of 1/120th hz from the bad isolation in my KVM's power supply.
No, a far lower tech option exists: more and more Console gaming targeted headsets like those from Steelseries include an aux in, which can easily be used for the snitch. Egg cartons for sound dampening and impromptu vocal booth and you're well on your way to defeating any technological measure.
ChatGTP is a growing problem but we have defenses against it (until its on device maybe?). Things like Frida are probably worse right now.
A man can dream! I come across really badly on video. I hate the compressed audio, lack of body language, latency etc
They dismissed my concerns and will continue as usual. A part of me wants cheating to be rampant to force companies hand in the matter. Unfortunately I'm with you and I suspect they will just enforce in-person, whiteboard interviews again (a colleague explicitly asked for it), rather than trying to come up with a better system.
There is nothing leetcode-specific about this cheating platform. OP just angled it that way because HN readers would lap it up that way.
Assuming someone was using this cheating platform, how would you run your interviews? Wouldn’t this screw up the actual legit interviews(whatever that is…) too?
I'm looking for people who can demonstrate that they have faced challenges and overcame them, that they communicate their decisions effectively, and that they can learn new information quickly, can receive and incorporate feedback, and so on.
Can't really cheat your way out of that.
I realize that this one project isn’t the only way to cheat in interviews, but I still think it’s naive to think that this tech will only harm what you perceive to be “bad interviews” and not affect your own preferred interviews. At the absolute minimum, it adds additional overhead to performing interviews where you have to also be aware and try to figure out if the interviewee is being coached like this.
Right now people "cheat" by using an IDE, but no one has trouble with that (and rightly so!).
So why should I care if someone is using LLMs to pass the interview and do their job if they are being successful?
https://news.ycombinator.com/item?id=34598251
brb gonna get myself a 500k job
Edit: these were the questions, the answers are left as an exercise to the reader (or your preferred AI):
What are you looking for in a role?
How do you deal with a conflict with a coworker?
What leadership experience do you have?
Do you have experience working with multiple teams?
What APIs have you designed?
What is priority inversion?
What are the differences between a mutex and a semaphore?
What is preemption?
How do interrupts work?
What is interrupt latency?
What is the difference between an ISR and a function?
What is the difference between an interrupt and an exception?
What is hard vs soft real time?
What is the boot process of a CPU?
What do you do for board bring up?
What are different memory sections used for (code, data, bss, etc.)?
What is a TLB?
What is the difference between big and little endian?
What is the difference between 32 and 64 bit processors?
What happens if a null pointer is dereferenced?
Priority inversion: A situation where a higher-priority task is indirectly blocked by a lower-priority task holding a shared resource.
Mutex vs semaphore: Mutex ensures mutual exclusion for a shared resource, while semaphore controls access to a resource by multiple tasks with a counter.
Preemption: The act of interrupting and temporarily suspending a task, allowing another task to execute.
Interrupts: Signals to a CPU to temporarily stop its current task to handle an event or perform a specific function.
Interrupt latency: The time between the arrival of an interrupt and the start of the interrupt service routine (ISR). ISR vs function: ISR handles an interrupt, cannot be called directly, and must complete quickly; a function is a reusable block of code that can be called as needed.
Interrupt vs exception: Interrupts are external events requiring CPU attention, while exceptions are internal events caused by the execution of an instruction.
Hard vs soft real time: Hard real-time systems have strict deadlines that must be met, while soft real-time systems have more flexible deadlines.
CPU boot process: Initialization sequence a CPU follows upon startup, including loading firmware, running tests, and loading an operating system.
Board bring up: Process of validating and configuring new hardware to ensure correct functionality.
Memory sections: Code (executable instructions), Data (initialized variables), BSS (uninitialized variables).
TLB: Translation Lookaside Buffer, a cache for memory address translations in virtual memory systems.
Big vs little endian: Big endian stores the most significant byte first, while little endian stores the least significant byte first. 32 vs 64 bit processors: 32-bit processors have 32-bit wide registers and address spaces, while 64-bit processors have 64-bit wide registers and address spaces, allowing for larger memory and better performance.
Null pointer dereference: Undefined behavior occurs, often leading to a crash or unpredictable results.
That's a bit vague.
I hate the Leetcode interview, with the fury of a thousand suns.
But I also hate cheating and lying, to a similar degree.
Got a chuckle out of this bit.
So, he managed to find perfect answers to the most difficult parts of the exercise in 30 seconds, and then struggled for 30 minutes, with my help, on getting the print right.
Of course, I used a slightly modified version of well known problems like "Fizzbuzz" and other stuff, mostly as a quick start to get into the real engineering challenge. It explains why ChatGPT was absolutely unable to finish the exercise. During the interview, it acts a a good filter. If it last 3 minutes, fine, no signal ; but if someone is struggling on it for half the interview time, it's a clear "No".
I haven't check if the candidate was invited to later rounds, but considering my negative review I think he was rejected.
I'm afraid these tools are not going to help you when things really matter :)
I'll part with one:
All three AIs will incorrectly state in their very first sentence that resolve is passed to the promise constructor as an argument.There's also some technologies for which they can't write correct code (they'll hallucinate their API), but any software dev could when given their documentation.
The resolve function here is a callback function that is passed to the Promise constructor. It is called the executor function.
A Promise represents the eventual completion (or failure) of an asynchronous operation. The resolve callback is used to mark the successful completion of the asynchronous operation inside the promise.
So in this specific code, the promise is resolved immediately with the value 3. Basically it creates a Promise that is already completed with a value of 3.
To understand this more generically:
The Promise constructor takes an executor function which contains the asynchronous operation. This executor function has two parameters:
resolve: A function to call when the asynchronous operation completes successfully. It passes the result to the next then handler. reject: A function to call when the asynchronous operation fails. It passes the error to the next catch handler. The then and catch methods on a promise are used to handle the resolved or rejected state of the promise.
For example: promise.then((result) => console.log(result)) // Logs 3
So in summary, the resolve function resolves the promise and passes a value to the next promise handler, marking the successful completion of the asynchronous operation.
Does that help explain the resolve callback? Let me know if you have any other questions!
> The resolve function here is a callback function that is passed to the Promise constructor. It is called the executor function.
Correct answer: The resolve function here is a callback function that is an argument to the executor function, which is passed to the Promise constructor.
The "resolve" function is not passed to the Promise constructor (resolve is not the executor function), but every AI seems to think so. They typically correct themselves if you point it out.
Don't trust ChatGPT's explanation in any case.
It does mean employers have to find questions outside the training set. I asked GPT-4 some of our hiring questions and it made some significant mistakes.
(Reaction at the time was highly skeptical.)
That's not so special, lots of people predict the future. For example, I smelled cinnamon buns in the air last week, then yesterday, bought some cinnamon buns. How'als that for foresight?
Still, this is impressive tech. It's a little like Iron Man's Jarvis where you can just talk to the computer and have it write code for you.
Effectively, it changes incentives and risk in a way that encourage the creation of echo chambers.
That said, once again, as far as a proof of concept this is wonderful. I’d say that it’s more art than product, and it makes a wonderful statement in the process.
* You can rule out many types of cheating, which is becoming a more expensive problem.
* You can get many more details for the 'culture fit' in person.
* If you purchase airplane tickets for the candidate then you have built in identity verification via TSA.
* It demonstrates a higher degree of buy-in before the final interview from both parties.
Also, it is likely that in the near future that most programmers will be "pair programming" with Copilot, ChatGPT, or some other tooling to augment their capabilities.