Wednesday, 13 May 2026

Seriously, why try to cook Sam Altman?

It's no secret my opinion of Sam Altman isn't exactly high. To me, he's one of those snake oil salesmen that continually hypes up a product that, while interesting in limited scopes, is nowhere what it's purported to be. And he exudes the low-effort vibe of a con artist who flourishes not by being smarter than others, but by picking raving idiots as his target audience.

That said, I don't dislike the man, and bear him no ill will. And I certainly was not among those who cheered when one Daniel Moreno-Gama lobbed a Molotov cocktail at his home last April, then threatened to set fire to the OpenAI headquarters in San Francisco, USA. 

The threat.

What was his reason? Apparently, "AGI poses a threat to humanity and therefore it must be stopped." Come on, now. Really?

AGI

I don't know what this guy has been smoking, but that brand of AI that Sam Altman and his ilk have been forcing down our collective throats, LLMs, barely qualifies as AI, much less AGI. Before anyone jumps on my back, I'll concede that LLMs are incredibly useful. And when you compare them against their predecessor - autocomplete - a massive technological leap in terms of scale, pattern-matching and the like. However, calling them "intelligence" just tells me that your standards aren't particularly high.

How many times have we been promised that AGI is near? How many times has it not materialized? Countless, and countless. The simple fact of the matter is, this tech exists for a reason, and it's not to better the lives of humanity.

Smoke and mirrors
in service of the
almighty dollar.

No, like everything else, it's meant to make money.

AGI might make money once it actually exists in the real world rather than the fevered imagination of fanboys and science fiction enthusiasts, but it costs too much to get there. Meanwhile, faking AGI costs a lot less and satisfies the lower-level requirements. Who needs real creativity when you can simulate it? Who can even tell what actual creativity is?

So, if AGI is nowhere near, what's there to stop?

Humanity

Do human beings suck in general? Well yes, and I don't think that's ever been a controversial statement. But do we suck more just because of AI? We certainly suck more visibly. We have all manner of rubbish created by generative AI, churned out by people who have way too much time on their hands. Deepfakes. Nonsensical clips of Michael Jackson fighting Bruce Lee. AI porn.

AI generation of
Michael Jackson vs Bruce Lee

AI was the tool that made all this possible; but make no mistake, human beings are the ones who should be blamed for how it's used. If you're going to blame AI, why stop there? Blame Social Media. Blame the damn Internet.

I would argue that humanity's greatest threat is humanity. Not AI. If we're already our greatest threat, a pale imitation of ourselves isn't going to do a better job of ending us. It's just not.

Killing Sam Altman

Finally and most obviously, killing Sam Altman isn't going to do jackshit to stop the progress of AGI, assuming it's even progressing. For the obvious reason that Sam Altman does not represent the technological forefront of AI. (Though ChatGPT would probably disagree.)

Ergo, if AGI does indeed exist, it's not inside OpenAI.

Burn it down... and then what?

And all right, let's assume that this one douchebag techbro Sam Altman is behind AGI. You think you can destroy the code just by killing the CEO and firebombing the office? Son, it's 2026. Cloud services are a thing. They've been a thing for years.

Also, is Altman the only one far enough ahead in the race to matter? Think of all the other AI from big tech companies. Microsoft's Copilot. Google's Gemini AI. Meta's Meta AI - actually, I take that last one back. My point is, OpenAI is far from the only culpable one here. What exactly is killing Altman going to accomplish; scare all of them into not doing their usual thing? Good luck!

The fiery conclusion

All this is preposterous. Even overlooking the fact that killing a person just because you believe he heralds the inevitable doom of humanity, is morally questionable and definitely very illegal; the reasons for even going there make no damn sense. Daniel Moreno-Gama isn't the hero he imagines he is. But maybe he should stop watching so many Terminator movies.

Come with me if you want to live burn AI to the ground!
T___T

Friday, 8 May 2026

Ten Reasons To Keep Treating Job Interviews As Target Practice

For the longest time, I've been an advocate of getting practice in job interviews... using actual job interviews. I make no apology for this; in fact, at a certain stage in my career, I made it a point to do this regularly. And I will continue to advise professionals to keep applying for jobs and going for job interviews, even - or especially - if they have no current intention of switching jobs. Hey, life is about at least opening new doors to see what lies beyond, if not going through them.

Opening new doors.

Don't feel too bad about potentially wasting the time of the companies you apply at. How many companies post job ads and conduct interviews for positions they have no intention of filling, just so they can technically bypass the requirements set out by the TAFEP? Two can play at that game.

Plus, there are some really compelling reasons to do it. Here's a list of some really big ones.

1. Muscle memory

You know what they say about practice making perfect? Well, there's no such thing when it comes to interviews (or anything, really). But you can get awfully good at it. What about mock interviews? Well, mock interviews are great and all, but at some point you're going to have to stop hitting the punching bag and square off against someone who's actually trying to hit you back.

This won't hit back.

People also tell me that they have better things to do than to attempt interviews "for fun". This is a huge misrepresentation of what I'm recommending. Of course, if it's fun for you, that's a bonus. But it's not the main point.

Nothing about this is supposed to be fun. Think of this as working out, where you condition your body, strengthen it, in the event that one day it might be ready when called upon. This is the career interview equivalent of exercising in a gym.

2. Confidence

At the very least, you'll get a lot more comfortable at it.

Even when it's a high stakes interview where there's a lot riding on it and you actually care about the outcome, there's no denying that prior practice helps. A big part of you will feel like you've seen and done all this before. There will be a certain familiarity to the entire process that, due to the comfort said familiarity brings, will go a long way towards offsetting any nerves.

Staying chill.

People have remarked on how remarkably at ease I seem during job interviews. What they don't know is that this has nothing to do with my people skills. I still find other human beings tiresome and annoying. It's simply that after a few hundred interviews with actual companies and dealing with all their bullshit, it stops being fresh and exciting. As a result, it also stops being anxiety-inducing. Seriously, no matter how unique and special some interviewers seem to think their interview process is, the truth is that the vast majority of the time, it's like most other interview processes.

Tech round? Mock project? Whiteboard? I've seen it. I've done it. I've even conducted it. Nothing makes me nervous. Because almost none of it is new.

Reusing the boxing analogy from before, the best way to get over a fear of being punched in the face, is to get punched in the face frequently. Similarly, to get over a fear of rejection from interviewers, you need to get rejected often. From real interviews.

3. Develop market awareness

The tech industry is wide and varied. Even if you narrow it down to software development, or even further down to web development, the fact is that different employers have different requirements. They may need proficiency or even just passing familiarity with new software, new frameworks, new software libraries that you may never even have heard of.

And it's true that you don't know what you don't know. So if you don't even have any idea where to start improving, how are you going to improve? It certainly isn't going to be by repeating the same old stuff over and over. That may work for some industries. But no, not software development.

Laundry list of requirements.

But every time one applies for a new job, guess what - the application often comes with an oh-so-helpful wish list of skills that the employer is looking out for. Sure, some of it is laughably impractical, but this is generally where you can scan the list for things that look unfamiliar to you, and then start exploring.

You know the D3 and HighCharts demos I have done? They both started out as items on a job application list of requirements. I Googled the terms and the rest is history.

4. Broaden horizons

There are sights you don't get too see very often. Huge, sprawling offices that overlook the sparkling waves of Marina Bay. Fancy commercial towers. Lush lobbies.

Not to say you can't see those things without going for a job interview... but really, what better time? Surely not during your free time when you undoubtedly have more pressing concerns and better things to do?

See the sights.

Aside from the sights, sometimes companies have interesting ways of testing interviewers, such as through puzzles or case studies. Some of them were so fun I turned them into web demos. Tetris in vanilla JavaScript? Rock, Paper, Scissors app? All that came from some applicant assignment sheet.

Also, I know I earlier said that most interview questions are lame and formulaic. Most. Sometimes interviewers surprise you with a question you haven't heard before. That's very valuable. It not only expands your experience, it tests your ability to think on your feet.

Take the experience as a way to broaden your horizons. Add to the growing list of stuff you can later confidently claim to have seen.

5. Learn how to conduct

One side effect of having attended a whole shitload of interviews in your career, is that you learn how to conduct them.

Well... not quite.

Let me qualify that. You don't exactly learn how to conduct them. That kind of experience comes from actually conducting them, just as the know-how to get through job interviews comes form actually attending job interviews.

Conducting an
interview.

But you do learn an awful lot about how to conduct them. For example, you would know from firsthand experience how cringey some questions sound, such as the classic "where do you see yourself in five years?" and the ultimate douchebaggy "why should we hire you?", and hopefully avoid being such a cliché.

You would learn, from the interviewee's point of view, what makes a bad impression on them, and avoid falling into those traps.

6. Zero consequences

Using real companies and real job applications for practice, is like honing your craft in a real environment with no stakes whatsoever.

If you weren't all that (or even at all) interested in the job, it doesn't matter if you fail. Your ego might get bruised a little bit, but that's about it.

Target practice.

What are they going to do if they find out you were just using them for practice? Not hire you? Big deal. It's not like you were actually interested to begin with. Practice, remember? Are they going to sure no one ever hires you in the industry? Please, they wish they had this much clout. This is Singapore, not Silicon Valley.

My entire point is that there are no consequences for failure. This is a consequence-free activity dressed up as high-stakes operation. You pretend to yourself that this is a job you really want, though in actual fact you could care less. As interviews go, the only thing less stressful is a mock interview, and those are pretty lame.

7. Future-proofing

"But I'm happy where I am!"

Oh, you sweet summer child. You don't have to be unhappy where you are, to go for a job interview. Especially when the objective is practice. But it probably would add a huge dose of motivation.

If you're happy and
you know it...

It's a hedge against the eventuality that you no longer want to work in your current place of employment, for whatever reason. No relationship lasts forever, especially not one that's predicated on a nebulous human emotion like "happiness".

And when - when, not if - that happens, you'll be glad you bothered. Your resume's already somewhat up-to-date due to all the regular practice. The last interview's still fresh in your mind, along with all the land mines you stepped on in the process. You're ready to go.

At the very least, you'll have gotten a good idea of how much your skills and abilities are worth in the market.

8. Bragging

Anyone with even an ounce of ego likes to brag about their accomplishments. Well, sunshine, here's your chance. A sanctioned space for you to safely brag about all your professional accomplishments. Talk about how you solved the persistent rounding error, that intermittent asynchronous event bubbling issue, and optimized that query to reduce latency to milliseconds.

Not only are you expected to do so, you are encouraged to. That's the entire point - to sell yourself.

I'll confess - this is one of the biggest reasons for me to attend any job interview. Not only do I get to brag, I get to brag to an interviewer who knows exactly what I'm bragging about. That's not a small thing. You see, anyone can brag. But who you brag to makes a hell lot of difference.

Toot that horn!

As a tech, if you're bragging to people who don't have the know-how to properly appreciate the brilliance of what you're bragging about, it can be like casting pearls before swine.

But when you're speaking to someone who has a pretty good idea as to why your accomplishments are impressive, that is sweet. And the cherry on top? Impress that someone enough and you may just win a job offer.

9. Eureka moments

During interviews, you're asked to describe your current work, and the challenges you face. And this can have a few effects.

You'll talk about the problems you're tackling, and how you either solved them, or are attempting to solve them. And we all know what happens when you talk them through someone, especially if you're explaining those problems well enough: you get an Eureka moment. Honestly, a lot of problems are solved just by talking the problem through with someone; anyone actually. You don't really need to be in a job interview to get that Eureka moment.

Your Eureka moment.

But can you get that Eureka moment during a job interview when you're talking about your work? Yes, absolutely. I wouldn't make it the reason to do job interviews, but it's one of the possible side-effects.

10. Gaining Perspective

One thing may happen when you go for those interviews and discover all the things you wouldn't have otherwise. You may actually realize how good you have it. You may gain a newfound appreciation of your workplace, warts and all. If seeing how things are out there makes you happier at your job, that's value.

The grass is browner on the
other side.

Granted, some places seem more fun to work in. They're also potentially messy, have less benefits, and are a pain in the butt to commute to. It could be any number of things, or all of them.

In the process, you may just discover that you're really grateful to have this job. And that's fine. Just don't be too grateful. Your career depends on it.

I like to call it the "grass is browner" syndrome.

Final notes

I haven't followed my own advice in years. I do still think it's good - even great - advice. But for me, it's started to show diminishing returns. The gains just aren't there anymore once you've clocked in the hours. Still, what this means is that there are gains. I can walk into an interview and feel little to no anxiety. I can answer most questions glibly, and even if I don't impress sufficiently in the end, I'm rarely too bothered by it.

Do exercise caution. It's entirely possible that you'll become better at passing interviews than actually doing the work... and that's the last thing you should want.

Let's review this in five years!
T___T

Monday, 4 May 2026

The Case of the Awkward Tech Interviewee

It's been a while since I attended a job interview. As an applicant, anyway.

Recently, I was on the other side of the interview, reviewing candidates for a tech position within my company. The interviewee in question was a nervous-looking Malaysian. There wasn't anything that really stood out, except for his awkwardness. Which, in itself, was a problem. You see, for tech positions, sometimes one can get away with not being able to communicate that well. The stereotype of socially-inept but brilliant techies exists for a reason.

Brilliant but
awkward?

However, this particular position was for a leadership role. And lack of communication skills just wasn't going to fly. I could tell that my co-interviewer had already written our applicant off and was about to call it in, but I persisted. We'd already scheduled and allotted the time; I figured that I might as well develop the muscle memory I needed for being an interviewer.

Besides, it could have been just nerves. Some people have told me I can be intimidating, a statement I consider laughable. Please, look at this face. Nothing about me is remotely intimidating.

Either way, I decided to give him a question he could answer. I asked him to explain what he would do to combat SQL Injection. His answer, predictably, was "Stored Procedures". My follow-up, probably just as predictably was why Stored Procedures? What do Stored Procedures do that normal SQL queries don't?

He stammered. Hemmed. Hawed.

After a few minutes, I put him out of his misery. I told him to Google the term "paramterized queries". And then told him that in future, if anyone ever asked him a question like that again, he should refer to that, rather than simply say "Stored Procedures". It would be a better, more complete, more correct answer. And more importantly, it would be an answer that instilled confidence in the asker of the question, confidence that the answerer knew his shit.

After we were thanked him for his time and bade him goodbye, my co-interviewer turned to me and asked me why I'd spent so much time on this guy. Did I see some potential that he'd missed?

I replied, simply, that we obviously weren't going to give him the job... so I might as well give him something.

People commented on my perceived generosity, or at least, on me "paying it forward". I don't think either is true. This was decidedly not about making the tech industry a better place, or even giving back.

Back then...

Upon further reflection, something similar happened to me in the days when I was the applicant. There were times when I sensed I had failed the interview, and when the interviewer asked if I had any questions, I ventured out of the box.

I asked for advice. And this paid off in spades. They proceeded to tell me more or less where I'd gone wrong. We all knew I wouldn't make it past this round, but they at least thought I deserved a fighting chance... somewhere else. They wanted me to succeed, again, somewhere else. I guess it helped that His Teochewness has such a winning personality.

Seeking answers.

I think that helping candidates along is a very natural instinct on the part of any tech interviewer who takes their job seriously. Of course, it helps if the applicant doesn't piss them off. One may object on the grounds that this helps applicants cheat on their next tech interview. That's only true if they get asked the exact same question next interview. Also, let's be real, answers are all over the internet.

And from a cynical point of view, even if it's true that you're enabling inferior candidates to "cheat", they'd likely be "cheating" at the interviews of your competitors. Nobody really needs me to explain this one now, do they?

It's probably also true that techies generally like to look out for other techies. Some little tribal instinct there. Us geeks against the laypersons.

To conclude...

Interviews need not be an adversarial exercise. Your interviewers want you to succeed, or at least not turn out to be a total waste of time. Selfishly, because they already invested the time and energy into prepping for this interview, and conducting it. From that point of view, they get nothing if you turn out to be a dud.

Therefore, they don't need to love you. They just need to not severely dislike you. And the rest takes care of itself.

Without question,
T___T

Monday, 27 April 2026

JavaScript's non-existent relationship to Java

Despite the fact that I can no longer, by any stretch of the imagination, be referred to as a "beginner" where my career is concerned, I sometimes do like to read beginner books on tech. It's oddly soothing. There's also plenty I can learn in terms of how to communicate tech concepts and ideas, from the authors of such books, if not the actual tech itself.

And this is one such book that I picked up from the neighborhood library recently - How to be a Web Developer, by Radu Nicoara.

This book.

Now, this isn't one of my Reference Reviews - I didn't finish reading the book and this would be dishonest. Radu Nicorara probably knows his way around the building blocks of the World Wide Web and has, again, probably done a whole lot more than I have. After all, he published a book. And I give him all the credit in the world for even attempting it.

However...

...once I got to Page 60 (or thereabouts), I encountered a statement that was so egregious that it took me out of reading the book entirely. Not that I ever found the book all that engaging in the first place.

This passage shocked me.



JavaScript is a scripting language (meaning the code is not precompiled) that's derived from the Java programming language, hence the name.
I was in complete disbelief when I saw this. Just to be sure, I sent a photograph of the page to Meta AI, and Meta AI being the nice little bot it was, it described the passage as "a bit misleading".

A bit misleading?! Try "completely false".

The error

For anyone who might be tempted to repeat this, JavaScript is not derived from Java. Aside from the fact that they may both be described as programming languages (coding pedants may insist that in JavaScript's case, it's a loose description) they don't actually have anything to do with each other.

JavaScript began life as a loosely-typed client-side language meant for browsers to interpret. Java was (and still is) a strongly-typed compiled programming language. The names are similar, and the syntaxes are similar. But that's where the similarities end, and even these similarities can't be used as evidence for JavaScript's relationship to Java.

In fact, JavaScript's original name was Mocha. Yes, as in the coffee. It was changed to "JavaScript" as some kind of marketing ploy to mislead people into thinking it was a child of Java. Well, guess it worked!

Fancy a cuppa Mocha, luv?

This reminds me of an encounter on the Clubhouse app where I heard some American woman make the ridiculous claim that in the Chinese language, "the words for danger and opportunity are the same".  John F Kennedy, the 35th President of the USA, was the first to say this back in 1960, and he was wrong. In Chinese, danger is "危机" and opportunity is "机会". Both words contain the word "机", but "机" is also a suffix commonly used to describe machines such as "飞机" (flying machine, a.k.a aeroplane), "手机" (hand machine, a.k.a mobile phone) and "耳机" (ear machine, a.k.a earphones). At the risk of stating the painfully obvious - aeroplanes, mobile phones and earphones have fuck-all to do with danger or opportunity, just as JavaScript has no relation to Java.

Which tells us a couple things - just because two words sound the same or contain subsets of each other, does not make the things they are describing, related. Thus, just because Java and JavaScript both contain the words "Java", it doesn't follow that they're related in any way. The second thing this tells us is, if you don't speak a language, maybe keep the witty quotes to a minimum unless looking stupid brings you deep emotional satisfaction.

As for syntax, both Java and JavaScript's syntax is based on C. Curly brackets, semi-colons, function declarations and so on. But this similarity is not confined to Java and JavaScript. Several other languages such as PHP and C# also have great syntax similarities with Java. In terms of similarity, C# is even closer to Java than JavaScript is.

All in all...

It's not my intention to jump on Nicoara for this error. Whomever his editor was, shares the blame for this. And this glaring factual error aside, what little I read of his book seemed sensible. Therefore, I didn't contact Nicoara and inform him of this boo-boo. What good would it do? It's not like one can un-publish this book.

Besides, I'm not exactly perfect. Early in my blogging days, I probably made my fair share of factual errors. Though, in all fairness, it's not like I'm profiting off my blog, or asking people to pay for it.

All that aside, I used this as a teachable moment. Even if that little piece of programming history I taught was dryer than a nun's coochie.

Java nice day!
T___T

Wednesday, 22 April 2026

Spot The Bug: The Textbox That Refused Validation

Hello, dear Bug-hunters. Time once again for some elusive bugs!

And here we
go again...


Today's episode of Spot The Bug is about form validation. Specifically, HTML form validation.

I had a mailer form, like so, and I wanted to verify that this message box was filled before submission. I just added required in the HTML attributes. Simple, right?
<body>
  <h1>Contact Us</h1>
  <form method="POST">
    <fieldset>
      <legend>Email</legend>
      <input required name="txtEmail" type="email">
    </fieldset>
    <br />
    <fieldset>
      <legend>Subject</legend>
      <input required name="txtSubject">
    </fieldset>
    <br />
    <fieldset>
      <legend>Message</legend>
      <textarea required name="txtMessage" rows="5"> </textarea>
    </fieldset>
    <br />
    <button>Send Mail</button>
  </form>
</body>


So here was the form. Each form input element had the required attribute, which tells HTML5 that they cannot be blank.


What Went Wrong

You see that little tag come on when I fail to fill in Email and click Send Mail.


And if I fail to fill in Subject, and click Send Mail.


But when I leave Message blank and click Send Mail, the form attempts to submit. The form submission went through without a hitch. It wasn't supposed to - because I hadn't entered anything in the Message text box. Or so I thought.

Why It Went Wrong

See this? You probably won't spot it right off the bat, but... there is a single space between <textarea> and </textarea>. Innocuous? Not quite, because that would mean that the text content of the HTML element, registers as a single space! Which also means, that it's not an empty string.
<textarea required name="txtMessage" rows="5"> </textarea>


Which, of course means that the validation passes!

How I Fixed It

I changed it to this. Now there would be no content in the texbox by default.
<!-- <textarea required name="txtMessage" rows="5"> </textarea> -->

<textarea required name="txtMessage" rows="5"></textarea>


And attempting to submit with this box left empty, would trigger the error message!


Moral of the Story

It can't be stated enough, that what you see onscreen isn't necessarily what's happening in the HTML. In this case, it was being reflected on-screen, except that, it being a space and all, was pretty hard to visually detect at a glance.


T___T