This screen is after the "walk us through your resume, explain what you've built" conversation, where we ask them about specific challenges, decisions they made, etc.
Everyone who has made it to this screen has already spoken to us about their previous work and at least seemed to have some skill in their general area of programming.
What we're testing for doesn't need to be memorized or practiced. Anyone who can program for money should be able to do things like FizzBuzz, repeat the pattern in Pascal's Triangle with a for loop, or come up with a basic strategy to eliminate non-primes.
Even if you blow the part of the interview where you need to identify prime/not-prime, as long as you show us that you have a process you're fine.
Maybe we just suck at or are too charitable when it comes to processing what candidates have claimed to have done - I'm unsure.
Contribution to OS projects would allow us to bypass this screen altogether, but great point.
Haha we might have to switch to Rust just to ease our interviewing woes here - we're primarily a PHP/Laravel shop, and have tried to be as charitable as possible to candidates by allowing them to program in the language they're strongest in. Perhaps we need to change that.
The screen we're doing is meant to filter out the frauds/imposters and so far has a 100% success rate, but unfortunately we've caught three out of the last three people who have made it to that point. It's become a huge waste of time.
Maybe we just need to curate candidates from OS contributors to prevent this, or something of that nature.
Having the GPT answer beforehand would allow us to confront them about it sooner, but at that point we're definitely not hiring them since they thought it a good idea to use an LLM to cheat on questions they should be able to do in their sleep.
Interesting that you're asking the candidate to have their hands visible. We haven't wanted to have to go that way, but we might.
I disagree with the carpenter-hammer analogy here pretty strongly.
We're basically trying to figure out if they can code generally, or if somehow they've skated by in their last positions without the fundamental skills of programming.
I'm not sure how, but we've come across a number of programmers from F1000 companies that can't seem to hit some of the basics in their chosen language.
LLMs have their place as a tool, but before we empower them with the latest and greatest programming assistance, we want to make sure that they have the skills to do things like critically interpret the output of Copilot, etc.
We want to make sure we're that the people we hire possess the skills they claim, and that they won't serve as a very-slow wrapper for the LLM tools we already pay for.
Not really, since failing FizzBuzz basically ends the interview.
That said, Pascal's and Non-Primes allows us to do a few minutes of basic, "that looks great, what are some ideas for optimizing it" work together once they have established that they have the basics of programming.
I am incredibly open to suggestion on better ways to evaluate people for both (a) their basic ability to code, and (b) their ability to think about code/optimization.
Great point on the Sieve - knowing it off of the top of his head wasn't itself a red-handed indicator of cheating, but claiming that he'd used it in a B2B SaaS app was. Especially given that he wasn't able to explain how he'd allegedly used it.
The candidates we're bringing into this screen typically have 1-3 prior positions on their resume, so the point here is to throw them some softballs that they should be able to crank through with some ease to demonstrate that their basic programming skills are there.
We've had experiences where people who have held legitimate programming jobs at F1000 companies struggle greatly with some of the basic questions that I've listed above. I'm not sure why, but it's the case.
We try as best as we can to adjust for anxiousness, I know that programming in front of others can suck, but all the same we're just trying to establish, "before we go forward, can you do some elementary tasks that anyone with your claimed experience should be able to do"
The screen we are performing here is a basic "can you program" type of evaluation.
We've run into a number of people with seemingly-decent resumes (several positions as engineers at reputable albeit non-FAANG companies like insurers or e-commerce firms) who have struggled to complete basic tasks like the Pascal's Triangle question mentioned above.
The intent here is to toss them a couple of softballs that they should be able to knock out of the park, almost like if they were helping a younger sibling with CS 1XX or 2XX level work.
We're not against the use of Copilot, etc. once onboarded. We just want to make sure that these candidates possess basic skills that their resumes would suggest they mastered years ago.
This is generally what we do and what raised our suspicions in the first place - they both could "walk us through" their code, but had trouble explaining why they did certain things, how they could improve things, etc.
We thought that the approach you've outlined would generally be good enough, and has led us to catch instances where people are leaning heavily on LLMs, but our issue now is that everyone appears to be using these things. Admittedly, our sample size here is low (n=3). But it's still frustrating nonetheless.
We're definitely not doing any "Leetcode style" interviews over here - these are basic "can you perform basic programming tasks as you've stated" type questions.
How do you reconcile recent extreme weather and weather events with your apparent view that most climate reporting is fake? Or that recent years have all been the hottest in modern human history?
Your comment isn't very useful, and not in the spirit of HN with regard to helpful/thoughtful discussion. It's just complaining without evidence.
This does exactly the opposite of that. Reading the text of the bill, every part of it, especially Section (B), is couched in the principle of "not interfering."
For Example: "A PERSON WHO IS THE SUBJECT OF POLICE CONTACT MAY RECORD THE ENCOUNTER IF THE PERSON IS NOT INTERFERING WITH LAWFUL POLICE ACTIONS"
So if a police officer determines that your recording of a traffic stop is "interfering" with their investigation, that it's causing you to cooperate too slowly, that your holding up the phone is limiting their ability to see into the vehicle, etc., they're well within the law to instruct and even force you to stop recording.
While a court may find that their determination of "interference" was insufficient, and that they were wrong to take your phone or arrest you for refusing to stop recording, it will be a determination made after you were arrested or fined or your phone was confiscated.
It produces a chilling effect on the ability of citizens to record the police, and gives police more law to throw at citizens to try and intimidate them into not recording their activity.
I think that one major issue here is that while you and I likely have the time and other resources to go fight something like this if it were to occur, many of the people for whom this law will be most relevant (areas where the most police activity occurs are often in impoverished areas) do not have that same luxury.
If you're barely scrapping by on an hourly job, and then get picked up or fined for this, oftentimes your only option is to accept the plea so you can get out of the courtroom and try to get back to work.
This law serves to provide a means for the police to place that burden on people who cannot bear it.
I've been (lightly) thinking about this with regard to digital identity.
One of the few use cases that I find very compelling with regard to blockchain/web3 tech is as a means of ID/auth much in the same way that many sites now offer options to log in with FB/Google/etc.
One big obstacle (I imagine, I haven't really looked into this that far) is that of the password reset. Some non-trivial amount of people will forget the passwords to their identity tool, and in this scenario there's no central power with the capability to reset it for them.
The simplest option is to designate trusted friends who you could delegate authority to in order to perform some multi-sig reset, but then there's the issue of a FriendCoup. If you strike it big and turn on or ignore your friends, there's nothing stopping them from getting together and performing a takeover. Even if there are individual objectors, because it's blockchain, everything's public, and these are identity wallet contraptions, everyone knows who the hold out is and can lean on them or find some way to get their password, etc.
Even outside of a FriendCoup scenario, a FedCoup scenario where the government just leans on your buddies to grant them control is pretty plausible.
So I guess the question is, what sort of strategy for this is FriendCoup/FedCoup resistant but still grants the necessary amount of delegated power?
Not entirely relevant to the above, as doing this pen and paper for a password manager is a little harder for outsiders to game given that the holders aren't public, but still a question I've been batting around. Curious about anyone's thoughts/ideas or any existing work in this space.
Edit: After thinking about this for an extra minute, if it's not time sensitive a deadman switch could probably do it. If your friends perform the multi-sig and you haven't logged in in X days, then and only then will the reset occur, so you can void an attempt. That said, falls down on the FedCoup scenario since you'd presumably have restricted access to the internet.