Browsed by
Tag: howto

Participating In A 24 Hour Hackathon

Participating In A 24 Hour Hackathon

Just returned from a 24 hour hackathon, sleepy, red-eyed, tired, exhausted and yet writing this post. You know why? Because I skipped it the last time, and the time before, thinking I will do it the next day and that sleep was more important, but never did it. Not going to make the same mistake again. So here I am.

For those who are unaware of what a hackathon is, it is an event where dreamy eyed people enter and leave with red eyes, it is a single night sprint where people come together to build something that they believe will make them a billionaire or like Silicon Valley series mentions time and again, ‘will make the world a better place’! Well, jokes aside, a hackathon is an event / competition where teams / individuals build software / hardware in a single sprint of 24 hours. Hackathons have a theme, ranging from generic things like improving community to specific themes like solving a specific delivery problem the company faces. Some hackathons are closed, conducted only for the members of an organization, some are open to all. Some hackathon focus on profitability of an idea and implementation, teams winning sponsorships from investors, and some focus only on ideas and imagination of the participants. All in all, a hackathon is a developer’s Disneyland!

If you feel like you have ideas, but no time to develop them, try them out or run them by other people? Hackathon is the place for you to build your dream concept into reality. You are an amazing developer, you can punch in code and get things working in no time, hackathon is the place for you to show your skills. You like to interact with people, share ideas and learn how people feel about them, hackathon is the place for you to validate your product. You have a concept, but are looking for skilled brains to develop it, hackathon is the place for you to spot skills and recruit them. You are a nerd, introvert, who loves to code (the stereotypical software developer), walk right in, there are many like you in there. You are a night-owl who believes that sleep is for ‘cats’, you will fit right into a hackathon. Imagine a place which provides electricity, wifi (I have your attention now, don’t I?), food, seating space and all else you need, and leaves you undisturbed for 24 hours with the freedom to build your dream into reality, now that is a hackathon. (Put like this, it sounds better than Disneyland!)

Now let us say you wish to go to a hackathon and ‘make the world a better place’, you need to have a plan, like everything else. There are things that you should and should not do. There are things that you should and should not carry. I have over time built a list of items I carry to a hackathon, and like other ideas validated it against others during the hackathon. So what we have here is a list of items people in general carry, not every item will apply to you though. It is like a camping list, but for geeks.

Preparing for the Hackathon

  • Prepare for your idea: Think, elaborate it, plan it. This is also a test of your agility, all your skills in iterative, agile, development are going to be tested. Know that a 24 hour hackathon is 3 working days time on your hand, it is a lot, plan how to utilize it best.
  • Choose the right team: Long hackathons tend to be team games. Choose your team wisely. You should have compatible yet slightly overlapping, targeted skills, and equal passion. You probably do not need a marketing executive or the so called ‘product owners’ on your team unless the idea is from their domain. It is not a conference, you do not get a booth there. And passion, yes, you do not want your team members jumping into sleeping bags at the chime of 10 only to get up at 6 next morning.
  • Identify what open source projects can help you, know how to use them. Play around with them. May be send a pull request for missing features. But know what is going to help you get it done faster and plan for it.
  • Set up your machines. You do not want to be downloading a database server or creating cloud service provider accounts at the hackathon.
  • Set up productivity tools suitable for your idea. For example, get accustomed to using a clipboard manager; write and keep handy scripts to automate simple tasks like starting db, launching db shell, clearing tables, generators for various frameworks etc.

Packing for the Hackathon

  • Laptop: Of course! Humans are yet to build a computer one can use to develop software on in thin air, unless that is what your idea is for the hackathon.
  • Laptop charger: You will be surprised how many people forget this. Although your machine has juice for one work day, it is not enough for a hackathon. If you think of it, it is actually 3 work days there. And you don’t want to be making ‘connections’ by asking people for charging cables.
  • Phone & charger: You are going to interact with a whole lot of people, do carry your phone to note down numbers, not everyone brings the business cards, it is not a conference. Hackathon is for thinkers and doers not talkers, yet the excessive use of phone screens drains them, so do carry your chargers. Some hackathon venues do provide charging stations, you can check to confirm if there is one.
  • Peripheral devices: If you prefer to use an external mouse, drawing pad, a VR headset or whatever you need, carry them. Pack the devices you need to build your idea, like a raspberry-pi, a hovercraft kit or whatever. Keep pen-drives handy. You can check or request if the organizers provide an external screen, it will be too huge to carry anyway. It is all developers and geeks there, I would not blame you if you do not trust the security of the wifi there. In that case, carry your own portable hotspot.
  • Identity proof: You have registered online, but the organizers need to know who you are before you can enter.
  • Toiletries: Do I need to explain? Just don’t stink, you do not want to be remembered for that.
  • Medicines: If you are on medicines, do not forget to carry them. If you get acidity by staying up late, carry antacids. You get headaches, carry a mild pain killer. Have allergies? Carry an antiallergic. Afterall it is a competition, you want to be your best throughout.

Wearing for the Hackathon

  • Wear something casual and comfortable: If suits are your thing so be it, but remember you are going to be scratching your head over a lot of things in the next few sleepless hours, be comfortable. You do not want to be scratching other parts of your body due to uncomfortable clothes. You do not need to look pretty/handsome, make-ups and hair-sprays are not required, your personal comfort is.
  • If you are representing a startup, wear them on! Hackathons are good for creating awareness and hype.
  • It is okay to wear your lucky accessories, but limit it to that, avoid the temptation to wear superman under your clothes.

Hacking at the Hackathon

  • Not literally. Do not hack others’ devices, you can get banned from the premises or worse.
  • Divide your hours like they were days. 4 hours represent your half day of work in there. Have regular discussions.
  • Divide your tasks and identify interfaces where your tasks meet.
  • Use version control systems extensively, If it is a hardware product, keep taking photos from all angles. At hackathon, I prefer to change the way I commit; usually I commit often but push after cleaning. At a hackathon I commit and push extremely frequently, on every unit completion. It would not be an exaggeration to say that make the version control system your undo log. This also help prepare for an unfortunate event if your machine decides to take a nap while you are banging the keys.
  • Ban headphones on the team. Unless there is interaction, there is no team.
  • Plan your long breaks, like lunch, dinners and snacks to be in sync with your discussions.
  • Take frequent breaks apart from the discussions, individual or team breaks, but get up and walk around. I drink a lot of water, that forces me to take frequent breaks and helps avoid health issues as well. It is also a good idea in your day to day work.
  • Do not sit it through, walk around, jump around, interact, stay active and awake.
  • If you can, take naps in between. Just make sure you allow your partners to pour a water bottle on your head to wake you up, just in case. You do not want to miss all the fun by sleeping through.
  • There tend to be side events every few hours in long hackathons, participate in them, get to know people.
  • Meet people. You will find a whole lot of them are working on something amazing. You might end up meeting your next employer, co-founder, your living idol, or even your soulmate, if you are looking for that. You never know. All those coming to the hackathon tend to be there for their passion.
  • Have fun. Win or lose, unless you have fun at the event, it is pointless. Have what fun means to you. No one forces you to take part in any of the events or to talk to people, if you just wish to code, so be it. But enjoy the 24 hours, you do not get platforms like this every day.

After the Hackathon

  • Wrap up everything, pack the items and belongings, do not forget your chargers and peripherals.
  • Have one final meeting, plan out what you would like to do with the idea and the code / product built so far.
  • Divide the tasks for the future and decide timelines. If you leave here without a plan, and if you have not won the prize, it is highly likely that the idea will never be pursued further.
  • Know that what you are feeling, the mild body ache, sleepy red eyes, it is similar to a jet-lag and treat it as such, by sleeping only at your usual timing. Avoid taking an untimely nap in the day, set your routine back as soon as possible.
  • Write a blog. 😉

If there is something that should be added to the list to make it more usable, please suggest. See you at a hackathon some day.

Creating a Coding Interview Problem

Creating a Coding Interview Problem

Creating a Coding Interview Problem

At work, I have been responsible for conducting the coding tests during the interview process, and have been doing that for over a few years now. Over the time I have made some mistakes, learnt some things and this post is a summary of what one should consider when creating a coding test.
Coding tests are generally the first round of interview; it is either online or on campus, depends, but a coding round is considered as the first gate a candidate has to cross. How you conduct it has some implications, for example, if you asked the candidate to submit code online, you may want to verify that the code was written by the candidate, they understand it and that they did it in the stipulated time. You can do that with an additional pair programming round on campus. If you conduct the test on-campus there is little room for such doubt. But then you need to ensure things like a dedicated desk or meeting room for the test, a machine, and food and coffee may be. But there are some considerations integral to coding tests themselves, these are the ones we shall be looking at today.
Before we begin, let me call out that there are those who believe that interview is not the best process to understand the suitability of a candidate, and I would not disagree. But I believe that if done right, coding tests are the best way to understand a person’s approach to problem solving, their expertise and command on programming. How to go from there is your choice.
We shall see the points I have learnt to consider when creating a test problem, we shall also discuss the the thoughts and reasoning behind them.

What to consider

Skills: What are you looking for

First is to identify the skill set you need, the practices that matter to you for the role you are looking to fill. People consider knowledge of language C as a basic expectation in computer science, but if a developer is not expected to work on C it is pointless to ask a question with C in mind. Similarly, the most attractive questions for an interviewer: questions on shortest path algorithms, sorting and searching algorithms seem pointless. If there was ever a need to use them, I would not expect any employee to implement them anyway, why expect them to implement in interview. All we need is that they understand how those algorithms work. In an interview, we need to better target the skills that matter to us. Yet, it is better to skip any frameworks that you might use, frameworks can be taught and learnt, teaching problem solving approaches takes longer. I am also of the opinion that the programming language used to solve the problem should be of the interviewee’s choice, but that is not always feasible, since we should have enough skill in that language to review the code they submit!

Prioritize: What is the value of each practice/skill to you

Prioritize the skills in these categories: ‘must have’, ‘should have’, ‘good to have’ and ‘cool to have’. Model the problem in a way that targets the ‘must have’ skills and probably touches on some ‘should have’ skills. Skip anything under ‘cool’ category. This is not to say that we should hire a person who can do only the job we require them to do at the time of hiring. It is to say that the person should be able to do at-least that much. You have rest of the interview process to assess the person’s ability to learn or apply creativity, coding test is the gating criteria.

Time: How much time can you allot for the test

This matters a little in an online test, but is a huge consideration in an on-campus test. For on campus tests we need to have provisions for machines, food and meeting room or desk. If it is an interview drive, we need plan for as many number of machines as there are candidates or divide the candidates in batches, with delay in batches equivalent to time for test. If it is an online test, how much time to provide the candidate to revert and if the candidate can get a weekend to revert are considerations as well. Either way, how much time do we demand from the candidate is a question and we need to decide on a problem that needs an estimated amount of time to solve.
It is also important to accommodate for the pressure the candidate may be under during the test. This matters even more for on-campus tests; it can put your time calculations off considerably. I try to make the problem statement very clear and as definitive as possible. Being explicit about what is expected and what is not helps, because an unclear question leaves room for random implementations or shortcuts where I least expect them. That makes it difficult to evaluate the solutions on equal grounds. On the other hand, unclear questions leave room for creativity, but I have seen people missing the point with these.

Branding: Showcase how you are

Interview is a window, window for the company into the candidate’s capabilities and window for candidate into company’s culture. Just as the company needs to like the candidate, the candidate needs to like the company. And the problem statement is the first impression of the company! It is important to make the problem ‘fun’ to work on. I prefer to use casual way to describe the problem and try to make it enjoyable to read and to solve. It should have the feel of a fun place. You should choose a style that best describes your organization. As a side note, nerd jokes or references to Hitchhiker’s Guide to the Galaxy or Star Wars do not always work. 😉

Creating the problem statement

Over the period I established a process for creating the problem statement, enabling a predictable estimation of time and solution. Over time you can choose to skip some of the steps, but to begin with here is the process: 
  1. Once the problem is identified, create the write-up describing it. Instructions, guidelines and rules about time, how to submit the code, languages allowed etc should be mentioned at the top.
  2. Once the problem statement is formulated, ask a peer to read and explain it to you. Ensure it means what you expect it to mean.
  3. Solve the problem. Record the time.
  4. Ask a peer to solve the problem, record the time taken. The peer here should be from the target experience range and skillset. Ask for their experience.
  5. Anything you learn during these discussions, or while solving the problem, convert them into instructions and add them to the top.
  6. Fix the scope of the problem to fit the time.
  7. Solve again, when you are in a different mindset and record the time.
This process, although tedious, sets the expectations right. Ponder on how good is your solution in that time and how acceptable are your mistakes to yourself. Consider that you already knew the problem and had (unknowingly/knowingly) designed a solution in your mind. That should help set expectations from an interviewee ‘under pressure, under time limit, likely less experienced than yourself, groomed in different culture with different practices than yours who was just presented the question.’ Sounds difficult, right? It is not to mean that the evaluation should be lenient though, it is only to identify what is acceptable.
While evaluating, one should remember that you are not looking for candidates who solve the question the same way as you do. In other words, you are not looking for candidates who think just like you. The different the better, it is always surprising how many different ways you find the problem solved.
That’s all from me, all the best for finding the right candidates!
Using Docker and a Private Registry with VPN On Windows

Using Docker and a Private Registry with VPN On Windows

Wasn’t that a very specific title? Docker has a very good documentation and reading that alone is enough for most of the straightforward tasks we might want to do. But as always some practical tasks are not straightforward, hence this blog. What we are going to see here today is how to setup docker toolbox on a Windows machine, make it work even when VPN is connected, make it talk to a private, insecure docker registry (that is why VPN) and configure it so it can run docker compose and see how we can set this config as a one-time activity. That’s quite a mouthful, but yes this is what we are going to do. All ready? Let us begin then.

Install Docker Toolbox

Go and download the docker toolbox and install it. That should create a shortcut called “Docker Quickstart Terminal”. Run it. That should show you an error about virtualization.

Enable Virtualization

Restart your machine, enter the BIOS settings and enable virtualization. It may be under advanced settings. On this Laptop, it is under the advanced settings -> device configurations and is named as: “Virtualization Technology (VTx)”. Whatever be the name, enable it.
Docker requires a Linux kernel, and since Windows machines lack it (of course!), docker toolbox runs a lightweight Linux distro called boot2docker in a virtualbox, hence the virtualization setting.

A Handy Tip

This tutorial will require you to copy and paste quite some shell commands, it is better we make that easy. Exit the quickstart terminal. Right click the shortcut, click properties -> options and enable ‘Quick Edit’ mode and save. It might ask for permission. This should now enable paste just by right clicking the mouse, to copy just select the text with mouse. While we are at that, also consider increasing the buffer and window size to suite your taste.

Start Up the VM

Make sure you are not connected to VPN and use the Quickstart Terminal shortcut again, this time it should proceed to validate if the boot2docker image is latest, or it shall pull the latest image, then it shall create a VM, get an IP, setup some ssh keys and finally the whale should appear with a terminal. Run the following commands to get a hang of docker running on windows:
docker -v
docker version
then docker run hello-world
docker images
docker ps -a
(And do read the output of hello-world, it describes how docker works). 

The Disappointment

Feeling happy? Now for a little disappointment, connect VPN and try again. Errors errors everywhere. Disconnect VPN. What happened: Docker is running in a virtualbox on your machine, which gets an IP in local range (normally:, and you are talking to it over ssh. Once VPN is up, it sets the new routes and sends the 192.168.* range traffic out over VPN and your commands never reach your VM running docker. The most popular solution to this is setting a port forwarding and is documented on many blogs/githubissues. Let’s just do that.

A new Beginning

Ensure you are not on VPN and remove the default VM, not necessary, but reduces the confusion. So in the quickstart terminal:
docker-machine rm default

And confirm. We are now going to create a new VM, let us call it ‘custom’. So type in:

docker-machine create -d virtualbox custom
eval "$(docker-machine env custom)"

It might take a couple of minutes, it is almost the same process as the first time. What we did is created a VM named custom and setup the environment to talk to this VM instead of the default. Mark this step, cause if anything goes wrong in the following steps, this is the one you should get back to to start over. Just be sure to use a new name, docker currently does not allow reusing names for VMs, so next time you may not be able to create a VM called custom. A new name should work just fine.

Battling With VPN

Now we shall create the a port forwarding on the virtual machine, binding the default docker port (2376) on localhost/ to forward to this VM, whatever the ip of it.
docker-machine stop custom
/c/Program Files/Oracle/VirtualBox/VBoxManage.exe modifyvm "custom" --natpf1 "docker,tcp,,2376,,2376"
docker-machine start custom
docker ps -a
If you changed the location of virtualbox installation, please use appropriate path to vboxmanage. Assuming it was successful, last command should show you a table with all containers. You can use UI to do that as well: Open VirtualBox, stop the VM, open settings -> network -> NAT adapter -> advanced -> Port forwarding. Click add rule and use the same values as above (comma separates columns). If the command was successful, you should see the rule listed at the same location. Also, this is the place to add an entry if you need any port exposed from a docker container and use it with VPN enabled; for example your application’s tomcat port.
We are not done yet, a few more commands:
export DOCKER_HOST="tcp://localhost:2376"
alias docker="docker --tlsverify=false"
Kudos to this smart guy for that alias. In other posts, you might find IP of the VM (which does not work), public IP of your machine, or even loopback IP ( being used, which might work but I would advise against that. Use ‘localhost’ instead; this and the TLS setting has to do with running docker-compose.
Now enable VPN and enjoy docker. This is where your journey ends if you are not using a private registry; but if you are, then continue.

Configuring Private Insecure Registry

Ensure that VPN is down, and ssh into the docker-machine. We want to enable it to talk to an insecure registry. A private docker registry does not need a name, but docker images in a non-docker-hub registry require that they be tagged with the URL of the registry prefixed to the usual repository name. They say it is for transparency, helps in identifying where the image originates from. Hence, it would be advisable to have a host-name even if your registry is private and has a static IP. That way even if you change the IP of the registry for whatever reason, you do not have to update all images/tags/compose ymls, shell scripts and whatever else is using them. Let us say our registry is hosted at:, on port 5000 and this being insecure, of course, is accessible only over VPN.
This step is intentionally manual, to avoid risks of breaking something else:
docker-machine ssh custom
sudo vi /var/lib/boot2docker/profile
In the EXTRA_ARGS, before the closing quote, add this line: 
(I would ensure a blank line before the quote, as there already was) Save the file and exit vi (:wq). We now need to restart the docker daemon for changes to take effect:


sudo /etc/init.d/docker stop
Ensure service is down:  sudo /etc/init.d/docker status
sudo /etc/init.d/docker start
Ensure service is up: sudo /etc/init.d/docker status 
Exit the VM by typing exit in terminal. (BTW, there is restart command too)

Using the registry

Now let us try pushing and pulling from this registry. In the quickstart terminal: 
docker tag hello-world
docker push
docker rmi
docker run
What we did is tagged an image with the registry, pushed it to the private registry, removed the local copy and run the image by pulling from this registry.

Docker Compose

Next step is to get docker compose up and running with this setup. Actually, we are already ready, everything that we need to run docker-compose is taken care of in the previous steps. Most importantly docker-host configuration. You see, the TLS certs allow only for docker-machine IP and localhost to be used even when we disable verification, but we have already taken that into account and we have already configured our private registry. All set. Just connect VPN, navigate to your directory with docker-compose.yml file and hit: docker-compose up. You should see the images in compose file getting pulled and executed. 

Starting the quickstart terminal second time

When you restart the quickstart terminal you might find that it recreates the ‘default’ VM and configures the environment to use it. That is okay, it does not bother us. But what does bother us is that none of the docker commands are working with VPN again. Please keep reading..

Consecutive starts of quickstart terminal

Well, we have to reconfigure the terminal every time to use our VM of choice. Here is how to do it:
Always make sure that you start the terminal when VPN is down. Starting with VPN up has never worked for me; and then run these commands:
eval "$(docker-machine env custom)"
export DOCKER_HOST="tcp://localhost:2376"
alias docker="docker --tlsverify=false"
Yes, every time you start the terminal. There is a way to avoid this, read on. 

One Time Setup: For The Brave Among Us

From this point on, you are entering undocumented territory and are on your own. If something breaks, do not come looking for me. 🙂 And before making any modifications, take a backup.
If you notice, the shortcut points to a shell script called ‘’. We are going to modify this script to auto-configure our environment every time it is called. Navigate to docker installation directory (directory that quickstart shortcut is pointing to) and open the (After creating a backup) file in a text editor.
Change 1: On line number 10 which looks like: VM=${DOCKER_MACHINE_NAME-default}
change that line to: VM=custom. Custom here is the name of our VM. This saves you from typing the eval line every time.
Change 2: On line 66/67, in “Setting Env” step, after the existing eval command add the following lines:
eval "DOCKER_HOST="tcp://localhost:2376""
eval "alias docker=docker --tlsverify=false"
These handle rest of the config. That is all, save and exit the file and we are ready to roll. This may break when an update the docker toolbox is installed which overwrites the file, may not work if the script changes in future, may break things I am not aware of, hence only for the brave. Besides, I do not use a Windows machine daily, so you guys would be first to know if it starts breaking ;). Let me know and we will figure it out.
How to add a nice code block to blogger

How to add a nice code block to blogger

While there are awesome syntax highlighting and styling libraries  with nicely written tutorials for using them with blogger, a simple ‘code’ tag can suffice at times…

For such times:

.myCodeHighlighter {
border-left: 4px solid #FF9933;
display: block;
font-family: Courier,"Courier New",monospace;
margin: 15px;
overflow: auto;
padding: 15px;
text-align: left;
white-space: nowrap;

And use as:

<code class="myCodeHighlighter">
//the code codes here..

A preview of how it will make your code tags look like? You are looking right at it! 🙂