To Do Or Not To Do...

...that is the question! Enough Hamlet, let's get serious.

When attending a job interview, there are certain points of contention as to what to do, or what not to do. Often, someone advising you to do one thing, and it is the very thing that others are telling you not to do.

What should you do, then? Take a poll?

No, not at all. Feedback is helpful, but often, you need to put everything in perspective. Sometimes the reasons people advise you to do (or not do) certain things may not apply to the situation. Sometimes the reasons made sense back in the 60s, but are ridiculously obsolete now.

Let's take a look at some of the things that people claim you should do during the interview process, and examine the reasons for doing, or not doing, them. Specifically, in the tech context.

Before: Cover Letter

Some recruiting firms claim that this is a way to make your resume stand out. It gives hints to your personality, and your ability to (gasp!) write a letter. In fact, it's very strongly recommended that you write a cover letter. Personally, I think that if a company is going to insist on a cover letter before they even look at my resume, they better be one motherfucking huge badass company to warrant that level of effort - in which case they probably receive more cover letters than they care to look at. Cover letters are meant for companies you really want to join, as opposed to those you apply to simply because you need a goddamn job. Again, if a company is vain enough to require that an applicant wants to join them specifically, they better be huge. Like Google huge.

Do at least write a perfunctory introductory email in addition to attaching your resume when you apply. A couple of lines will suffice. Because, otherwise, the email just looks odd with only a subject title and an attachment. It may even look like spam.

Don't overdo it. Nothing screams desperation like trying too hard. There's no need to rehash your resume, or write mountains of paragraphs just to show you know how to write three-syllable words. Less is more. Trying too hard is not appealing in an applicant.

Welcome!

There's also no need to worry too much about personality. Heavens, you're a techie, not a club hostess. Personality is a liability. A company wanting to hire a tech for personality is barking up the wrong fucking tree and you're better off avoiding that potential trainwreck.

If in doubt, don't. Let's face it - the tech scene in Singapore is flooded with foreigners, the majority of whom English is not their strongest suit. Where it comes to leaving out the cover letter altogether, you're in good company.

During: Wearing a tie

Some old-school business people like to see applicants wear a tie when interviewing. It reminds them of the good old days where a visual first impression was one of the main factors of consideration. Personally, I prefer to wear a pressed shirt. Nice shoes. Combed hair, cleanly shaved, a touch of cologne. The works. And yes, a tie. Not that I think it matters that much; but if I'm going to spend good money on a four-foot piece of fabric, I'm damn well going to employ every feasible excuse to wear it. Even when interviewing for a startup, because that's how I roll.

Tie or no tie?

Note that it isn't necessarily just about how you appear to the interviewer. As a tech, it's your skills that are important, true. But employers may also want to get a glimpse of how you would carry yourself in a non-technical context, i.e, when representing the company to speak to clients. In that sense, your value isn't in just your technical skills, but also your communication skills.

Do be presentable. Obey the stated dress code, and yes, if it's formal, put that tie on.

Don't disregard the stated dress code. If they say "casual", for example, don't do the whole blazer-and-tie route. If you can't seem to understand basic instructions, you're probably not much of a hire. That said, don't take "casual" to the extreme and show up in berms and slippers. That's a no-brainer, right?

If in doubt, don't. Most techies don't bother going beyond a nice shirt, pants and shoes. You're not going to stand out for not bothering either.

After: Follow-up letter

Again, recruiters like to make a big song and dance about how important it is that you stand out from the crowd, be memorable, and all that hogwash. Remind them that you exist, and so on. It's recommended that you send an email thanking the interviewer(s) for their time and inquiring after the job.

Thank you for your time!

Do exercise a little common courtesy and thank the interviewer for their time, perhaps a few days after.

Don't be pushy or needy. Don't mention that you need a job. Few things kill off your hopes of getting hired faster than looking like you have no other options. People always want to hire techies who have options, unless they're planning to hire desperate cases in order to exploit them.

Oh, and don't send the follow-up email right away. Timing is everything.

If in doubt, do it. If you've already blown the interview, it's still good manners. If not, it revives your chances. If you've accepted another offer, all the more you should do it.

Do, or don't do?

As I said earlier, a lot of it depends on context. Even when you narrow it down to a tech context, the answer's not always cut-and-dry. Exercise some judgement!

Do have a nice day. Don't sweat the small stuff!
T___T

Film Review: Unfriended: Dark Web

Unfriended is back! Well, not exactly. Unfriended: Dark Web is a stand-alone sequel to the excellent original. This means that it has nothing to do, storyline-wise, with the original Unfriended. Which also means that you don't have to have watched Unfriended in order to understand what's going on with this one.

Like its predecessor, this movie is in "found footage" format. Unlike its predecessor, Unfriended: Dark Web has no supernatural elements in it. It's not a revenge flick about a wronged ghost... this time.

Warning - minor spoilers to follow

I really want you to watch and enjoy this movie, so I'll be spoiling it as little as possible.

The Premise

Mattias steals a laptop from an internet cafe and uses it to Skype chat his friends. The laptop turns out to have been the property of a hacker from the dark web... a hacker who earns money through kidnapping innocent girls and torturing them to death, and streaming the experience live for the amusement of the dark web audience.

The Characters

Colin Woodell as Mattias O'Brien. Decent turnout. Did the whole nerd thing pretty well, though later on he tended to overact. His anguished declaration of love and displays of panic, for some reason, didn't grab me as much as they should have.

Betty Gabriel plays Nari, Serena's wife. She portrayed both her decisiveness and civic-mindedness, and her firmness in the face of danger. The sheer gutsiness of the character was awesome, and even as she was killed, it looked like she put up a hell of a fight.

Nari's wife, Serena, is played by Rebecca Rittenhouse. This role was pretty meh and screamed cannon fodder. I didn't feel much for the character and the actress just did not have that much to work with beyond being a lesbian. Even the crying scene felt a bit draggy.

Andrew Lees as Damon, the Brit among the group. He's a calm reassuring presence with tech know-how. He's even shown using Skype chat from his company's datacenter!

Connor Del Rio is AJ the conspiracy theorist. He plays him with the right amount of goofiness and paranoia. I think the character is a cool dude to hang out with, if a bit ranty.

Stephanie Nogueras as Amaya DeSoto, Matty's girlfriend. What a babe. Didn't say a single word - literally; she plays a deaf character - during the whole movie, but somehow this movie at least partially revolved around her and her deafness. That doe-eyed innocence actually kept the tension up because I wanted her to survive the movie.

Savira Windyani as Lexx. Cute and spunky. Seemed to be the token Asian in the cast, because she didn't contribute anything other than to the body count.

Alexa Mansour as Erica Dunne, the first victim we see. She looks just the part of the victim too - girl-next-door, pretty ordinary, thrown into a world of sadistic nihilism.

Douglas Tait makes an appearance as Charon IV. This guy is probably the most famous of them all, and the low budget probably contributed to his very limited scenes. The low resolution and all made his scenes look like some kind of video acting for a computer game.

The Mood

Starts off light-heartedly, with a lot of camaraderie interspersed with boyfriend-girlfriend drama. Gets grim in the middle of it, when it's revealed who the real owner of the laptop was, and what he was into. At the end, it's really sad and sinister all at once.

Like the original, the action all takes place on a computer screen. Facebook, YouTube, Google and Wikipedia all make an appearance, along with many other apps.

What I liked

"covfefe" as a password. Nice way to tie this to the modern world.

The music is bitchin'.

Nobody here is an unsympathetic character. No, not even that nutty conspiracy theorist. They're all, at the very least, mildly rootable for. This makes it easy to be invested in seeing at least one make it out alive. It's precisely because they're so innocent (unless you're one of those nuts who consider homosexual marriage a crime punishable by death) that makes their eventual deaths all the more horrifying.

The twist near the end, and at the end, is delicious. I'm not gonna spoil this one. You need to see it.

The way the hackers use live feeds (hacked from CCTV) is great for the movie. So while the protagonist is mostly stuck at his laptop, we still get to see stuff that's happening elsewhere.

The way AJ the conspiracy theorist dies is unintentionally hilarious. I really enjoyed it... for all the wrong reasons.

What I didn't

The glitches that come up whenever one of the villain hackers make an appearance. Like, what's up with that? It's not cool, it's distracting and makes no damn sense.

The cast is too pretty. The gorgeous mute girlfriend aside, everyone else has these great cheekbones and perfect teeth. Even the Brit dude looks like Chris Hemsworth and has that sexy Londoner accent to boot. Damn, I hate them already.

Racial demographics. I can accept a predominantly white cast. But they seemed to have included a black actress and an Asian actress just for the sake of having them. Why? Just make them all white, or make more than one of them black, or something. Why does every horror flick seem to follow the same damn formula for racial representation?

It's too unbelievably convenient the way these dark web hackers appear to have figured out every move they'd make. Really?

Conclusion

Mostly enjoyable and didn't feel too shabby even when compared to Unfriended. Kept things fresh enough that the whole take on the "found footage" genre concept that made Unfriended such a hit, doesn't feel rehashed. As a sequel, Unfriended: Dark Web is not too bad at all. This is a movie that will make you feel apprehensive about staring at your computer screen too long.

In my review of Unfriended back in 2015, I remarked that "any follow-up clones would serve only to lessen the impact of the original". In a way, it was true - the freshness is gone as far as concept goes... but the storyline is new and refreshing.

My Rating

7.5 / 10

Die-die must see!
T___T

Data Theft at SingHealth

Sometime yesterday evening, Singapore was the recipient of unwelcome news. Suspicious server activity had been detected about two weeks ago on 4th July, with the personal and medical records of roughly 1.5 million people in SingHealth's database stolen. That's right; while Americans were celebrating their Independance Day, Singapore was experiencing the most serious breach of data security in her history.

What this means for you, is that if you had visited any Polyclinic or Government Hospital / Medical Facility as a patient recently (say, in the past few years), there's a chance that your personal and medical records are in someone else's grubby little hands now. My mother and some of my colleagues have already reported receiving an SMS from from SingHealth informing them of such.

According to Prime Minister Lee Hsien Loong yesterday, his own medical data had also been targetted "specifically and repeatedly". This basically implies that it was a deliberate attack and not something your neighborhood kiddy script user would do on a lark.

The Good News

Records were accessed, but not doctored (pun intended). Your ongoing treatments and billing aren't affected. (Though if your treatment is remarkably expensive, you may not consider this good news.)

Since kicking the cyberattacker out of the system on Jul 4, further attacks were observed but no further data were illegally stolen, the ministries said, adding there was no disruption of healthcare services during the period of the cyberattack and patient care has not been compromised.

The above was reported by ChannelNewsAsia. Shit standard of English aside, (what the holy fuck does "illegally stolen" mean? As opposed to what? Having it stolen legally? Get lost, you knobs.), the Government isn't simply sweeping this incident under the carpet and hoping no one will notice, and is taking this seriously.

The Bad News

Your personal records such as name, NRIC and residential addresses were stolen. If there are any online systems out there that merely require a name and NRIC for registration, you may or may not find yourself the victim of identity theft. If you have the particularly bad habit of using your NRIC number as your email password, now would be a great time to change it.

Phishing attacks are also a distinct possibility with the data stolen. Think someone sending you requests for more data using the stolen data of someone you may know and trust... the possibilities are endless. In particular, imagine someone asking for some information about your bank account, and being armed with details like your NRIC, date of birth and telephone number.

What does this mean for Singapore?

From the perspective of being attacked, this is but a drop in the ocean. Not to trivialize the event, but Government agencies all over the world get cyber-attacked constantly and Singapore is no exception. Something was bound to get through eventually. The important thing is to be able to respond and recover swiftly. The world isn't going to end tomorrow just because of this. The average man in the street shouldn't be too worried, though people in the departments of our Government's cyber-security certainly should be.

Be vigilant, paranoid even, and don't make the mistake of thinking something is safe simply because it's stored by the Government. That's one of the first places they attack.

From the perspective of being successfully attacked, it's time to think of what would happen if the attackers had gone for, say, our military database instead. You can't take anything for granted these days, and this latest incident is testament to that.

Stay healthy,
T___T

The Buzz About FizzBuzz

FizzBuzz in tech, is a programming question designed to be trivial for people who can code, and a real test for people who can't. Basically, if you can't even solve FizzBuzz, you don't belong in any programming job. At all.

The test goes like this...

Write a program that prints the numbers from 1 to 100. But for multiples of three print "Fizz" instead of the number and for the multiples of five print "Buzz". For numbers which are multiples of both three and five print "FizzBuzz".

Yep, it really is that simple. All you really need to know is how to iterate (For or While loops), logic Conditionals (If-Else statements) and how to use the Modulus operator to determine the divisibility of x by y. Stuff any fledgeling programmer would know.

To be brutally honest, FizzBuzz would barely be a Level 2 kata on CodeWars!

When the issue of FizzBuzz crops up, understandably, the first instinct most engineers get is to attempt to solve it. No, I'm not going to be exploring the many different ways to solving FizzBuzz today. If this is your thing, there's a list you can consult. Instead of how to solve FizzBuzz, let's take a look at the deeper question of why FizzBuzz?

Yes, why Fizzbuzz?

More than ten years after it first came out, FizzBuzz is still in use in some places today as an entry-level interviewing test.

Hiring managers claim that it is a great filter to weed out those who can't program at all. I think that's an astonishingly low bar for what I assume is a job where the complexity of the code is a lot higher.

There is also this (presposterous-sounding but apparently true) claim that 40% of job applicants can't solve it. And honestly, I don't think that says anything about how daunting a task FizzBuzz is. I mean, am I supposed to feel all special because I can solve FizzBuzz because "40% of job applicants can't solve it"? Get real. This only tells me that the wrong kind of people are applying for the job, because people who actually code for a living don't get stumped by FizzBuzz. Besides, it's a job. Anyone can apply for a job, including your neighbour's grandmother. The job applicants are simply job applicants, period, and there's nothing you can say to convince me that these people who are capable of failing the FizzBuzz test are actually professional programmers. Or even amateur ones.

Why not Fizzbuzz?

OK, it's not that I don't think FizzBuzz is effective for separating programmers from non-programmers. It clearly works. What I'm saying is, we shouldn't have to go there in the first place. Why are people who can't program, applying for programming jobs? Because hirers advertise for degrees in Computer Science, not the ability to solve FizzBuzz. Attract the right candidates and you won't have to waste time filtering out 40% of them.

Besides, being able to solve FizzBuzz simply means you know how to use a For loop, If statements and the Modulus operator. Big fat hairy deal! These should be a given! There are things far more important for a programmer employee to have, than the ability to solve FizzBuzz.

Can the programmer solve FizzBuzz under pressure? Under time constraints?

Coding under pressure.

Is his (or her) code clean, readable and extensible? If not, does that programmer understand why it's not, and why it's important for it to be so? Are the variables aptly named? Are the comments (if any; having no comments isn't a bad thing if you're only solving something like FizzBuzz) actually useful? Is your candidate a cowboy cop or does he understand the value of teamwork? To be clear, there's a place for both in the right context. What does your organization need?

These seem petty, right? Code should work, end of story? If that's the candidate's attitude, that candidate should forget about having a place at the table. Professionals care about excellence. In this day and age, programming has increasingly become a team sport. The ability of a programmer to communicate and collaborate with others, has become key. The ability to solve something as trivial as FizzBuzz is only, and will always be, nothing more than elementary.

That's all. Buzz off!
T___T

Web Tutorial: Styling a Checkbox

The humble checkbox has been a mainstay of the web ever since HTML forms were in existence. Its purpose is to enable the user to select multiple options on a form. It's simple, effective and intuitive.

However, it has one notable flaw - it's pretty much unstylable in CSS. You can't alter the size or appearance of the checkbox. At most, you can make it appear or disappear. That said, for those determined to bend the humble checkbox to your will, being able to make it appear or disappear will be the key to this web tutorial today..

We begin with a bit of HTML incorporating two checkboxes with their respective labels. The first checkbox is labelled "Print" and the second is labelled "Email". Their ids will all also be named accordingly. As an example, we set the first checkbox to be checked by default.

<!DOCTYPE html>
<html>
    <head>
        <title>Checkboxes</title>

        <style>

        </style>

        <script>

        </script>
    </head>

    <body>
        <label for="cbPrint">Print</label>
        <input type="checkbox" name="cbPrint" id="cbPrint" value="print" checked>

        <br />

        <label for="cbEmail">Email</label>
        <input type="checkbox" name="cbEmail" id="cbEmail" value="email">
    </body>
</html>

It's just a plain-Jane checkbox. We're going to make our own soon!

We begin by enclosing each checkbox and its label in a div, and giving the div a class of checkbox_wrapper.

    <body>
        <div class="checkbox_wrapper">
            <label for="cbPrint">Print</label>
            <input type="checkbox" name="cbPrint" id="cbPrint" value="print" checked>
        </div>

        <br />

        <div class="checkbox_wrapper">
            <label for="cbEmail">Email</label>
            <input type="checkbox" name="cbEmail" id="cbEmail" value="email">
        </div>
    </body>

Then we style checkbox_wrapper.

In the main class, we set the cursor property to pointer so that when you mouse over the checkbox or label, it shows the user that this sucker is meant for clicking!

The label within the checkbox_wrapper class has font-size set to 16 pixels. This one's entirely up to you. I'm just making things pretty. I'm awesome like that.

And lastly, the checkbox, which is the input tag within the checkbox_wrapper class, has the display property set to inline. This is entirely unnecessary, because that is the default setting for the checkbox anyway. But we'll need this for later.

        <style>
            .checkbox_wrapper
            {
                cursor:pointer;
            }

            .checkbox_wrapper label
            {
                font-size:16px;
            }

            .checkbox_wrapper input
            {
                display:inline;
            }
        </style>

There shouldn't be significant change at this point, though you may notice that there's some spacing between your checkbox-label pairs, due to the divs they're enclosed in.

Now, before each label, add a div with a class of checkbox. Assign an id which is the id of the respective checkbox, followed by "_checkbox". Within each of these divs, you should have a span element containing "&checkmark;". In the HTML character table, this translates to ✓. A tick!

For a full listing of HTML special characters, here's a link. (https://dev.w3.org/html5/html-author/charref)

        <div class="checkbox_wrapper">
            <div class="checkbox" id="cbPrint_checkbox">
                <span>&checkmark;</span>
            </div>
            <label for="cbPrint">Print</label>
            <input type="checkbox" name="cbPrint" id="cbPrint" value="print" checked>
        </div>

        <br />

        <div class="checkbox_wrapper">
            <div class="checkbox"  id="cbEmail_checkbox">
                <span>&checkmark;</span>
            </div>
            <label for="cbEmail">Email</label>
            <input type="checkbox" name="cbEmail" id="cbEmail" value="email">
        </div>

This is what you should have...

Now style your checkboxes. We'll make it a 20 pixel by 20 pixel square, with slightly rounded corners and a dark grey outline. For good measure, we'll set the float property to left so it aligns with the label.

            .checkbox
            {
                width:20px;
                height:20px;
                border-radius:3px;
                border:1px solid #444444;               
                float:left;
            }

Coming along nicely!

Let's clean this up a little. Set the margin-left property of the labels to 1 em.

            .checkbox_wrapper label
            {
                font-size:16px;
                margin-left:1em;
            }

OK, looking less crowded now.

And here, we'll adjust the tick's span element so it sits nicely within its checkbox. We can accomplish this by setting the display property to inline-block, the width to 100% and aligning the text center. We'll also make the tick bold, and give it a nice lime green.

            .checkbox span
            {
                display:inline-block;
                width:100%;
                text-align: center;
                font-size:1em;
                color:#44FF44;
                font-weight:bold;
            }

Yep, looking presentable now.

Making stuff work

Now you have the checkboxes, but you need to make them respond. First, let's write some JavaScript.

Alter the HTML code as follows. You'll notice that we added an onclick event which calls the checkbox() function, passing in the id of the checkbox as an argument. Also, each div with the class checkbox has had an additional class added to it, either on or off depending on whether the checkbox is checked. This will be significant soon.

        <div class="checkbox_wrapper" onclick="checkbox('cbPrint')">
            <div class="checkbox on" id="cbPrint_checkbox">
                <span>&checkmark;</span>
            </div>
            <label for="cbPrint">Print</label>
            <input type="checkbox" name="cbPrint" id="cbPrint" value="print" checked>
        </div>

        <br />

        <div class="checkbox_wrapper" onclick="checkbox('cbEmail')">
            <div class="checkbox off"  id="cbEmail_checkbox">
                <span>&checkmark;</span>
            </div>
            <label for="cbEmail">Email</label>
            <input type="checkbox" name="cbEmail" id="cbEmail" value="email">
        </div>

And write the checkbox() function. First, grab the div that we styled, using the id and the string "_checkbox".

        <script>
            function checkbox(id)
            {
                var cb = document.getElementById(id + "_checkbox");
            }
        </script>

Next, check if it's checked by accessing its className property.

        <script>
            function checkbox(id)
            {
                var cb = document.getElementById(id + "_checkbox");

                if (cb.className=="checkbox on")
                {

                }
                else
                {

                }
            }
        </script>

If it's checked, set its class to "checkbox off" and ensure that the respective checkbox is unchecked. Do the opposite if it's not checked.

        <script>
            function checkbox(id)
            {
                var cb = document.getElementById(id + "_checkbox");

                if (cb.className=="checkbox on")
                {
                    cb.className = "checkbox off";
                    document.getElementById(id).checked = false;
                }
                else
                {
                    cb.className = "checkbox on";
                    document.getElementById(id).checked = true;
                }
            }
        </script>

Time to test!

Click on the labels or styled checkboxes. Do the original checkboxes respond? They should. We have a problem though... the styled checkboxes themselves aren't responding.

This is because we haven't added styles for On and Off states. Let's fix this. For the Off state, span disappears. For the On state, span is visible.

            .checkbox span
            {
                display:inline-block;
                width:100%;
                text-align: center;
                font-size:1em;
                color:#44FF44;
                font-weight:bold;
            }

            .checkbox.off span
            {
                display:none;
            }

            .checkbox.on span
            {   
                display:inline-block;
            }

And here you go!

One final touch. Hide the checkboxes.

            .checkbox_wrapper input
            {
                display:none;
            }

Voila.

Try it here...

✓

Print

✓

Email

Isn't that an awful lot of trouble?

Well yeah, no shit. These are the hoops HTML/CSS makes you jump through to style textboxes. Still, if you want a nicer-looking UI, this is what it takes.

It's worth noting that many CSS frameworks such as Semantic UI already do this for you, and all the styling and JavaScript has already been written in the package. But nothing like learning how to do it yourself, hey?

That's all. ✓ back for more! (snicker)
T___T

Where To Find Work (Part 3/3)

It's not just the tech companies that need a programmer. A lot of things run on software now, and to suggest doing otherwise is to cede power to competitors. There are plenty of opportunities to be found sectors outside of the software industry... but they come at a cost.

Small-medium Enterprise

Company Size. Small or medium (duh)

Service Model. B2B or B2C.

Pros

Importance. You're less expendable because a lot of users are depending on you. And there's no competition because most self-respecting developers would rather beat themselves to death with their own keyboards than work here. If you're about playing it safe, this is probably as safe as it gets.

A clear path to
promotion.

Promotion. You have only one boss above you, and the only way to get promoted is to take his spot.

Domain knowledge. You are going to get intimately familiar with the ins and outs of the industry the company is in, because you'll be writing software for it... if you're lucky. This is a valuable learning opportunity.

Cons

Pay. The pay won't be bad, but it won't be great either.

Cost center. The company is going to begrudge you every cent they pay you because you don't contribute directly to profits, and non-tech companies typically don't recognize the actual value of tech - you're just a fancy way to keep up with the Joneses.

Doing shit work. If you're lucky, you'll get to write software, but you may end up fixing monitors, troubleshooting Microsoft Office and screwing in lightbulbs because some idiot says it's "tech-related".

Tech stagnation. You'll make all of the technical decisions and get to work with only tech you're comfortable with. And that is not a good thing, not if the term "constant improvement" holds any meaning for you.

Unable to hands off. Nobody's here to take over your job. This also means no long vacations for you.

Verdict

Unless it's a very brief stepping stone to much greater things, why even fucking bother?

Multinational Company

Company Size. Large. So large that in the company's industry, the name is internationally recognized. Like banks, or universities.

Service Model. B2B or B2C.

Pros

Better scope of work. In an organization this large, you get to work in an actual team and do bigger projects.

Pay. The pay is usually decent to great.

Professional visibility. An internationally recognized brand is great news, even if it's not in the tech industry.

Domain knowledge. Having domain knowledge outside of the tech industry is always a bonus, and nothing to sniff at. It also increases your employability if you want to continue finding work in the same sector. For instance, if Oversea-Chinese Banking Corporation (OCBC) was looking for developers, obviously developers who had done a stint in, say, United Overseas Bank (UOB) would be looked upon more favorably.

Cons

Tech stagnation. The technical stack will already have been worked out and those above you are unwilling to change the status quo. Years into it, you'll probably still be using the same increasingly outdated tools.

Politics. In any organization of this size, there's always going to be a lot of this.

Cutting through all that red tape.

Red tape. Ditto for the above.

Verdict

Worth a try. Even if it doesn't work out, there's brand name value. Just don't stick around too long.

Wherever you go...

...do the best you can. That's the least you can do as a professional. Learn whatever you can. That's the only takeaway you'll ever have other than money.

And lastly (and most importantly), know when to leave.

Many gainful employments!
T___T

Where To Find Work (Part 2/3)

When we talk about tech companies, names like Google, Microsoft and IBM come to mind. But tech companies cover a wide range - from infrastructure to software. They also come in a large variety of sizes and service models. It's best to examine your planned career path and make your decisions based on those.

Tech Start-up

Companies that have yet to turn a profit or arrive at any kind of critical mass.

Company Size. These are typically really small, numbering less than ten employees, though large startups (such as Uber) aren't unheard of. We're, at this moment, speaking of the really tiny operations.

Service Model. B2B or B2C.

Pros

Experience. If you're starting out in your career, this is an excellent way to get your feet wet. The ungodly working hours and the tendency of the employer to throw everything your way will ensure that - as long as your attitude remains positive. Also, mentioning that you've survived "startup culture" is almost always a positive with potential employers. If nothing else, you've proven you can weather storms.

Importance. Companies like to say "everyone is important in our organization". This is bullshit. There's always dead weight in corporations above a certain size. But in a tiny startup, this is true because there's no way for it to be false. Every person actually matters. It's a minimal headcount. This is a huge chance to make a difference.

Sauntering to
work like this!

Informal. There's little to no red tape because it's more trouble than it's worth at this point. Sure, there are rules... but also a great amount of flexibility. If you need to take urgent leave or even just a couple hours off, there's generally little to no paperwork and the approving party is more amenable to it. And the lack of a dress code basically means you can waltz in rocking your shorts and slippers every damn day.

Cons

Pay and benefits. Typically not great. It's a startup and they're surviving on raised funds. This means belt are always tightened.

Environment. Along with belts being tightened, being in a startup also typically means that your office is going to look like somebody's storeroom.

Workload. If you're a fan of coming in on time and leaving on time, don't count on it with a startup. Here, due to lack of manpower, everyone gives way more than the prescribed eight working hours a day, bosses included. Working in a startup is hell for your work-life-balance.

Stability. Or lack thereof. A company that is in danger of going under anytime due to lack of funding, isn't the safest bet in the world. You've been warned.

Verdict. Try this at least once in your career. Especially early in your career. If the start-up fails, you'd have gained valuable experience. If it succeeds (and that's a tremendous if) you can take a healthy chunk of credit for bringing it past startup stage. Either way - much to gain, fuck-all to lose.

Software Vendor

These are small companies that make software or websites for other companies. They may have gotten past the startup phase, but survival is a constant struggle.

Company Size. Small or medium.

Service Model. B2B

Pros

Responsibility. Everyone manages clients and builds software at the same time. This is really good for leveling up different aspects of your game simultaneously.

Informal. There are rules. Those rules are also negotiable, because at this point, the company hasn't grown large enough that making occasional exceptions on a case-by-case basis would pose any sizeable problem. That said, it really depends on who's in charge. Some SMEs have a serious case of Chinese Towkay Syndrome and like to act like they have a few thousand employees under them.

Domain Knowledge. Doing work for several different clients, all from different industries and backgrounds, can make the developer well-versed in a large variety of industries. This is always useful, particularly in the event that you want to consider being a software developer in that particular industry.

Direct contribution to profits. Since the profits come off doing lots of low-margin work, your value is determined by how many clients you manage to bill on your watch regularly.

Cons

Repetitive work. Doing different versions of the same thing day in, day out, can make you feel like you're stuck in a Hamster Wheel of Doom.

Standard of work. By that same token, doing work for so many clients invariably means that the projects are small. And simple. Things you'll eventually outgrow.

Pay. The pay is not that much better than that of a startup. The company can pay more, but you have to constantly prove yourself because your performance is directly linked to profits. This can prove exhausting in the long run.

Like a very leaky boat at sea.

Stability. They're more stable than the average startup, which doesn't mean much. A bit of upheaval in the tides of the economy will see them scramble to cut the dead weight.

Verdict

A decent (but entirely optional) training choice early or in the middle of your career. Don't stay beyond a few years. Get the experience you need and move on.

Tech Multinational Company

These are typically the big players whose head office is often not in Singapore.

Company Size. Large. Sometimes huge.

Service Model. B2B or B2C.

Pros

A great environment.

Environment. Big spaces, janitorial services, posh business locations.

Pay and benefits. Your remuneration is likely to be competitive. You may even get dental.

Professional visibility. Google. Facebook. Microsoft. These ring a bell? They should, because they're B2C and just about everyone has heard of them. If they're purely B2B, like Cloudflare or Atlassian, then maybe not. But those in the tech industry would have heard of them, and that's no small thing. Working in a tech MNC opens new doors.

Stability. Big tech companies tend to be big for a reason. They've weathered storms, and in all likelihood, will probably be around long after you're gone.

Cons

Politics. At any large corporation, you get people jostling for position and all that juvenile shit.

Your expendibility. Again, in a large company, your contribution doesn't have as much impact. Their attitude is more along the lines of "you're lucky to be working for us" rather than "we're lucky to have you on board". There are small companies with the same attitude; then again, we aren't talking about those wannabes, are we?

Red tape. A company of that size doesn't have the luxury of making exceptions for extenuating circumstances. Everything will be strictly by the book, unless you're personally very important to the organization.

Verdict

Move on when the time is right, but this makes a great addition to any resume. If you do decide to stay for the long haul, there's always the chance of a promotion and increased benefits.

Next

Now for the non-tech companies...

Where To Find Work (Part 1/3)

Software developers looking for employment opportunities are apt to find them just about anywhere. That's because computers are a pervasive presence in today's world, and you'd be hard-pressed to find an office that doesn't use any kind of computer technology. That said, the kind of computer technology required varies wildly. Some companies need hardware support. Some need software maintenance. Some need online portals created almost constantly.

Let's take a candid look at some companies I've worked in over my long and storied career, and see what would make decent career choices. Granted, tastes vary from developer to developer, but there are some factors that should objectively help a developer make his or her decision.

Why? We should just look at the pay, right?

Ack! That's for people who don't have long-term options and have to make the largest amount of money they can in the shortest time possible, via any means necessary. You're a developer. You're a member of an industry that will be around for a long, long time. If you're just about the money, screw long-term prospects, there's a ton of more efficient options for you out there.

Factors

Tech or non-tech? Generally, career-wise for a developer, being a developer in a tech company trumps being in the IT department of a non-tech company. But that also depends on context. More later...

Company Size. This usually means a tiny startup of maybe five employees, to an Small-medium Enterprise (around twenty to a hundred employees), to a Multinational Company. However, the term "MNC" can be misleading. Some firms in Singapore calling themselves Multinational Companies have tiny branches (five to ten employees each) in Southeast Asia while the head office has about twenty to fifty employees. Technically, they are MNCs... but size-wise, they're still Small-medium Enterprises.

Most people will tell you - the bigger, the better. That's not always true.

Service Model. Business-to-business (B2B) or Business-to-consumer(B2C)? More pertinently, is what you will be doing, directly related to profits or are you pretty much a cost center? If it's the latter, it's generally a bad idea... but again, that's context-dependent.

Now for the examples!

For ease of categorization, I'll be diving them into primarily tech and non-tech companies. And, starting with one very special category... Government bodies.

Government bodies

We're not going to go into Government-affiliated bodies, and just stick to civil service and statutory boards.

Tech or non-tech? That depends on which branch of the Government you go into. If it's the SPF, that's non-tech. But if it's IMDA, then yes, that's tech.

Company Size. Definitely Multinational Company. You may think that it's weird to classify the Government of any country as a Multinational Company. That would defeat the purpose of it being this country's Government, right? Well, bear in mind that Governments have embassies situated in other countries.

Service Model. B2B.

Pros

Prospects. Prospects are definitely bright with this option. Recognition factor is high, at least within the country itself.

Stability. No manpower laws are going to be bent here, much less broken. That means you can generally be assured they won't try to screw you over illegally, or be anything less than scrupulous with your pay and benefits (which can be pretty generous).

Cons

Long-winded. Just getting your foot in the door can be a pain in the arse. They'll generally make you fill up a ton of paperwork and produce a lot of superfluous documentation... and that's before they even interview you.

Lots of paperwork.

Things move slowly due to all that slavery to procedure. So if you're in it to effect stuff, good luck.


Snootiness. Could be my imagination, but the Government bodies, or rather, their recruiters that I've interacted with, seem to have this air about them that basically says you should consider yourself fortunate to even be considered. I once declined an interview offer from one such recruiter, and her reaction was adorable. It was like nobody had ever had the audacity to turn her down before.

Tech stagnation. This being the Government, their tech tends to be more proprietary than open-source. And their tech tends to be Microsoft or Oracle/Java. You could try changing that, but I wouldn't hold my breath.

Verdict

A solid, safe choice. Though, to avoid stagnation, don't outstay your welcome. Definitely something to aim for at least once in your career.

Next

Let's take a look at tech companies.

Reference Review: Java SE 7 Programming Essentials

It was 2015 when I first picked up Java, while trying to learn Android programming. Java SE 7 Programming Essentials, authored by Michael Ernest, came in very useful as a reference.

As a fledgling Java user who has not, to this date, landed a job in that capacity, I'm nevertheless indebted to this book and its author. Outdated it may be in some parts, but the basics are explained very well and it's aided my understanding a great deal.

The Premise

Java SE 7 Programming Essentials is a book with the professed goal of preparing the reader for the Java SE 7 Oracle Certification Exam. Never having taken such an exam, I couldn't say how effective it is in that regard. What I can say is that the book appears to go above and beyond the call of duty.

The Aesthetics

Visually, with a predominantly blue-and-white theme, the book is cleanly divided into sections within each chapter and locating these sections is simple and effective.

The words aren't cluttered together and it's pretty easy on the eyes.

The Experience

Reading this book was straightforward, and digesting each chapter even more so. Even at a beginner's level, I had very little trouble figuring out what the author was trying to say.

The Interface

After each chapter, there are Additional Exercises and Review Questions, to which the answers may be found in Appendix A.

Appendix B mostly covers the Oracle Certification Exam and its list of objectives.

The margins occasionally host side-notes which feature tips and additional information.

The margins are sometimes marked by an icon to denote that the section it is appended to, is of particular importance to certification.

What I liked

The style of writing. Ernest has a way of explaining a concept that not only appears comprehensible, but actually makes sense. Take this beauty:

An empty statement, signified by the semicolon, is sufficient under the compiler rule "it's okay if it's useless, as long as it's legal."

Regarding infinite loops,

As program users, we quickly grow accustomed to letting error messages tell us something is wrong. As looping troubleshooters, we must learn to distinguish between a good kind of quiet (a busy but productive system) and a bad kind of quiet (a system happily spinning its wheels). Infinite loops will survive in your programs for as long as it takes you to recognize the difference.

Or even at the Introduction,

Certification is, in my view, a low rung. If you want to find work in this field, it's my failure to let you believe a high score on the exam will do more than bolster your confidence.

The Review Questions after each chapter, especially the answers at the Appendix A. Michael Ernest takes pains to not only provide the answers, but also to explain why the answers are correct, in the process reiterating the concepts covered in the relevant chapter.

What I didn't

The book did not provide any relevant working samples that I could use in a project. To be fair, that was not its purported purpose. Would've been a nice-to-have, though.

Conclusion

Java SE 7 Programming Essentials does a whole lot more than prepare its reader for the exam. It's not an easy read by any means, but it's a lot easier than many other Java books would be.

My Rating

7 / 10

Ernest-ly yours,
T___T