Prepare for the interview

Dear Candidates,

When you come in for an in person interview please consider the following.

  1. Bring your own hydration. As a candidate you should expect to do a lot of talking. Come prepared and bring your own water bottle. This will also show that you came prepared.
  2. Listen to the questions well. Given that you will be doing a lot of talking, use some time to listen to questions as well. Don’t interrupt the interviewer and try to understand the question very well. Then reply.
  3. Ask question or clarification. If you don’t understand the question well or you would like to know of more context before answering the question — ask us the question. Try to use the time in the interview as if you know the interviewer and you are on the same team. At work – you would ask others for help or clarification, right? Do the same in the interview. Be respectful and ask for the clarification. Repeat the question back to the interviewer just to make sure you got that right.
  4. Get up and use the whiteboard. If you are in an in person interview and if there is a whiteboard available in the meeting room – get up and use it to support your responses. Most of the times we will setup an in person interview in a room that has whiteboards with a purpose. Don’t wait for us to ask you to use the white board, use it instead. Show the initiative.
  5. Be aware of what you don’t know and be prepared to address it. When you join a new team or a company there will be a learning curve. We understand that and we would have built in “some of the” learning curve, training needs etc into our plans and estimates. As a hiring manager though we would like to know how would the candidate balance delivery and learning. We would like to know more about the attitude of the candidate and how the candidate would accept this situation. Be prepared to answer this question. Show the interviewing team that you have been in this situation before and how you handled it. Tell us and convince us are prepared. Don’t expect all of your learning to happen within the 8-5 work hours only.
  6. Be prepared to be put on the spot. In the interview – you will be put on spot. Be prepared for that. If there is something on your resume the interviewer will ask you about it. They will probe the depth of your knowledge on a specific topic and the breadth of your technology coverage. We will also ask you about how you will work in a specific scenario. For example – let’s say you are hired and this is your first week on the project. You are asked to work on so – and – so task. What would you do? The goal of such questions is not only to see how you can build out a technical solution but also to see how you would work in a team. What kind of relationships would you want to build, what kind of help you would need from them, how you would escalate issues and discuss solutions.
  7. Keep an online profile and highlight it. These days everyone would have a linkedin or github or some kind of professional online profile. Highlight this in your resume. Note that I am not talking about your personal facebook profile or anything. If you don’t have an online profile of some kind that is not a good sign.

Often times a quick way to judge your proficiency level with a skills is to ask how would you rate yourself on a scale of 1 – 10. This is the scale we usually think of. In the top 1 skill you claim to have we would expect you to be at a 8+ level. In the next top 2 skills you claim we would expect you to be at 6+. For most of the other skills on your resume you should be 3 or a 4 at least.

On a scale of 1 – 10 please rate yourself on the following

10 = You are an expert, can write a book on this topic, you are on the forefront of latest advances and frameworks

9 = You have used this extensively, can design architectures, can explain anything on this topic to other tech leads and management, you have actually tried out some of the latest advances and frameworks

8 = You have used this extensively, can work with complex requirements, can work on complex debugging scenarios, can mentor developers, you are well aware of the latest advances in this area

7 = You have used this extensively, can mentor developers and you understand concepts very well, used it on more than 1 projects

6 = You have used this on one project, in a good capacity and learned it grounds up and are now a defacto expert on this on the current project

5 = You have used this on one project, in good capacity, learned it grounds up and know this very well

4 = You have used it on one project, and did a POC at work

3 = You have not used on a project, did a POC though at home though.

2 = You have heard of this framework / technology, read a few articles, never used it though

1 = Never used or heard of this framework



Unit Tests Assertion Coverage

A unit test case is made of three parts – the “given”, “when”, “then”. The “given” is the piece of code that set’s up mock objects, data that needs available and dependencies that need to be injected. The “when” will execute the method under test. The “then” verifies the results of the execution of the method under test.

Too often it is observed that the unit tests do not have enough of the “then” statements that verifies the return results. This happens more often in cases where existing code running in production does not have sufficient unit tests available. When new features are built on top of the existing code it is often difficult to write proper unit tests with good verifications and assertions.

The problem described above is also a symptom of a team’s focus on code coverage. While code coverage is a good metric to observe and use it only proves that the application code was executed. A unit test case with “given” & “when” and no “then” will also produce a good code coverage metric. This kind of unit test is not a good test because the verifications do not exist.

I recently tried out a solution to this problem with really good success. The solution was to capture the return value of the “then” piece of the unit test case and run it through the jackson object mapper. The result is a JSON representation of the actual return value of the method under test. Save this JSON in one of the files in src/test/resources folder. This makes up the “expected json” of the unit test. In the unit test, now every time the method under test is executed, take the actual return value, again convert it to json and compare it with the “expected json” that is saved in src/test/resources folder.

This approach is also described as Characterization Tests. As described on the wiki:

In computer programming, a characterization test is a means to describe (characterize) the actual behavior of an existing piece of software, and therefore protect existing behavior of legacy code against unintended changes via automated testing. This term was coined by Michael Feathers. [1]

This approach allows us to gain the critical “Assertion Coverage” from a test case. Assertion Coverage is the measure of how much of the data produced by the method under test is valid. Contrary to what it sounds like, this approach does not produce any metric like the code coverage metrics, its not something we can see in red or green colors. The benefit is clearly visible though.

Another important benefit of this approach is the “expected json” that was produced serves as a documentation of what a specific method produces. The entire object is converted to JSON and thus we can get a good visual of the data that flows through the code.

In the next post I will elaborate more on this approach with an example.

React over Angular – my take

I took some time to learn React JS in the last few months. I created my little version of todomvc like application, created the same application using React and using Angular. The code lives here:


Here is what I found. Overall I liked React much more than Angular for the following reasons:

  1. My debugging experience was much better. Angular brings JS into HTML and React brought HTML into JS. At first I cringed a little at the thought of having HTML within JS. As I kept building the application though it was much easier to debug issues. 
    1. First things first — there was only one file to look at. Nothing more. All my JS and HTML is within one single file. Unlike Angular JS where I had to look at a directive, an HTML and a controller.
    2. JSX caught a lot of errors at compile time. This gave me more confidence. With the angular app I found errors at run time AND after a few hours of that error introduced.
    3. Easier to refactor – The above reasons made it easier to refactor the code as well.
  2. Componentization came naturally. With this I mean creating web components that can be distributed and reused much more easily. Again – having a single file helped a lot. I will be writing more about componentization in later posts.
  3. React definitely had a very small learning curve, much smaller than angular. It was much easier to explain React than Angular to my friends who knew nothing about both.
  4. Aligns well to Page Object pattern that is popular in testing circles. Although this is not the best of the reasons – it is worth a mention.
  5. The idea behind React makes complete sense. The part that model is the state and HTML is the projection of state and that only part of HTML that has changed is the one that is modified.
So – would I use React on my next project? This is a difficult question to answer. I would certainly advocate for it. A lot depends on the organization / project though. If there are Angular / any other framework experts out there and things are done well – there is no need to rock the boat.

Fuzzy Avenger

My latest new project on Github is Fuzzy Avenger.

Why was this created?

This project started off as a learning exercise. This weekend I wanted to learn Akka with Java. In the process I created this github project to capture my learnings. The folders one – five in here is where that learning was captured. As I did that I realized a simple utility can be created that can be used with any traditional java code – specially unit tests or just for curious minds. This utility will process a list, apply a long running function (like making service calls) to each element in the list, capture results, aggregate them and will return the results. The results will be returned in the order – one for each element in the input list. Thus, this utility was created.

Why would I use this?

I would recommend not to use this in production code, yet.

Use this utility in your unit tests to exercise parallel processing / concurrency. For curious minds – to try out some instrumentation on your services For learning To provide me some feedback, if this is interesting, helpful and what updates can be made

Everyday Math from McGraw Hill Education

These days I am working on the version 4 of the Everyday Math program with McGraw Hill Education. The marketing team here prepared this video about the product we are building these days. The product is Everyday Math 4 that is targeted to students and teachers for grades K-6 and this will be launching in June for the 2014-15 school years.
The video features the authors of the EM, product sponsors, UX designers and academic designers from the Chicago office and showcases the product we are building.
More information on Everyday Math program: 

Technical Skills for BA’s and QA’s

What kind of technical skills do BA’s and QA’s need? Terry and I had a good discussion on this quite a few times in the last year. Her recent email to the group soliciting feedback and ideas sparked a really good email conversation. Here is my take on this topic.

I think the technical skills needed by BA’s and QA’s depend a lot on Intranet / Internet system as well. With an internet system used by users all over the country / world BA’s and QA’s would need more technical skills around what are the minimum system requirements. Do we support multiple browsers / devices, what are the compatibility criteria and options. What are the trends in browser usage? What new technologies are coming in marketplace that may need to be accounted for – example, new version of Android or ipad mini 🙂 If there is a new version of TinyMCE editor available do we upgrade? What does it buy us? etc

In an intranet system we may have a much more predictable user base. The technology standards are governed by a company wide “standards board” of some kind. This takes away the need BA’s and QA’s to know some of these technical items. In an Internet system where the user base is sampled and the technology terrain keeps changing much faster BA’s and QA’s need more technical skills.