Wednesday, February 3, 2010

Idea of a litmus test for the company that hires you

I suspect this might be a good question to raise on an interview with any potential employer in software engineering industry: "With regard to the engineering you do when creating your product(s), if you were a car manufacturer what kind of car make would you match your whole production line with - AvtoVAZ, Toyota, Ferrari?". The list, of course, can vary to contain names known to the other party but the idea would still be the same.

I see no other way to quickly reveal how significant and relevant the tools and technologies employed by the company are. Sometimes they might tell you they use Perforce but then it appears they don't use branches and store compiled binaries in it for some wierd reason. Sometimes they claim to use Continuous Integration system but then you find out they don't write unit-tests so it makes using of CI close to sheer nonsense. Or, even worse, they do write unit-tests but without assertions. Some mention they are Agile but meaning by that things are in total mess and uncontrolled. Think for some time and I bet you will be able to find your own examples of such lies.

It is just a rough guess, yet I hope it is on the right track.

2 comments:

  1. Totally agree with the second paragraph. For example some time ago I worked for one USA company. PM said during the interview that they do use Scrum, write unit-tests, conduct design meetings.

    In fact they violated the one of basic Scrum ideas - team size. Scrum states 10 man is a quantity of team members while our team was about 16 man.

    Agile methodology in fact did mask absence of overall plan of the product development. When a sales guy meet a new potential customer which was interested in a new feature he called to our PM and told him some very raw ideas about that feature. PM orders to half of developers to fold their current tasks and start implementing the new feature. Of course there were no requirements and specs. So sometimes it ended in tester and developer (after development and testing already finished!) sit together and call to sales guy trying to make him to explain how exactly the new feature should look like.

    Unit-tests - they really tried to write them, and they had CI server. The problem was in awful architecture and code quality. So most unit-tests required specially populated DB, test not a single class but the whole bunch of stuff from UI till executing SqlDbCommands, run very slowly (DB recreated about 7 times during one run of all unit-tests), had very limited code coverage and checks mostly positive test scenarios. Tests were very large, ugly and required very much time to write and maintain them.

    Unfortunately all these things I understood only after I had started working in that company.

    Regarding the question you propose to ask - imho it doesn't reveal something really valuable. The most possible option is that a person being asked the question just incorrectly answers it. Either because he is lying or really believe in his wrong answer.

    ReplyDelete
  2. To Konservator: Let me beg your excuse for not noticing your comment earlier - there was something wrong with notification settings for the blog.

    I think nowadays most of the time you can hear word "agile" being applied to how the project is managed rather than to the development technology if any is present. Using a popular word is just a convenient way to hide the fact that the project actually lacks efficient management. As a consequence the development technology suffers from multiple problems like it was in your case where the project ended up with lots of unplanned activities. I'd say "agile"-ity of too many projects these days is just another manifestation of false advertising where by using misleading statements a potential hire is being persuaded to agree with non-satisfactory conditions.
    Can we do anything about it? What if the proposed question would be asked to different project representatives? Imagine I first ask that question to PM and he proudly responds - "yeah, we're assembling Ferrari cars here!". However, during another interview the development lead tells you something like - "I'd say we are building cheap Toyota cars". This discrepancy would make me wary about how much trust I can put into all their statements and probably insist on more details being revealed. Maybe a small thing but still of some value.

    Using an abstract question (still from engineering area) is supposed to shorten the conversation. Otherwise this might become really boring if while trying to build a good picture of the project you start asking how they carry out each and every development activity.

    ReplyDelete