Do recruiters still need to ask for resume / CV printouts?

In a digitized world, it is quite a paradox that companies still require interviewees to bring a printout of their resume or interview invite email.

If the phrase"save trees" makes you roll your eyes, then please feel free to stop reading. The rest of this blog post requires a more creative and inventive mind to interpret it.


Why in the world would you require printouts?

Assume a company conducting just 100 interviews every three months.

• That's 100 * 3 sheets of paper on average * 4 quarters a year = 1200 pages.
• For 3000 companies in a city, that's = 1200 * 3000 = 3.6 million pages a year!!! With that much of paper, you can make 293.49 copies of the Indian Constitution. The bulkiest constitution in the world! As for cost, that'd be 7.2 million Indian Rupees.
• And oh...in terms of trees, that's 432 of them.
• On top of that, you also want candidates to carry a printout of the interview call email?
• Some companies even expect candidates to carry and submit photocopies of their marks card and resume even if they have not yet been selected by the interviewer (when you ask a candidate to submit exactly the same details a million times, it's a sign that your recruitment process is messed up. Ever heard of referential integrity?).
• Then there's the entering of candidate details on a bunch of paper forms!

Seriously, HR departments...haven't a single one of you considered moving into the digital age?

What can be done:

• Let interviewers use their work laptops to view documents. 
• Specifically ask the candidate not to bring a printout of anything. 
• Candidates can email their resume and scanned copies of other documents.
• They can bring a copy of the interview call email on their smartphone (a copy of this email is usually asked for by the security guard).
• If candidates are expected to fill in their details in a form (do you even need a form? Why not fill in details after being selected?), allow them to do it via an online form (perhaps even a day before the interview). You could even create a user friendly form that could be used on a smartphone. Create forms that  can be shared with the candidate on the smartphone via bluetooth (if the candidate does not have connectivity to the internet).
• If the candidate wishes to share any additional documents, it could be done either via Google drive, bluetooth or via a pen-drive or rewritable CD/DVD. Make sure you use the pen drive on either a Linux or Mac OS, to avoid those annoying Windows viruses.

Yes, I know you might be a company which has very strict security and device policies. Do understand that these policies and security are meant to prevent sensitive company information from leaking out; not for preventing candidate information from coming into the company.

A creative/inventive mind will always find a way to create facilities and spaces where interviews can still be conducted with a minimal use of paper.
Once you've become digital, shout it out! Let the world know that your department is awesome! Spread the news. It really is time to get out of the feudal age.

No more printouts!!!

If you want to hear the magic word before going digital, here's me saying "Pleeeeeeease!!!".

Automation: Script to set up tabs for you in a single terminal and run commands in them

I noticed many colleagues loved opening up multiple tabs in a single bash terminal, setting title names for every tab and running commands in them. They performed this ritual manually every single day.

The first thought that went through my mind was "Hey, why don't we automate the process?". I suggested it to them, but I guess they preferred doing it the old way. So when I had some free time, I did a bit of finding out and created this shell script:


#!/bin/bash 
#The ampersand in the end of this file makes sure that the gnome-terminal command is run as a background process. 

echo "Setting up environment"; 

gnome-terminal \ 
--tab-with-profile=Default --title=TAB1 -e "bash -c \"trap 'bash' 2; clear; ls; exec bash\"" \ 
--tab-with-profile=Default --title=ANOTHERTAB -e "bash -c \"trap 'bash' 2; clear; ls; pwd; exec bash\"" \
&

Place this code in an empty file named sim.sh and use the command 

chmod +x sim.sh 

to make it an executable file and then run it with

./sim.sh

and viola! You have a terminal with multiple tabs! Just replace the "clear;ls" and "clear;ls;pwd" with any other commands of your choice.

The syntax for adding more tabs is:

--tab-with-profile=Default --title=<THE TITLE YOU WANT TO GIVE THE TAB> -e "bash -c \"trap 'bash' 2; <THE BASH COMMANDS YOU WANT TO EXECUTE> ;exec bash\"" \ 

One more thing to do

Having the script is not enough. You'll notice that when you finish running any commands on the terminal, the tab title/name you set, would have gotten reset.

To circumvent this problem, do this:

Go to the Edit menu of the terminal. In Profiles select Default. For the option of When terminal commands set their own titles, select Keep initial title. 

That's it! Don't stop at this. Keep finding ways to automate tasks and save time!

How to solve Git merge conflicts using kdiff?

KDiff's windows (or any other three way merge tool's windows) aren't quite so intuitive, so here's some help.

Let's say you've worked on the master branch

and somebody else worked on a "tryingOutSomething" branch

...and you decide to merge that person's changes into your code.

But Git complains that there are merge conflicts!
Turns out the other person was working on the same file you were working on, and also on the same lines.

GitExtensions refers you to KDiff3 to solve the merge conflicts. Select the option to start merging and you see a screen with four sections.

Click image to view larger

The sections from right to left are:

• Section C: The code of the branch you are going to merge into your branch.
• Section B: The code of your current branch.
• Section A: The code that is in the commit which is a common ancestor of B and C. Don't bother about section A. You'd hardly ever use it.
• Bottom section: It's what your code will look like once you've done the merges and save the file.

You can manually make changes or copy code and paste it into the bottom section like this:

The "m" I've circled in green, is KDiff's indication that it is a line of code that's not from section A, B or C. It's a line that you manually modified.

Or, note that the extreme left of the bottom section is segregated into areas where there are merge conflicts and it shows letters A, B, C or m. Any letters that are present before you started merging (indicated in the image below by the red arrows pointing leftward), are merges that happened automatically. If that's not what you wanted to merge, click on the letter in the bottom-left section and select A, B or C in the toolbar on top (indicated in the below image by the red arrow pointing upward).

You can even edit the automatically merged conflicts and choose A, B or C or edit it manually.

That's it. Now just save and exit, and Git will allow you to commit.

Solution to another issue:
You'll see a residual file of the merge, which has a ".orig" extension. Don't commit it. Just delete it.
In case your merging went wrong and Git says "You have not concluded your merge (MERGE_HEAD exists)", then just go into the hidden ".git" folder and delete the files named:
MERGE_HEAD, MERGE_MODE and MERGE_MSG.
After deleting those files, you'll be able to do the merging again. Do it carefully this time and save and exit.

All the best! :-)

Aha!

Today is a little turning point for the LOL pages. They are now "Aha's!!!". Laughing Out Loud is not really what happens when one reads the little jokes I put up here. Aha describes the emotion better. Here we go...

Festival Sale

Share with this link

Continued in the next Aha!.

 

 

It's just about using the Hungarian variable naming convention appropriately

"...and when bmeJames oBond pulled the ftrigger, the sivillian jumped in the mwater."

This is what programmers are put through when reading or writing code in companies where somebody, some-day, misunderstood what the Hungarian notation was actually meant for and created a company policy of naming variables as such.

• bBusy : boolean
• chInitial : char
• cApples : count of items
• dwLightYears : double word
• fBusy : float (or flag)

Apps Hungarian is the original Hungarian. Not Systems Hungarian. If your programmers are annoyed with this notation, they are not wrong. See what the creator of C++ and the creator of Linux have to say about Hungarian:

Bjarne Stroustrup:

No I don't recommend 'Hungarian'. I regard 'Hungarian' (embedding an abbreviated version of a type in a variable name) as a technique that can be useful in untyped languages, but is completely unsuitable for a language that supports generic programming and object-oriented programming — both of which emphasize selection of operations based on the type and arguments (known to the language or to the run-time support). In this case, 'building the type of an object into names' simply complicates and minimizes abstraction.

Linus Torvalds:

Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged—the compiler knows the types anyway and can check those, and it only confuses the programmer.

How it all began

It started when Microsoft's chief architect, Dr.Charles Simonyi started it and it came to be known as "Hungarian" because it made variable names look as if they're non-English and also because Dr.Charles is originally from Hungary.
While Microsoft has a respectful article about him, praising how the introduction of the notation helped programmers write better code faster, the adulation could also just be the result of the influence of a powerful person. Given that in the days of the DOS operating system compilers weren't as programmer-friendly, and not being very careful with datatypes could lead to costly bugs when thousands of lines of code were involved, the Hungarian notation could have really helped programmers of that time.


My take on it: The Rudder Notation enhancement

Today's IDE's just need you to hover over a variable to view its type. But inspite of modern IDE's there are people who still find Hungarian useful. It can be useful when maintaining languages which use dynamic typing (JavaScript, for example).

Moreover, although there are various reasons for not using Hungarian, I just need one reason: Readability. We read left to right. Even in the days of DOS OS'es, variables would have been far more readable if the Hungarian notation were used as such:

variableName_typeInformation

Keep the type information away from the variable name with a distinct underscore and keep it on the right side of the camel-case variable. Of course, now that it looks exactly like English, you won't be able to call it the Hungarian notation anymore.

I named it the "Rudder notation" because the type information projects out of the name, pretty much like the rudder of a boat or plane, while also performing the function of guiding the developer or code-reviewer.

Are the variables more readable now?

• busy_b : boolean
• initial_ch : char
• apples_c : count of items
• lightYears_dw : double word
• busy_f : float (or flag)

Some people want to use Hungarian because they may some-day take printouts of their code. Really? Then you're very likely doing something very wrong somewhere. Others have written long posts on Hungarian; but really...

...what you need to do, is identify which variables could mistakenly introduce bugs in your code, and apply the Rudder notation to them. This identification is very much dependent on what kind of application you are building, and not on the language or the datatype.

Forming a policy for your programmers to follow by doing a monkey-see-monkey-do of somebody else's Hungarian policy would not just be unwise, it would create a culture where team leads force ideas onto the team without understanding the idea, and cause disgruntlement within teams who don't see the point or value that the policy adds to their work. Instead, educate them to recognize potential problem areas and create a culture where they share this info with each other. Creates a better sense of ownership.

-----------------------------------------------------------------------------------------

Update: Apparently I'm not the first person to suggest the underscore for Hungarian (but I'm the one who christened it the "Rudder notation"). c2.com pointed me to 'experts' who have already encouraged it: http://www.intentsoft.com/hungarian_notat/