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.

As a student of Computer Science, a university can have two roles. One is to teach you how the very fundamentals of Computer Science and the other is to teach you how to think independently in situations which you may not have encountered before. Situations in which you can use your creativity and intelligence to develop better solutions. The latter is highly important because that is the one which makes use of all your gray matter. But now I feel it may not be so important.

How many jobs can you think of in the industry where you will be working on something new? Something exciting? Something that will keep you up at night trying to think out an elegant yet logical solution? Not many I would say. Most of the time, when you join a place as a Software Developer or a Programmer or an Analyst, you will be working on something that has been developed by someone else. Sometimes it will be interesting, most of the time, not. Most of the time you will be maintaining, and not developing. It is no one’s fault, it just the way industry works.

The Software Developer is dead. Long live the Software Maintainer.

This thursday and friday my company , held its quarterly innovation day event. This is similar to Google’s own Innovation Time Off or Atlassian’s FedEx days . In short, we as employees got to propose ideas beforehand and then work on them for two whole days. Towards the end of friday, we got to present our efforts in front of the company and the best ideas got a business impetus to be developed as a company feature. The result of the last innovation day was the open sourcing of the page model developed in house called Gizmo by Luke Cunningham.

So last thursday, I decided to join forces with Geoffrey Giesemann on his idea of visualising suburbs and their corresponding information onto google maps. In this, I hoped my recent knowledge of their V3 API would come in handy. So we started at about lunch time on thursday and we split the task on basis of front and back end. The back end became Geoff’s task and he decided to write a rails application to load the monstrously verbose and complicated suburbs’ file and parse to JSON in a neat form. (Neat here being defined by the lack of extraneous data). My task became the front end. That is, to mock the JSON data that Geoff would provide and set up the map to display it. And thankfully, my knowledge from the recent devfest did come in handy 🙂 .

I started with a simple map and ensured that I could load the defaults and set up a single marker. This was fairly easy as the new API is very intuitive to work with. Then came adding additional controls to the top left of the map, which we decided would be the capital cities of the states. This would allow us to go directly to the geographical centers of the states, or centre of Australia, if we wanted. The mock data simply comprised of suburb name, its geocodes (latitude and longitude) and the name state it belonged to. I started out with a hundred suburbs and loaded them, using default markers in firefox and the whole thing was working neatly. I set up the info windows and was disappointed when I found out that the content was simple HTML(I was hoping for more controls, they are fun). The fun started when I loaded all the suburbs from Australia that I could find (in this case 15,000).

The fun was that with 15000 suburbs, all my browsers crashed; Firefox, Safari, Chrome. Someone suggested lynx but we had to decline, even though ASCII representation was tempting 😛 . So we decided to use clustering. Now V2 API used to have a MarkerClusterer, but for V3 Fluster2 was recommended. And rightly so. It was very easy to use and even easier to understand; even for someone like me who has not done much Javascript. But even after we clustered the suburbs, only Chrome could manage the load, probably due to its V8 engine. Once we dropped it in, the result was as follows:

Then we added custom markers for suburbs based on their state.

custom markers on hobart

These markers were obtained from google’s map icon repository.

and some information on the InfoWindow

info window over darwin

and our front end was complete. Geoffrey soon provided the the actual JSON data and after optimising our JS code to handle such a large load, we had a very nice application.

P.s Particular thanks to Daniel Hall who made me understand why the ‘A’ in AJAX stands for asynchronous.