The title is irritating, conflating AI with LLMs. LLMs are a subset of AI. I expect future systems will be mobs of expert AI agents rather than relying on LLMs to do everything. An LLM will likely be in the mix for at least the natural language processing but I wouldn't bet the farm on them alone.
That battle was long-ago lost when the leading LLM companies and organizations insisted on referring to their products and models solely as "AI", not the more-specific "LLMs". Implementers of that technology followed suit, and that's just what it means now.
You can't blame the New Yorker for using the term in its modern, common parlance.
Agreed, and ultimately it's fine because they're talking about products not technology. If these products go in a completely different direction and LLMs become obsolete the AI label will adapt just fine. Once these things hit common parlance there's no point in arguing technical specificity as 99.99% of the people using the term don't care, will never care, and language will follow their usage not the angry pedant.
This is something I immediately noticed when ChatGPT first released. It was instantly called "AI", but previous to that, HN would have been up in arms that it's "machine learning" not actual intelligence. For some reason, the crowd here and everywhere else just accepted the misuse of the word intelligence and let it happen. Elsewhere I can understand, but people here know better.
Intentionally misconstruing it as actual intelligence was all a part of the grift from the beginning. They've always known there's no intelligence behind the scenes, but pushing this lie has allowed them to take in hundreds of billions in investor money. Perhaps the biggest grift the world has ever seen.
Sure I can. If someone writing for the New Yorker has conflated the two concepts and is drawing bad conclusions because of it, that’s bad writing.
A good writer would tease apart this difference. That’s literally what good writing is about: giving a deeper understanding than a lay person would have.
The computing power alone of all these gpus would bring a revolution in simulation software. I mean 0 AI/machine-learning, just being able to simulate much more things than we can.
Most industry-specific simulation software is REALLY crap, most from the 90s and 80s and barely evolved since then. Many stuck on single core CPUs.
It could be a nice side-effect of having all this “LLM hardware” built into everything, nice little throughput focused accelerators in everybody’s computers.
I think if I were starting grad school now and wanted some easy points, I’d be looking at mixed precision numerical algorithms. Either coming up with new ones, or applying them in the sciences.
If the New Yorker published a story titled "What if LLMs Don't Get Better Than This?" I expect the portion of their readers who understood what that title meant would be pretty tiny.
Indeed, and the title itself contains an operational definition of AI as “this” (LLM’s) - if AI becomes more than “this” then the question has been answered in the affirmative.
AI is what people think AI is. In the 80s, that was expert systems. In the 2000s, it was machine learning (not expert systems). Now, it is LLMs — not machine learning.
You can complain, but it’s like that old man shaking their fist at the clouds.
The title annoys me more because if doesn't mention anything about time. AI will almost certainly get a good bit better eventually. The questions will it in the next couple of years or will we have to wait for some breakthrough.
I'm amused they seem to refer to Marcus and Zitron as "these moderate views of A.I". They are both pretty much professional skeptics who seem to fill their days writing AI is rubbish articles.
AI is LLMs now. Similar to how machine learning became AI 5-10 years ago.
I'm not endorsing this, just stating an observation.
I do a lot of deep learning for computer vision, which became AI a while ago. Now, when you use the word AI in this context, it will confuse people because it doesn't involve LLMs.
- Building plastic self organising maps (Lang 2002) using Python CUDA build to parallelise the more expensive bits. Also fancy building the directed graph half in Unity 3D.
- Also doing some data engineering pre-training and AIIA at work but no deets, sadly.
I was asked by an SME to code on a whiteboard for an interview (in 2005? I think?). I asked if I could have a computer, they said no. I asked if I would be using a whiteboard during my day-to-day. They said no. I asked why they used whiteboards, they said they were mimicking Google's best practice. That discussion went on for a good few minutes and by the end of it I was teetering on leaving because the fit wasn't good.
I agreed to do it as long as they understood that I felt it was a terrible way of assessing someone's ability to code. I was allowed to use any programming language because they knew them all (allegedly).
The solution was a pretty obvious bit-shift. So I wrote memory registers up on the board and did it in Motorola 68000 Assembler (because I had been doing a lot of it around that time), halfway through they stopped me and I said I'd be happy to do it again if they gave me a computer.
I work for a faang subsidiary. We pay well below average salary and equity. We finally got one nice perk, a very good 401k match. A few months later it was announced that the 401k match would be scaled back "to come in line with what our parent company offers". I thought about asking "will be getting salaries or equity in line with what our parent company offers?" but that would have been useless. Management doesn't care. I'm job hunting.
Folks getting mad about whiteboard interviews is a meme at this point. It misses the point. We CANT test you effectively on your programming skillbase. So we test on a more relevant job skill, like can you have a real conversation (with a whiteboard to help) about how to solve the problem.
It isn't that your interviewer knew all the languages, but that the language didn't matter.
I didn't get this until I was giving interviews. The instructions on how to give them are pretty clear. The goal isn't to "solve the puzzle" but instead to demonstrate you can reason about it effectively, communicate your knowledge and communicate as part of problem solving.
I know many interviewers also didn't get it, and it became just "do you know the trick to my puzzle". That pattern of failure is a good reason to deprecate white board interviews, not "I don't write on a whiteboard when i program in real life".
> We CANT test you effectively on your programming skillbase. So we test on a more relevant job skill, like can you have a real conversation (with a whiteboard to help) about how to solve the problem.
Except, that's not what happens. In basically every coding interview in my life, it's been a gauntlet: code this leetcode medium/hard problem while singing and tapdancing backwards. Screw up in any way -- or worse (and also commonly) miss the obscure trick that brings the solution to the next level of algorithmic complexity -- and your interview day is over. And it's only gotten worse over time, in that nowadays, interviewers start with the leetcode medium as the "warmup exercise". That's nuts.
It's not a one off. The people doing these interviews either don't know what they're supposed to be looking for, or they're at a big tech company and their mandate is to be a severe winnowing function.
> It isn't that your interviewer knew all the languages, but that the language didn't matter.
I've done enough programming interviews to know that using even a marginally exotic language (like, say, Ruby) will drastically reduce your success rate. You either use a language that your interviewer knows well, or you're adding a level of friction that will hurt you. Interviewers love to say that language doesn't matter, but in practice, if they can't know that you're not making up the syntax, then it dials up the skepticism level.
They generally do not know what they are looking for. They are generally untrained, and if they are trained, the training is probably all about using leetcode-type problems to give out interviews that are sufficiently similar that you can run stats on the results and call them "objective", which is exactly the thing we are all quite correctly complaining about. Which is perhaps anti-training.
The problem is that the business side wants to reduce it to an objective checklist, but you can't do that because of Goodhart's Law [1]. AI is throwing this problem into focus because it is basically capable of passing any objective checklist, with just a bit of human driving [2]. Interviews can not consist of "I'm going to ask a question and if you give me the objectively correct answer you get a point and if you do not give the objectively correct answer you do not". The risk of hiring someone who could give the objectively correct answers but couldn't program their way out of a wet paper bag, let alone do requirements elicitation in collaboration with other humans or architecture or risk analysis or any of the many other things that a real engineering job consists of, was already pretty high before AI.
But if interviewing is not a matter of saying the objectively correct things, a lot of people at all levels are just incapable of handling it after that. The Western philosophical mindset doesn't handle this sort of thing very well.
[2]: Note this is not necessarily bad because "AI bad!", but, if all the human on the other end can offer me is that they can drive the AI, I don't need them. I can do it myself and/or hire any number of other such people. You need to bring something to the job other than the ability to drive an AI and you need to demonstrate whatever that is in the interview process. I can type what you tell me into a computer and then fail to comprehend the answer it gives is not a value-add.
It is a gross oversimplification but you can look at the Western mindset as being a reductionistic, "things are composed of their parts" sort of view, and the Eastern mindset as a holistic mindset where breaking things into their components also destroys the thing in the process.
The reality isn't so much "in between" as "both". There is a reason the West developed a lot of tech and the East, despite thousands of years of opportunity, didn't so much. But there is also a limit to the reductionistic viewpoint.
In this case, being told that the only way to hire a truly good developer is to make a holistic evaluation of a candidate, that you can not "reduce" it to a checklist because the very act of reducing it to a checklist invalidates the process, is something that a lot of Western sorts of people just can't process. How can something be effectively impossible to break into parts?
On the other hand, it is arguably a Western viewpoint that leads to the idea of Goodhart's law in the first place; the Eastern viewpoint tends to just say "things can't be reduced" and stop the investigation there.
This is highly stereotypical, of course, and should be considered as an extremely broad classification of types of philosophy, and not really associated directly with any individual humans who may happen to be physically located in the east or west. Further as I said I think the "correct" answer is neither one, nor the other, nor anything in between, but both, so I am not casting any shade on any country or culture per se. It is a useful, if broad, framework to understand things at a very, very high level.
When I joined my current team I found they had changed the technical test after I had interviewed but before I joined. A couple of friends also applied and got rejected because of this new test.
When I finally got in the door and joined the hiring effort I was appalled to find they’d implemented a leetcode-esque series of challenges with criteria such as “if the candidate doesn’t immediately identify and then use a stack then fail interview”. There were 7 more like this with increasingly harsh criteria.
> So we test on a more relevant job skill, like can you have a real conversation (with a whiteboard to help) about how to solve the problem.
Everybody says that, but reality is they don't imho. If you don't pass the pet question quiz "they don't know how to program" or are a "faker", etc.
I've seen this over and over and if you want to test a real conversation you can ask about their experience. (I realize the challenge with that is young interviewers aren't able to do that very well with more experienced people.)
Do I? yes. I also teach my students that the goal of an interview is to convince the interviewer you are a good candidate, not to answer the questions correctly. Sometimes they correlate. Give the customer what they need not what they asked for.
Do I see others doing so? sadly no.
I feel like a lot of the replies to my comment didn't read to the end, I agree the implementation is bad. The whiteboard just isn't actually the problem. The interviewers are.
Unless they change mentality to "did this candidate show me the skills i am looking for" instead of "did they solve puzzle" the method doesn't matter.
The replies are addressing the reality of the interview landscape that fails to live up to your theory of how whiteboarding interviews should be.
It's all well and good that you and other "wise interviewer" commenters on HN actually grok what the point of interviews are, but you are unicorns in the landscape.
I don't think you made it to the last paragraph either:
> I know many interviewers also didn't get it, and it became just "do you know the trick to my puzzle". That pattern of failure is a good reason to deprecate white board interviews, not "I don't write on a whiteboard when i program in real life".
> The goal isn't to "solve the puzzle" but instead to demonstrate you can reason about it effectively, communicate your knowledge and communicate as part of problem solving.
...while being closely monitored in a high-stakes performance in front of an audience of strangers judging them critically.
> Why are you on a thread about Google-style interviews?
For the same reason you wrote "Google-style". Because this thread is specifically about those interviews happening not at Google.
Oh, maybe you misunderstood their question. When they suggested Google wasn't relevant, they meant the company culture at Google itself because that's what you were talking about.
Perhaps. I'd even say it's part of what is taught as part of a PhD.
But if someone was ready for your exact question by having the right interview practice/experience, or they just don't care about your job so there's no stakes. Then you still aren't measuring what you think you are.
+1 to all this. It still surprises me how many people, even after being in the industry for years, think the goal of any interview is to “write the best code” or “get the right answer”.
What I want to know from an interview is if you can be presented an abstract problem and collaboratively work with others on it. After that, getting the “right” answer to my contrived interview question is barely even icing on the cake.
If you complain about having to have a discussion about how to solve the problem, I no longer care about actually solving the problem, because you’ve already failed the test.
I think you're severely underestimating how much just about every software company has bought into the FAANG philosophy, and how many candidates they get who can answer those questions correctly.
Yes if you don't communicate clearly, you will get points deducted. But if you can't answer the question nearly perfectly, its basically an immediate fail.
Unfortunately I used to think this was the main purpose of the interview as well, but have been proven wrong time and time again.
The only thing that matters in most places is getting to the optimal solution quickly. It doesn't matter if you explain your thought process or ask clarifying questions, just get to the solution and answer the time and space complexity correctly and you pass.
Like others have said I think this is a symptom of the sheer number of people applying and needing to go through the process, there is no time for nuance or evaluating people on if you would actually like to work with them or not.
> I was asked by an SME to code on a whiteboard for an interview (in 2005? I think?). I asked if I could have a computer, they said no. I asked if I would be using a whiteboard during my day-to-day. They said no. I asked why they used whiteboards, they said they were mimicking Google's best practice.
This looks more like a culture fit test than a coding test.
I am so happy that you did this. We vote with our feet and sadly, too many tech folks are unwilling to use their power or have golden handcuff tunnel vision.
>I was allowed to use any programming language because they knew them all (allegedly).
After 30 years of doing this, I find that typically the people who claim to know a lot often know very little. They're insecure in their ability so much that they've tricked themselves into not learning anything.
What is the functional difference between copying an AI answer and copying a StackOverflow answer, in terms of it being "cheating" during an interview?
I think the entire question is missing the forest for the trees. I have never asked a candidate to write code in any fashion during an interview. I talk to them. I ask them how they would solve problems, chase down bugs, or implement new features. I ask about concepts like OOP. I ask about what they've worked on previously, what they found interesting, what they found frustrating, etc.
Languages are largely teachable, it's just syntax and keywords. What I can't teach people is how to think like programmers need to: how to break down big, hard problems into smaller problems and implement solutions. If you know that, I can teach you fucking Swift, it isn't THAT complicated and there's about 5 million examples of "how do I $X" available all over the Internet.
> Languages are largely teachable, it's just syntax and keywords.
This is like "learning a natural language is just 'cramming vocabulary and grammar' - voila, you've become a fluent C1 speaker". :-)
Seriously: if you argue this way, you have only seen a very biased set of programming languages, and additionally, your knowledge of these programming languages is very superficial (i.e. you have never gotten to the "interesting"/"deep" concepts that make this particular programming language special, and which are hard to replicate in most other programming languages).
I think the argument is that for a good chunk of business work, you don't need to use the "interesting"/"deep" concepts. Sure, you'll need time to adapt to the idioms of the language you're using, but following examples you can be just as productive as others in a relatively short time.
But companies don't pay high salaries for the 80% mundane and easy tasks you do day to day. They pay for the 20% that is challenging and especially for that 1% of problems that occur only once every few months or years. If that 80% was 100% of the job then the company could pay 1/2 to 1/3rd the amount by outsourcing it.
I disagree, companies pay based on the problems you can solve to make them money or help achieve organizational goals. One of those ways can be coding, but there are many others.
No, the comparison to natural languages is what is whack. If you understand the underlying concepts that programming languages pick and choose from as features, all you have to learn is what keywords map to those concepts and the language's syntax.
The comparison to natural languages would be if you could learn one language and then quickly pick up every other language of that "class" after learning how that single language works. That's not really how natural language works at all, but it does work with programming languages.
> If you understand the underlying concepts that programming languages pick and choose from as features, all you have to learn is what keywords map to those concepts and the language's syntax.
If you understand the grammatical topics that a natural language picks, all you have to learn is what word transformation rules map to those concepts, and the natural language's vocabulary.
> The comparison to natural languages would be if you could learn one language and then quickly pick up every other language of that "class" after learning how that single language works.
There do exist books on this topic (though more commonly for language families). See for example
> If you understand the grammatical topics that a natural language picks, all you have to learn is what word transformation rules map to those concepts, and the natural language's vocabulary.
Yes, and then do that in real time while you're having a conversation with someone who's been learning the language since they were a baby. It is an unreasonable comparison.
In C, implicit type narrowing/widening behavior stumped me as a noob working on noob problems. “Deep C Secrets” was a revelation when I finally found it.
> Languages are largely teachable, it's just syntax and keywords.
That's only true for a subset of programming languages, and it requires you to already know how to program in at least another language of the same family. Knowing Java will not help you with Haskell, but it will help you with C#.
I have to deal with students using AI to cheat on homework and exams, and I can't allow them to not even learn the basic concepts.
They could convince you with buzzwords, get hired, and then feed all problems to the AI until it reaches a point where the codebase is too big for the context, and then all their prompt “engineering” experience is basically useless.
That is the future I am trying to prevent.
Until the AI can code a full system like SAP, or an Operating System, or a Photoshop clone, by itself, we need some people in the loop, and the more knowledgeable the people, the better.
It's not useless because some people will lie and cheat. Over the years, I've interviewed hundreds of people and a substantial minority could not write even the simplest code. Many will say they would be able to filter out such people after a conversation. But, IMO, the fact that they are still able to get hired at some places shows how wrong that often is.
> That's only true for a subset of programming languages, and it requires you to already know how to program in at least another language of the same family. Knowing Java will not help you with Haskell, but it will help you with C#.
In this context, to a large extent it holds. Yeah. It’s probably more true of mainstream languages roughly related to each other, but in an interview, you’re not testing for knowledge of syntax and keywords. You’re trying to test for ability to build and problem solve.
I share your concern about prompt “engineers” who don’t understand the underlying codebase, language or system. But I don’t know what to do about it in the context of a technical interview.
I've accidentally been using an AI-proof hiring technique for about 20 years: ask a junior developer to bring code with them and ask them to explain it verbally. You can then talk about what they would change, how they would change it, what they would do differently, if they've used patterns (on purpose or by accident) what the benefits/drawbacks are etc. If they're a senior dev, we give them - on the day - a small but humorously-nasty chunk of code and ask them to reason through it live.
Works really well and it mimics the what we find is the most important bit about coding.
I don't mind if they use AI to shortcut the boring stuff in the day-to-day, as long as they can think critically about the result.
Yep. I've also been using an AI-proof interview for years. We have a normal conversation, they talk about their work, and I do a short round of well-tested technical questions (there's no trivia, let's just talk about some concepts you probably encounter fairly regularly given your areas of expertise).
You can tell who's trying to use AI live. They're clearly reading, and they don't understand the content of their answers, and they never say "I don't know." So if you ask a followup or even "are you sure" they start to panic. It's really obvious.
Maybe this is only a real problem for the teams that offloading their interviewing skills onto some leetcode nonsense...
This is a fine way. I’ll say that the difference between a senior and a principal is that the senior might snicker but the principal knows that there’s a chance the code was written by a founder.
And if the Principal is good, they should stand up and say exactly why the code is bad. If there's a reason to laugh because it is cliche bad, they should say so.
If someone gave me code with
if (x = 7) { ... } as part of a C eval.
Yeah, you'll get a sarcastic response back because I know it is testing code.
What I think people ignore is that personality matters. Especially at the higher levels. If you are a Principal SWE you have to be able to stand up to a CEO and say "No, sir. I think you are wrong. This is why." In a diplomatic way. Or sometimes. Less than diplomatic, depending on the CEO.
One manager that hired me was trying to figure me out. So he said (and I think he was honest at the time). "You got the job as long an you aren't an axe murderer."
To which I replied deadpan: "I hope I hid the axe well." (To be clear to all reading, I have never killed someone, nevermind with an axe! Hi FBI, NSA, CIA and pals!)
Got the job, and we got along great, I operated as his right hand.
Wonderful! My PhD was in stream anomaly detection using dynamic neural networks in 2003. Can't wait to go deep through this paper and find out what the latest thinking is. Thanks, OP.
The only one that directly annoys me is not being able to have threaded comments at the PR level. https://github.com/github/roadmap/issues/552 You can do it with "quoting", which is fine if there are two of you but turns into a mess if there's more than that.
They've said that they're watching the discussions for feedback, so I hope they listen and implement that one.
Happy that they are being transparent (rather than letting the issues rot), annoyed that they appear to be prioritising marginally useful AI stuff for basic UX.
Shameless plug but this is one of the many GitHub code review limitations I set out to fix when I created CodeApprove (https://codeapprove.com).
You can comment on any line, a whole file, or a whole PR and all comments are threaded and tracked to resolution. They are never hidden because they’re outdated or because the discussion is too long.
Also commenting on random irrelevant changed line because you can't comment on unchanged ones (but they might need changes due to rest of the PR).
Github code review is horrible and I think it's actually worse than not having anything at all because now it's hard to convince people we should switch to something better. "Oh I don't want to learn another tool, github is good enough"
IMO education is still built around Victorian structures and needs to be reworked from examinations downwards. Examinations are an exercise in being good at examinations, not proficiency in the subject. Once you strip that away the you wind back all the structures that feed it. You can see this working at schools designed for the neuro diverse. Those students simply can't sit and listen to a teacher all day, so each student learns in their own way and are better of for it.
Arguing about the effectiveness of edtech is like complaining there wasn't a viola on the Titanic's band.
What, specifically, is an example of an exam not measuring proficiency? If an exam is well designed, the student will need to figure out what is being asked and use their mastery to provide an answer.
> What, specifically, is an example of an exam not measuring proficiency
Not op, but a few examples:
1. Test structures that reward good time management. The paper SAT is a good example of this. The early items in a section are (were?) easy, the middle items were medium difficulty, and the toughest items were towards the end. A good test take would manage their time so that they spent the most amount of time on questions that could improve their scores — later questions for high achievers, but the middle questions for folks who were missing a lot of questions in that range.
2. Test structures that reward endurance. Again, SAT is a good example. How often have examinees sat down in a multi-hour high-stakes testing situation before taking the SAT. “Not often enough to feel comfortable” is usually the answer. I have taken some foreign language proficiency tests that were also multi-hour long endeavors. I practiced answer old exam questions in a testing environment, so the tests were easy for me. Some of my peers did not, and fatigue seemed to be a part of their challenge.
3. I took some “issue spotter” tests in college. I had never heard of or seen an issue spotter test before. I bombed my first one. My professor kindly walked me through things he knew I knew the answers to that would what given me credit. I aced all future issue-spotter exams. Side note: familiarity with test/question format seems to matter for better students, but it largely doesn’t for unmotivated students. Many studies on familiarity with test/question format show no correlation, but my personal experience (as a test giver) is that this is due to lumping the unmotivated and ambivalent examinees with the folks who notice, care, and take action.
There are many more answers to your question, but the above are few decent examples.
I think test prep allowing people to increase SAT scores is actually a useful feature not a bug.
If you’re the kind of person who’s going to put extra effort to add a few points to your results, you are also the kind of person more likely to do well in collage classes.
I agree in general with what your idea, but this sort of assumes a few things that aren’t always true:
1. Examinee is aware of test prep and its potential benefits. Definitely not always true in low socioeconomic status (SES) families, especially ones with no family members who have been to college.
2. Examinee can afford said test prep courses and/or materials. Library and online are “free” options, but we are back to assuming that the examinee has easy access to a library and/or the internet and knows how to find said materials.
There are many, many students who would do well in college if they had some insight on how to do college. The US has a lot of wasted potential due to our public school focus on bringing up the low achievers to the exclusion of developing those with high achiever potential.
Some private schools and most public schools in “good” neighborhoods have programs and cultures that cater to those with high potential, but these schools only address a relatively small portion of the student population with high potential, imho.
It's not really being the "kind of person who’s going to put extra effort" and more the "kind of person who is privileged enough to have parents that care about their education, know that outside resources exist, and have the time and money to utilize those resources".
I think the SAT is a ludicrous setup given that most people never see anything like it in their lives again but the practice of studying for passing an exam of some kind is an absolutely invaluable skill
> I think the SAT is a ludicrous setup given that most people never see anything like it in their lives again
Yeah, I guess.
I think the issue is that the folks best suited to get the most out of college don’t really need to prep much to absolutely crush the SAT.
Most people are just woefully underprepared.
> but the practice of studying for passing an exam of some kind is an absolutely invaluable skill
Yep. Learning how to study, learn, and prep for a test are good skills to have.
That said, for folks who have done well in a semi-rigorous school environment and read the right things (high-brow periodicals), very little test prep is actually needed to get them close to their theoretical max score.
There are a few catches, though:
- Some people in the US have an incredibly irrational fear of math.
- The math curriculum is super-slow and limited for those who like math, often turning them away from it (or at least the high school math classes).
- Most folks have no idea what university-level literacy looks like. Doing things like reading “high-brow” periodicals gives high school students most of the vocab and text structures covered in the SAT.
A good example in the UK is teaching students the FOIL technique for algebraic expansion. Students typically can expand (ax+b)(cx+d) because they've learnt a recipe but cannot expand say (ax2+bx+c)(dx+e).
Many schools here focus on such tricks (nix the tricks was a great book focusing on such things) as schools here are judged on pass/fail rates.
In general, exams are an excellent way to assess students en masse at their ability to remember similar problems but not inherent problem solving techniques. The latter I've found is possible to teach 1to1 but far harder with a class of varying abilities.
That, to me, is not a problem with the exam though. It's a problem of teaching to a special case and not the general case. If you want to find fault, it's in the incentive system. But I don't see how the exam itself is the problem.
Well I won't reiterate all of 'bad education' by Bryan Caplan but to my mind exams are imperfect because:
1. Schools are not equal. It's not fair to compare students when they usually have no choice over their teachers.
2. Exams cover an arbitrary syllabus controlled by undemocratic exam boards.
3. Topics are chosen by exam boards that can be examined not by importance.
4. Students who perform poorly under stress of exam conditions are punished for it.
5. Exams serve no real purpose. Children are not chickens being graded for sale. They're at best a weak signal of aptitude.
I would much prefer exams to serve as a prerequisite of sitting a future course rather than an assessment at the end. That way teachers can actually teach rather than continuously repeat the same content.
the inability the generalize the foil procedure to an expression with more than 2 variables speaks more to the non mathematically oriented population just sucking at generalizing things. i have found this to be a very “you have it or you don’t” type of thing, not really something that can be taught
I've always had a difficult time wrapping my head around this acronym. What counts as "outer"? What counts as "inner"? And yes, when there are more than two items (not necessarily variables!) to be multiplied, you suddenly have to ignore this little trick, because now it's confusing to know what to do about the middle stuff -- and it doesn't take into account non-commutativity either.
And yes, some of the problem may be due to my (very recently diagnosed! at least, formally) autistic mind. But I cannot help but think that if someone with a PhD in math struggles with and largely ignores "FOIL", then the problem may be with the technique, and not with the people who don't understand it.
i never found foil stupid, but i also only have a bachelors in math. maybe this was because i had already been exposed to multiplying polynomial expressions, beyond just a 2 term * 2 term by the time i had learned it in school, but i never found it particularly complicated to grasp. foil was never taught to me as the only way to multiply polynomials, rather, an easy algorithm to apply in a certain case. the goal is for you to make the connection that oh, in a 3x2 case, u have to multiply each term in the 3 with each term in the 2, etc.
i think your problems with foil can be extended to the general way math is taught. at least for me, it was always full of tricks, little rules that can be broken sometimes, and i was constantly learning new things that made me realize my old teachers had taught us tricks to shortcut solutions.
“Well designed? is doing heavy lifting here. You can get very good at specific test formats in terms of time management, common tricks, etc.
Actual tests include things like: Multiple choice questions were providing answers aids answering the question. Short responses / fill in the blank generally mean people can just regurgitate answers they don’t understand. Essay responses sound great, except you can’t answer many questions and essays writing is a separate skill which heavily influences final scores.
More broadly tests are time limited so can’t test skills that take long periods of time to demonstrate a major issue for say programming.
> More broadly tests are time limited so can’t test skills that take long periods of time to demonstrate a major issue for say programming.
Every programming class I've taken, in high school or college, was project based where the main source of grade were actual programs I wrote which actually did something.
The one exception perhaps being the AP test for AP CS.
English exams for ESL students are a great example.
Getting good grades in those exams requires that you know the criteria for evaluating each part of the exam and how to tailor your answer to that criteria. For example, if the exam asks you to write a short movie review you are expected to follow the formula for reviews and show that you can use certain specific grammar constructs.
If you know English well but you don't practice the exam before you will get a mediocre grade, simply because you didn't follow the tacit guidelines that you are expected to know.
Exams are a poor measure of proficiency. Proficiency is gained by doing and stretching a skill over time. You can measure that in small increments than a periodic exam. At the end of a period, a student would have a body of work to demonstrate proficiency rather than relying on a single day.
When I taught at university there was a disparity between exam grades and the physical body of work they had submitted over the years. You'd see the grade and be shocked the did so badly. The grade reflected proficiency in examinations, not in the subject.
I agree 100%.
With ChatGPT at everyone's disposal with entire humanity knowledge in generative form, we need to completely rethink the concept of teaching and learning.
There are so many opportunities to deliver personalized Ivy League level education in your native language of choice, for essentially pennies/free to everyone around the world on demand
In my opinion without exams, kids will never solidify what they learn. It’s usually pretty easy to think you have a solid grasp of some thing until you’re actually asked to solve a brand new problem.
Then I would ask anyone to keep building on knowledge rather than training for an arbitrary benchmark. Filling your short-term memory with knowledge to be then dumped straight after will get you a good exam mark but doesn't mean you have anything close to a solid grasp. Most schools (in the UK in particular) optimise for grade outcome because that's how they are judged, that's not the same thing as being good at a task.
It kind of is. I’m a firm believer in that knowledge comes from doing. Even the trades use exams. If you want to become a welder, you have to weld five particular welds, then get graded. There’s no better way to gauge someone’s proficiency at something while also letting that person find out what their weaknesses are.
Yeah definitely agree. Tech at my kids school just means all the tests and homework are done on a computer instead of on paper, but it is still the same format as it has always been.
Would be cool to see more open ended long running projects instead of the standard 'lecture > homework > test' pipeline. Kids are also given a crazy amount of leeway and teachers/parents will drag a negligent kid to their diploma. Even if a kid tried to fail they would be met with a bunch of counselors and special classes begging him to put forth a minimal effort. It might help if we moved the guardrails back a bit and let kids know that failure is a very real possibility.
reply