The art of technical interviews is an old one, but not always a well practised one. There are always a few variables and a lot of theories. Should they be long? Many ? How about spread out? Or all in one day? Recently, we have had to conduct a few and I think I have learnt a few things from them. When I combine these ones with the ones I have given in the past, I have come to the following conclusions from the point of view of an interviewer:

  • It should be hard to pass an interview. You are not there to make the interview easy. Making the interviewee comfortable and making the interview easy are not the same thing, and too often the difference is glossed over. You are not there to be friends, and you are not there to be his or her mentor. Be nice, but blunt and if you spot a weakness in understanding, zero in and don’t let go till you have identified why that weakness is there.
  • Don’t assume anything. Don’t assume they know what a source control is! Do not assume they understand the difference between static and dynamic types! Do not assume they understand what your business model is! Ask ask and then ask some more.
  • Codility does not tell you how the person thinks. It tells you whether they can solve a programming puzzle quickly. You want to find out how a person thinks and whether there is decent base beneath the layers of programming on top. What you want is a person who can think for himself, learn and build on his understanding. What you do not want is a code monkey who likes typing characters. So create a simple coding test by all means, but rather than using codility, put it in a git repository which you then mail to them. Get them to solve the problem, test it and send it back to you in a day or two. Then you read the commit logs. That will tell you more about how a person thinks than codility. It also has the added benefit of demonstrating to you whatever it is you wanted from Codility.
  • When you get the person into your office, make sure they spend an hour pairing with an experienced developer on an existing feature that is being developed. This should be enough to show whether the person has had some pairing experience; whether the person can navigate while someone else is typing and point out errors; whether the person commits often, tests regularly etc etc. Most of all, it will tell you whether the person stops his pair to ask something which he does not understand.
  • Make sure that the person is a cultural fit. This is the most easy thing to stuff up as it is the hardest to check in a short amount of time. Which is why most companies should have probationary periods for new comers.

In the end, the worst case scenario is that the person you hired turned out to not be what you wanted and you will have to let them go! The only caveat at that point is that if you and the person are not a good match, make sure that it is not a surprise to that person, otherwise it is fair on neither of you.

My thoughts on DevOPS on the REA Engineering Blog.

Excerpt:

It should not be marketed as position to slot one person in, or even rotate people through. A software developer who writes the code should be as concerned about his/her code working in production as he/she is in development. Definitely operations are more experienced with deployment and maintenance of products in production like environments, but that does not mean a developer should not base his software decisions before being aware of implications of deploying it in production, or be unaware of the status of his code after it passes quality assurance. The thinking behind devops is the critical bit of software development.

Prologue:

Deep in the history of the world, when Earth was no longer a child in the solar system, its denizens will ask, how did we get here! How did we let it take over, despite all that Arnie told us. And the answer will be, because it came under another name and another guise. Because we let it, and because it was awesome. It was not called Skynet, but Android.

Back in 2011

Today was fun. Woke up way too early in the morning because my body is in pay back mode for putting it through God knows how many time zones. So at 0300 hrs, found myself at my laptop talking to my parents on Skype because for them in Kashmir, it was 1900 hrs. At about 0830 hrs, went to the Moscone West center to the conference and was immediately greeted by this

What I had not realised until then was that this years conference was going to be attended by about 5000 people. And all of them had decided to attend the keynote speech this year. It was packed but the arrangements were very nice and the keynote was very engaging and hands on. My favourite axiom is “Show, don’t tell”. And that is exactly what most of the keynote was. Demos! And they were awesome!

We started with what Android had done in the last year or so, the facts and the figures, the adoption and activation rates. Then they began showing a bit about the honeycomb roadmap, announcing Honeycomb 3.1 and how they were bringing it to Google TV as well. They unveiled their plans for the next iteration of android OS, Ice Cream Sandwhich.

The Keynote also had highlights about the new Open Accessory Standard and it was wonderful watching demos of how android devices integrated with exercise bikes, and game boards and lights etc.

It was very nice as well hearing from the development teams about what they had done and also where they were taking android. Movies for rent across devices, music in the cloud (BETA) and android across devices; allowing developers to write apps for Google TV as well. It was great fun.

Also, all 5000 developers got given a Samsung Galaxy Tab. 😀

After the keynote, the session began and the ones I attended the one called Honeycomb Highlights where they presented what was new in the OS and how to go about using it. They demoed some of the stuff and also showed how to use Render Script, for both graphics and computation.

After that I found my way to Secrets and Surprises of Geo APIS’s but sadly it was not much of a surprise.
They were still demoing most things which I had seen at last years dev fest in Sydney. The one thing that was new though was the ability to create heat maps on the fly from Fusion tables layered on maps or earth.

After that I attended a session where the presenters put Java Puzzlers and it was very interesting. I learnt about type erasure, bridge methods and how varargs and collections do not go well together.

After that attended a fire side chat with the Android team

And then after that attended a developer sandbox with the Chrome team. It was good fun.

Looking forward to tomorrow!

I just realised that simply using Prey would probably put you within some walkable distance of your stolen/lost laptop, but if the place was say a shopping centre, then you would be screwed. Then I remembered this xkcd comic, and decided to do something similar.

SSH into the system using the IP address generated by Prey. Raise the volume to maximum.

[damascus:~] sudo osascript -e “set Volume 10”

And then play some music file.

[damascus:~] afplay ~/Desktop/Symphony_IX_IV.mp3

Hopefully, the music should be loud enough for you to locate the laptop, even if through people’s reaction to a sudden loud orchestra amongst them.

But if you are not satisfied with this, then just use the say to speech synthesise words from the command line after you have raised the volume.

[damascus:~] say “This laptop is stolen! Help! Call the Cops!”

Sometime ago, a friend of mine lost his laptop in a taxi and never saw it again. And today, Humpy showed me this video, and I decided time had come to do something about my laptop and my iPhone.

The iPhone was easy, ever since tracking your iPhone came free with the iOS 4.2 through the Mobile Me subscription. I set up a Mobile Me account on my iPhone, and then simply went to MobileMe and then checked the map for my phone.

I highly approve of the fact that I can send a message, lock and even wipe my phone in case its stolen or lost, but one thing I would have loved, would have been to get a picture of the person holding it. But this is a good start. Onto securing my laptop. I initially thought a daemon running in the background would be enough. And I even wrote a small one :

#!/bin/bash
PING=/sbin/ping
CURL=/opt/local/bin/curl
MAIL=/usr/bin/mail

output=`${PING} -t1 google.com`

connected=`echo $output | grep ‘unable’`
curr_date=`date`
email_address=”ipaddress.of.mujtaba.laptop@gmail.com”

if [ “x$connected” = “x” ]; then
ip=`${CURL} -s http://checkip.dyndns.org | sed ‘s/[a-zA-Z/<> :]//g’`
echo “Your IP = $ip” | mail -s “IP on $curr_date” $email_address
fi

And then I realised I am probably not the first person to have thought of securing my laptop and a quick google search proved that. A post on teknobites caught my attention and I was directed onto Prey. Installation was easy and setting up the daemon happened quickly. I went to the panel, logged in and marked my laptop as missing, set report duration and waited patiently.

Lo and Behold 🙂 there was my laptop.

And what the scallywag was doing, and what he was logged in as :

And the best thing, it even takes the picture of the scallywag. 🙂

Me likey!

Hats off to guys at Prey.