Do AI detectors work? Students face false cheating accusations

The only solution is to require face-to-face proctored exams and not allow students to use technology of any kind while taking the test. But any teacher doing this will end up with no students signing up for their class. The only solution I see is the Higher Learning Commission mandating this for all classes.

But even requiring in person proctored exams is not the full solution. Students are not used to doing the necessary work to learn. They are used to doing the necessary work to pass. And that work is increasingly cheating. It’s a clusterfuck. I have calculus students who don’t know how to work with fractions. If we did truly devise a system that prevents cheating we’ll see that a very high percentage of current college students are not ready to be truly college educated.

K-12 needs to be changed as well.

As a student, the only thing the next institution will see is GPA, school, major. Roughly in that order. If the cost of not getting an A is exclusion from future opportunities- then students will reject exclusion by taking easier classes or cheating.

As someone who studied physics and came out with a 2.7 GPA due to studying what I wanted (the hard classes) and not cheating (as I did what I wanted) - I can say that there are consequences to this approach.

In my opinion, the solution is to reduce the reliance on assessments which are prone to cheating or which in the real world would be done by computer.

-> GPA can be gamed, as laid out.

-> Take Home assessments can mostly be gamed, I want to assess how you think, now which tools you use.

-> Personality tests favor the outgoing/extroverts

-> On-location tests/leet code are a crapshoot.

What should be best practice here? Ideally something that controls for first-time interviewer jitters.

Onsite interviews with a range of approaches seem to be the best I've found over the years. As much as it pains me, things like fizzbuzz are still useful, because people still lie about their ability to program in languages. If you claim to know C very well and can't knock that out in 5 minutes, and it takes you 45 minutes of prompting, well, you don't know C usefully.

I've seen good results with having a pre-done sort of template program that's missing functionality, and the person completes it out based on comments (for remote interviews), and you can generally tell by watching them type how familiar with the space they are. Again, perfection isn't the goal, but if someone claims to know C very well and is trying to make Javascript syntax work, well, they're full of crap about knowing C.

That said, probably the best approach I've seen for hiring junior dev sorts is a formal summer internship program - and some places have a pretty solid system for doing this, with 20-30 people coming in every summer for a few months. That's a far better way to get to know someone's actual technical skills. In the programs I interacted with, it's safe to assume that if you have 30 people, you'll have about 15 that are "Thank you for your time, good luck..." sorts, maybe 5 or 8 that are "Yeah, you'd probably be a good fit here, and can be trained up in what we need, you'd be welcome back next summer!" and if you're lucky, one or two "HIRE NOW!" sorts that leave the summer program with a job offer.

It's obviously a lot higher effort than interviewing, but the "Throw things at people for three months and see what they do, with a defined end of the program" process seems to be a really good filter for finding quality people.

I recently had an interview and a "skill test" in C. It was proctored by the interviewer in-person. I had so many questions about the questions. It was like, what is the output of "some code" and while obvious, there were some questions where specific CPU architecture mattered:

    #include <stdio.h>

    int main() {
        unsigned int x = 0x01020304;
        unsigned char *c = (unsigned char*)&x;

        printf("First byte of x: 0x%02x\n", *c);
        return 0;
    }

Sure, whatever. Probably dodged a bullet.

  unsigned int x = 0x01020304;
  unsigned char *c = (unsigned char*)&x;

However, on a big endian system, that same value would be stored in memory as [01][02][03][04] - so, reading a byte at 0x100 would return 0x1.

Older ARM systems were big endian, and there are others that run that way, though it's rarer than it used to be. One of the perks of little endian is that if you want to read a smaller version of a value, you can read from the same address. To read that value as an 8, 16, or 32 bit value, I read at the same address. On a big endian system, I'd have to do more address math to do the same thing. It mostly doesn't matter, but it is nice to be able to have a "read of 8 bits at the address of the variable" do the sane thing and return the low order 8 bits, not the high order bits.