One interview early in my career left such a mark on me that it changed the way I approach technical interviews ever since.<\/p>\n\n\n\n
The first step: I was given a take-home assignment to write a program that would round dollar amounts to the nearest five cents. The best part about this assignment? I got to pick which language to use<\/a> out of three options.<\/p>\n\n\n\n Then, I submitted the assignment, somebody reviewed it, and I got called in for a live interview. They gave me the heads up to come in familiar with the code I had submitted. <\/p>\n\n\n\n During the on-site interview, we did a pairing session on my code with myself and two other interviewers (sharing a single keyboard) to refactor my code. We all came up with ideas on how to improve the code. At the time I was unfamiliar with unit testing, so the interviewers showed me an example or two of some unit tests and then had me write some. <\/p>\n\n\n\n I left the interview having learned something. Even more, I actually connected with and collaborated with the interviewers. I thought to myself, even if I don\u2019t get this job, the interview was a win. (I did get the job btw).<\/p>\n\n\n\n In every interview process I\u2019ve gone through since, the good ones all had one thing in common \u2013 the exercise felt more like a paired programming exercise than a whiteboard exercise.<\/p>\n\n\n\n At CoderPad, we just finished building a new feature called Duplicate Pads<\/a>. The use case I\u2019m most excited about? It makes pairing during the interview easier than ever.\u00a0<\/p>\n\n\n