Saturday, 13 February 2016

When recruiter says "We'll get back to you" ...

I'm back in the business of job hunting, luckily this time I'm not desperate to get a job. My current job is fine. It's like an itch to see where I stand in the current market and also to see what kind of interview questions I get for my level of experience (13+ years in Java space). I polished my resume, uploaded it in couple of high ranking job portals and after a week I started getting calls from job consultancies and head hunters. The usual flow is you get a call/email on whether you're interested in a particular position, if yes you send your resume. Their client will look at it, if your profile get shortlisted then you'll be called for first round of technical interview.

Game is on .... :) I attended 2 interviews and walked out of an interview in particular without attending in which the original time slot given to me was 11:00 AM and until 2:00 PM (for three hours) I ended up waiting in a room. I can't take more than that and walked out. But that's just one. Another one got indefinitely postponed etc. Out of 2 interviews I took I got programming questions (write a program to do something with some twist) and some logical questions related to some rooms, bulbs and switches etc. I felt I pretty much done well in the first round and thought I will take second round to give best shot. However, the HR gave the golden words "We will get back to you".

I still remember in my earlier career days, I really used to wait for them to get back to me. But now I know what :) this means. I got rejected in both interviews. That's fine, but my point is, why don't they just say "Sorry, you are rejected". I'm sure they have their own reasons like putting few profiles in buffer just in case blah blah. But giving solid answer is always better I feel, instead of making innocent and desperate needy candidates wait forever hoping that one day they'll get that golden offer. Now, if I get an offer I do not like, I'll not say "I don't want this offer". I rather say "Dear HR, I'll get back to you"  :)

Saturday, 1 August 2015

The side effects of working in maintenance project

I have been doing software maintenance for some time, majority of my work experience is maintenance. As we already knew, no one really prefers to work in maintenance :) Recently, I went through an interview process and the kind of questions I got made me think and look back. Ideally there are two types of interviewers, who mainly focus on technology (like Java, SQL etc) and other category who focus on programming skill (the ability to code). This interviewer I faced is of second type. The questions were based on array manipulations and algorithms. Unfortunately, I couldn't clear the interview as my programming skill was not at peak :) Moreover, I don't remember algorithms like sorting, searching etc. This contributed to my failure

After that failure, I was thinking for almost two months to really understand what went wrong. After much introspection I realized that my programming was bad and I was unable to come up to convincing solution on paper. The reason is simple, I have not done real programming for quite some time. All I'm doing from the past 5 years is analyzing the code and fixing the bugs. Even in my current job, I'm spending my 90% of the time in understanding large code base, identifying where to apply fix and applying fix (this is as simple as adding one line of code, or changing property etc.)

Alright, these are side effects of maintenance programming. Typically, you'll be good at analyzing the code and fixing the bug, but not designing a system and coding from scratch. Perhaps this is the reason, I think many of us will not consider maintenance. Unfortunately, we do not get to choose our projects, even after programming interview there is no guarantee that we'll be assigned in greenfield development.

So how can we keep our sanity of programming? People suggest to become obsessive with programming and do coding all the time! This is not easy thing to do, especially after fracturing brain while bug hunt and fix. However, this is the whole point, so focusing on either consistently improving skill is important!

Thursday, 28 March 2013

What happend to Struts?

I still remember my good old days I learned Struts framework and did my first web application using it. I don't know when people started screaming about it and Spring framework came into market. Initially I always used to ask myself, why Spring and why not Struts? Because I haven't even fully explored Struts and Spring came and I need to learn whole lot confusing concepts. Anyways, I happend to learn it over a period of time and did some project on it. The point is frameworks come and go. Things are too fast now a days.

Sunday, 17 March 2013

Goodbye, Java!

The company I work for, gave up on Java (due to bad vendor implementation, licence cost, AppServer cost, DB cost) and going for Drupal powered by LAMP arena. We're all Java people forced to downgrade (or upgrade I don't know) to Drupal and PHP stuff. I'm bidding farewell to Java because the job market here is too bad for Java and I don't get any other Java job. So instead of freaking out, I want to stay cool and make a smooth transition to Drupal & PHP stuff. Also, I feel there is simply too much to learn in Java, there is no end for this coding madness. Every interview in Java is a battle for me, because each and everyone have their opinions on what is an Interface and Abstract class etc etc in Java. If I tell my own opinion I will be rejected. Tired and Bored.

Goodbye to Java ocean.

Tuesday, 19 February 2013

Successfully 'failed' in 3rd banking job interview

I screwed one more time. I am trying to get into banking job (as a Java Developer) since 5 years in Singapore. Every time something goes wrong. This time I screwed up in core Java and database. I've been thinking and introspecting on why this is happening. What's so great about banking job? Looks like banks only recruit people from banks. One must have banking experience to get into banks. What is banking experience? Banking experience is working in the banks. That means, working in nerve breaking pressure, working 20 hrs a day. Fracturing brain by thinking on how to solve production system because people out there cannot transfer money or get money. To handle this kind of work any developer need to be rock solid in core Java and database concepts.

Ok here is my problem. I am working in Vignette CMS side, not really done any super coding or super database stuff. Since I'm working in a product, the product takes care most of the things. I only write extensions with little Java and basic JDBC stuff. Whenever the interviewer asks banking related tricky question (Indian interviewers ask tricky questions always and also they expect the answer from the book they read), I either don't know the answer or I give wrong answer. Here is an example.

Q. What is the datatype to represent currency?
A.  I answered double datatype in Java. It's WRONG! Why? After walking out of interview room with failed result, I googled and found that, correct answer is BigDecimal. Because using BigDecimal gives more control over rounding behavior. So unless I work in banking environment how the heck I know that!!

Another one ...

Q. I have a database table with three columns with a composite index of three columns. Now, I will execute a SELECT statement with only two columns. Does the index is useful in this case?
A. I answered no. The correct answer is YES.

In many cases, my resume won't even get shortlisted. Because I've never worked in MQ, Kerberos, Multithreading, Locking. I've never know what is risk management. I screw those one or two lucky interviews I attend from banks.

Today is the day, I gave up to banking job preparation. I'm tired of reading, studying and failing. I want to focus on my field Web Content Management. Good bye banking job. I don't care for you anymore!!

Wednesday, 14 November 2012

Faster, Better, Cheaper

Software Architecture or Project Management or anything in general in life is all about making trade-offs. We always need to choose from the available options. We have to compromise on something to gain on other things. Which one to loose and which to gain is the process of making trade-offs.

In the software development out of the three options faster-better-cheaper we can only choose any two. If we want our product to be ready immediately with better quality less bugs we need to spend more money on it. In this case we gained speed and quality, however we loose on price. At the same time, if we do not have much budget we needed to settle for either slow development time or on quality.

In the architecture, if my software wants to serve with fast response I need to scale the system. I can scale either horizentally or vertically. This involves cost. Ofcourse, code refactoring or tuning can improve the system's performance upto some extent but to really improve performance the system has to be architected with load balancing or caching mechanisms. In order to provide quality of service (QoS) like 24x7 availability, we need to plan for failover strategy. There are various options to choose (active/passive, load balancing, caching etc) depends on budget.

At one point we cannot get all of three choices. Correct balance is important when making trade offs. The most important thing is to involve stakeholders of the project during deciding the trade offs. Their involment is critical because they are the people who actually use the system in future.

For example, if we are dealing with marketing department, they needed the software faster in order to go to market asap. For them it is time to market scenario. If they have budget, more people can be involved in the project and can be completed faster with better quality. If the project is internal for few staff, company may not provide super budget, in this scenario we can compromise on speed. We can deliver software in reasonable timeframe with limited resources.

In the architecture or project artifacts, either architect or project manager should document the gains and trade offs he/she considered and the reasons behind these decisions. The architect or PM should also take stakeholders approval of these artifacts. Anything in document can save us later point of time in projects when something happens to the project in chaos. Documenting decisions is always a good practise rather than verbal communications.

Tuesday, 25 September 2012

Project Manager, Business Users - Technology

How much technology a project manager should know? Is it just enough to know what's happenning in the team? Or more in the level of Solution Architet? Again there are different perspectives and variations. Let's consider a practical scenario and we'll see how each person in different roles act.

Let's say there happend to be a production problem in the middle of the night (if you are in the pub drinking during that time, don't take the call :) ) (say around 2 am, I like this time because this is the time I get calls) and it is serious issue and needs immediate attention. The below are the possible things each role can do if they get a call.

Q. What a developer can do?
A. A developer can login to the server, check logs and spends time understading what could have happend. Once problem is understood, he/she can see if this problem can be fixed remotely (assuming at 2 am you're at home doing remote login). If problem cannot be fixed from home or brain not responding, he/she convinces user who called by telling them that they can only fix at office hours.  

Q. What a senior developer can do?
A. Whatever a developer will do + he/she will think what could've caused the problem and how to fix it in terms of design. Also how to permanently eliminate this error in near future.

Q. What a solution architect can do?
A. Whatever a senior developer can do + he/she thinks of a mitigation strategy to eliminate this kind of errors in the midnight, and thinks about a plan and process on how to provide permanent solution to avoid this error and many other errors relavant to this error in terms of architecture etc.

Q. What a project manager can do?
A. He/She immediately calls any one from above 3.

This is what happens in most of the companies I've worked. A project manager's duty is go look after project in terms of cost, estimations (team lead help needed in this area), task allocation. And each person in team answerable to project manager.

I know a manager many years back. In order to explain problem and solution we applied to the problem, we needed to teach her programming language we used. For example, if there was a problem, say a NullPointerException, we added null check to fix it, if we say there was an exception and we added condition to avoid it, she used to ask us, what is exception? what is null? etc questions. Quite irritating, but she is a manager. So we gave her a Java crash course in 5 minutes to her and explained the issue in detail. Man, she learned so much technology in crash courses almost became solution architect theoritically.

Putting bias aside, a project manager should have 70% management skill and 30% technology skill. That's why I always like to work under Solution Architect's supervision rather than pure management type people.

I also don't like to interact with business users, the moment we try to explain why certain things cannot be done with certain technologies (like controlling their browser settings from our servers, weird!!) they stop the discussion complaining 'its too technical'.

Because of all these experiences, I decided to stick to technical career path eventhough I am getting PMP training offers at good discounted price. I prefer to manager servers rather than managing people. At least, servers will follow your orders!!

Finally, a joke I remember about managers. Here it is:

A man goes into a pet shop to buy a parrot. The shop owner points to three identical looking parrots on a perch and says, "the parrot on the left costs 500 dollars".

 "Why does the parrot cost so much," asks the man.

 The shop owner says, "well, the parrot knows how to use a computer".

 The man then asks about the next parrot to be told that this one costs 1,000 dollars because it can do everything the other parrot can do plus it knows how to use the UNIX operating system.

 Naturally, the increasingly startled man asks about the third parrot to be told that it costs 2,000 dollars.

Needless to say this begs the question, "What can it do?"

 To which the shop owner replies, "to be honest I have never seen it do a thing, but the other two call him boss!"

(copied from