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

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

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 MetaAI, and MetaAI 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

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.

Till the next Spot The Bug,
T___T

Film Review: Black Mirror Series Seven (Part 3/3)

Up next, we have Hotel Reverie.

The Premise

Brandy Friday signs up for the lead role in a movie reboot which is a computer-generated simulation of the original. This involves transporting her consciousness to a computer-generated environment.

The Characters

Issa Rae has an enjoyable outing as Brandy Friday. This is probably an unpopular opinion, but I think she absolutely nailed this role, especially when her character is playing the role of Dr Alex Palmer. There's an easy charm about that smile, that just looks so effortless. And her portrayal of an actress who wants to break out of gender stereotypes, is pretty compelling.

Emma Corrin plays Dorothy Chambers with a certain wistful sweetness that fits the story to a tee. A closeted lesbian who put herself into her roles on-screen. When I found out she also played Cassandra Nova in Deadpool & Wolverine, and Anna Harding (the pregnant wife) in Nosferatu, I was knocked for a loop. Corrin is so versatile, I didn't even recognize her!

Awkwafina as Kimmy. A fun role, though I feel like Awkwafina could have done so much more. Kimmy is basically the desperate and harried film exec who wants to get a movie made. I don't ever recall -not- enjoying watching Awkwafina on screen, but let's be honest, she was criminally underused here.

Harriet Walter brings a certain dry wit to the role of Judith Keyworth, owner of Keyworth Productions. She's occasionally snarky and delivers reality checks in straightforward, unvarnished style. I really dug her delivery of the line "NFI - not fucking interested".

Stanley Weber as Dorothy's onscreen husband Claude. Mustache-twirling villain.

Farid Larbi as Inspector Lavigne. Another one-note role.

Elaine Claxton as dog owner Madame Roban. Played this Karen in a black-and-white movie. She was fun to watch, in small doses at least.

Elliot Barnes-Worrell is in this episode for a few minutes Brandy's agent Quarterman. He's played as cavalier, snarky and dismissive... and he looked like he would be a nice addition to the cast. Except, after his first few minutes, we never see him again.

Charlie Hiscock as bumbling techie Jack. Hiscock plays him as a competent but complacent techie who gets whiny when he's stressed, and delivers some tech exposition.

Enzo Cilenti as Ralph Redwell. He's mostly seen in flashbacks, the typical beefy suave protagonist of black-and-white film. Cheesy, but effective.

Tessa Wong as Asian girl writer, Crystal. She plays a comedic role, at one point seeming more concerned with getting writing credit than saving Brandy's life. That was cute.

Magnus Brunn as Dieter. He's the guy who reads the romance meter. Kind of useless, to be honest.

Danielle Vitalis as black girl tech, Mika. Maybe it's just me, but it felt like she was making up the numbers. This is her second bit part in the Black Mirror series. The first was in Joan Is Awful, and this time round the role feels even less relevant.

Natalia Kostrzewa as nnamed delivery girl. It was an entertaining few seconds as she went all fangirl on Brandy only to reveal that she was actually more interested in her male co-star.

The Mood

It's a little humdrum at first, but soon we enter the black-and-white environment of the movie and ironically, things get pretty colorful from here as we switch rapidly between that environment and the "real world".

The narrative tension is raised towards the end, because this is Black Mirror and we're never completely sure who survives the episode.

What I liked

The interracial lesbian relationship between brandy Friday and Dorothy Chambers. Yes, I know, I've complained in the past that Black Mirror seems to insist on shoving interracial relationships down our throats, especially of the black-white variety. And this isn't even the first black-white interracial lesbian coupling, the first being San Juniperio. But this one was different. The lesbian part was actually an integral part of the story. Brandy Friday's identity as a black woman was actually acknowledged by the plot. It didn't feel like yet another box-checking exercise and giving us an interracial lesbian couple just for the sake of it. If anything, it felt like this episode was taking shots at Hollywood for its overeagerness in race and gender swapping in its reboots.

The concept of ReDream. It is pretty neat, and fits into the concept of generative AI as we know it today. Not exactly, but pretty damn close! What with the main character's consciousness being implanted into a computer-generated simulation and all.

This was one of those shows where the women had the most to do, and the men were either relegated to useless minor roles, or portrayed as incompetent buffoons. I should be annoyed, but in truth, I barely noticed it, even after watching the episode twice. It only just occurred to me, when writing this review. I mean, if any movie or show wants to go this route, they should absolutely take a leaf from this episode's book. It was done so masterfully, so subtly, as to be almost unnoticeable. Or maybe I'm just oblivious.

What I didn't

Dropping the USB device was relevant to the plot, because it resulted in Kimmy explaining things to Brandy (and to the audience) what ReDream does. But really, why bother when they could have Kimmy do that anyway, without that little plot device?

If ReDream could do all that, why would they even need an actual actor? Or actress? This part was never made clear.

Conclusion

This was actually pretty good. There was the risk of the whole virtual reality angle being played out in the Black Mirror series, but they somehow managed to make it feel refreshing. Never have I found a black-and-white setting so utterly compelling.

My Rating

9 / 10

Thoughts on Black Mirror Series Seven so far

I was blown away. I haven't felt this much optimism since Series Four. This feels like a return to form. Each episode so far, has been classic Black Mirror stuff. It started with the gut punch that was Common People, took a slight dip with Bête Noire, then came back strong with Hotel Reverie. The first three episodes of this series have so far trumped the entirety of Series Five and Six!

I'm TFI! Totally Fucking Interested!
T___T