The ridiculous interview experience

I have encountered a few interview questions which I feel strongly enough to talk about....

1) List all the scenarios where a stack overflow exception can occur.
2) Difference between mutex and lock?

These two questions seemingly different are in the same category - I work on shitty code either I wrote or I inherited from someone else - tell me whether you know about what happens in shitty code. The problem is that if you are a great programmer and you write great code, you may have never have encountered such scenarios before - your knowing or not knowing about this in no way indicates how good you are. I joined the job where they asked the mutex question and rewrote the entire code - their implementation was totally wrong and how they were trying to solve the problem was also totally wrong. Mutex was not the way to go.

You are not a less capable resource because your code and design is so good that they did not have the flaws which you needed to know about to succeed in this interview.

3) What do you do when you need to make a WCF call which may lay as long as 48 hours and WCF gives up?

You can't just write any code you want and blame MS when it does not work. Simple example -do not make a synchronous call where the client is waiting for the server to respond for 10 hours and complain. The better solution maybe to make a one way call to do the long running operation and periodically check for the status of the job.

Similarly the better way to write multi-threaded code is not to create a situation where you need to share anything between threads - much less a file which two different processes try to access at the same time and which needs mutex. Mutex is also an example of an API - knowing about it or having no knowledge about it, does not mean anything more than the fact that you have not used the API before.

4) Arcane questions on linked lists and data structures

A programming language/ computer science has many, many features. Often some of the arcane ones get used not because they are necessary but because of bad design. Knowledge of these arcane concepts are really not of use 99% of the time - and their usage is a red flag. Sometimes, people deliberately introduce such stuff not because of anything else, but just to show off - that is ok, but problems get created because they do not understand it fully and such usage causes problems later.

A point to note here is that I am not talking about some of the data structures which are actually used by developers all the time like lists, generic lists, dictionaries, hash tables, queues, etc. These and their brethen are useful all the time. I am specifically talking about stuff which people learn in college which are not used in day to day work.

It is better not to use such stuff and make the code brittle in the first place. A good thumb of the rule is that if 60% of them team may not be able to understand and use it, then do not use it to begin with.

I have been in a scenario before where they asked me questions on data structures and rejected me because I did not know it. However, the manager in that company had also talked to me and decided to hire me. I did the best work of all the people they had ever seen. It took sometime for the manager to realize that someone who had no idea about data structures could not only do the job, but could excel in it!. This is the ridiculous situation we have today where interviewers ask questions which are totally unrelated to success in a software job, reject the right people, hire the wrong people and even those guys cannot do the job well.

Often these are the very people complaining about the lack of qualified people in the market.

5) Explain MVVM

MVC and MVVM has cropped up in the recent times as something else which people ask for. Firstly, let me clarify that I have yet to see a large successful project anywhere in the world where people have used or created MVC and then used it in a large team - this includes the MVC implementation by MS in Asp.net which was eventually open sourced. Truth be told, even when this is used, 1% of the team does it, and those who do, do not use it in the way it is supposed to be used.

I would like to point out that indeed iOS and other frameworks do use MVC and they are useable. I am talking about half baked, unfinished frameworks released before they are ready and everyone jumping on them and trying to use them immediately. I have used MVC in the right way in projects. However, mostly, in Win Forms and ASP.NET, people tend to use it just for the sake of using it, without understanding how it works and creating really messy code. The latest version of MVC for ASP.NET is slightly better than the older versions where it is convoluted and a mess to work with. Theoretically, these are all great ideas, however before implementation in a real project, they need to be massaged into a useable state. Otherwise, you end up wondering what you did wrong when you simply copy paste implementation from some book written by someone.

People have forgotten that software was made by people for people. These days it seems that we think software is more intelligent that a person and people should struggle to understand and use a framework. No matter how many fools think this is true, the total and abysmal failure of such projects in terms of the struggle to complete such projects within timelines and resolve business needs prove my point.

In a world where Microsoft certified architects struggle to understand when to use interfaces and how to use it, MVC or MVVM is a long way off.

These types of questions are a red flag. When you add to the fact that they use WPF as well, you know you are dealing with a failed software division who use technologies without proper study and are late in timelines and struggle perpetually to understand what they are doing wrong and why everything is difficult.

You are a great architect and you can evaluate technologies well and ensure your company does not use some bad third party tool which creates problems down the road. The fact that you do not know how the bad third party tool works is not a negative mark.

6) Explain to me everything about the internals of the .NET framework all the way from stack, heap, app domain, process, etc.

This kind of question comes up from the very foolish assumption that if you know microscopic details on how a system works, somehow you are very successful in the macroscopic level. You can understand and explain every weird bug which comes your way because "you know everything under the hood". Nothing can be further from the truth. Usually such people end up totally confused because things don't work they way they think it does - because usually documentation is behind releases, versions have been modified and the books from where they got this information is outdated. Everything has changed, because MS fixed issues, bugs, made the code more performant, and their assumptions except for the very basic ones (which everyone knows) have changed.

In many cases, these are the guys who say MS is the cause of every bug when in fact it is their limited knowledge and work experience. In 99 cases out of 100, an experienced on hands programmer is correct in their assumptions and theories compared to such people. If they got so much time on their hands to read all that material instead of coding in real projects, I think that may explain this.

I have written an entire blog post on this:

http://deepinsightsdotnet.blogspot.in/2012/11/just-because-you-know-physics-does-not.html 

7) Explain SQL Joins

If you are a web/ component developer and they expect you to have in-depth SQL knowledge they are the fools. If you are a very good C# programmer, chances are your SQL skills are not much. Some companies make the mistake of only hiring such people and make them do both C# and SQL. The results are usually very disastrous for the C# portion of the code. And usually these bad parts are as difficult to maintain and fix as the most complex SQL.

8) Give me the best solution you can design for problem X (but I just want to hear my current design is the best)

One of my interviewing companies worked for some military projects. When they asked me to give the best solution and come back the next time, I researched and found out the best solution for the problem (done by Israel btb). They did not like it, because it showed how flawed their design was. For some reason, I was supposed to think and tell them their solution was the best even though it was not.

Give me a break!

The software division was created to solve business requirements not as a test bed for some developer to learn the latest technologies or new APIs. Any technology first needs to be tried out so that you can understand when and how to use it effectively - considering its strengths and its weaknesses. Sometimes, in paper it is great, but in reality it is totally unusable in a real project like LINQ to SQL or the entity framework.

The best projects and the most successful ones I have been on we're the ones where we considered these truths and used technology so we worked less and produced more. We produced more value for the business without spending late nights wrestling with some new technology.

We wrote code, produced frameworks but we understood them well and others were able to use it because it was easy enough to understand. When you cannot scale the implementation of a software by adding more team members who can understand and write the code - that is the biggest drag in the project.

I read somewhere that Mark Zuckerberg is unable to write any code without mistakes in Facebook today. They probably think he is wrong - but I feel the system which does not allow the most talented developer in the world who wrote the most scalable, performant site in the world is the one in the wrong.

Research and academics is good where they are, but they may need more iterations to convert good ideas into useable ones. Until people understand this, very large software projects will continue to fail - like iCloud, Windows, etc. You should not have to have a masters in computer science to write scalable performant code. The systems should mature so that anyone can write such code. Because as LINQ to objects has shown - nobody cares about linked lists or sorting algorithms - they just want to solve the business need, without having to worry about the CPU stacks or registers.

We have over compensated in one direction, it is time to realise that people created these systems. People need to be able to use and understand and implement them. The failure of a person to understand a system is not her or his failure - it is the systems failure - because people still can do things which computers cannot, and probably never will.

If we are to move to a more mature software system, then we will need to progress in this direction. Talent can be in different places - you could be a greatly talented developer - and still have no idea about all the data structures or sorting algorithms in computer science books you have never read before because they never came up in your work experience. In the real world, I have seen repeatedly that people who know all these arcane details struggle to design and implemented solutions to real problems. Their opinions are usually copy pasted from some book, they cannot defend their designs beyond saying that they read it in so and so book. When shown a totally new idea, they just blank off because they are not used to seeing anything which they have not read somewhere before.Truth is their brain is filled with a vast pool of knowledge with no understanding of how and when to use it because they got it for free from some textbook.

Is the person with the larger database in his head, more intelligent? - if intelligence is mere data, we would have an intelligent computer system somewhere - I don't see any such thing anywhere in the horizon.

We have to search within ourselves to find the solutions because we are the walking, talking, proof of concept of such an intelligent being.

And yet! Here we are thinking that because we can't answer some silly detail in some computer science book that somehow shows the lack of our knowledge.

Never feel bad rejected by such morons of companies. It is their loss they do not get you as their employee. It is always a two way street. Usually a good programmer or architect is of more value to be company than the company is to them.

Comments

  1. Vijay, most of the Mobile development (which surpass all other) is now in MVC. Both Android Java and Objective-C are more mature then C# and yet more difficult to work with then C#. APS.NET is a mess, you know how much I hate it. complex-SQL is of no use for programmer, will actually make the project suffer and code performance goes to drains. Same for exotic concepts (MSMQ, LINQ comes to mind). But from other hand Ajax and JQuery are great.
    Data Structures (some) and for mobile development threading is must. To implement a fast data access, you must not and should not rally on DB like code, although nova days I simply assume 4 Core CPU and move alone.

    ReplyDelete

Post a Comment

Popular posts from this blog

Tutorial: Using Google Cloud Storage from C# and .NET

Late 2008 Macbook only giving 1.5 gb/s speed with 6 gb/s Intel SSD?

Enable Visual Studio to use more than 2GB of memory