Interview Preparation Links

I have compiled a list of interview books to read for preparing for software engineering interviews. This is mostly a list for someone who is interested in learning or revisiting concepts in algorithms and data structure. A few links deal with design the others are just helpful for preliminary phone interviews:

1. http://www.topcoder.com/tc?module=Static&d1=tutorials&d2=alg_index Topcoder Tutorials on Algorithms - Some algos are really tough in this list, but this is still a fun list to read and practice a few questions. You can always create a tc account and do some of the questions in competitions.
2. http://www.parashift.com/c++-faq-lite/index.html C++ FAQ - A must read and follow guide for C++ interviews, I suggest to read this and understand why such design practices are followed.
3. http://sites.google.com/site/steveyegge2/five-essential-phone-screen-questions - Must read guide to clear phone screens
4. Programming Interviews Exposed - Read to get a decent idea of general thinking pattern required in an interview.
5. Professional C++ or C++ How to Program (Dietel and Dietel)- or any other C++ book to help clarify some basic concepts in C++.
6. http://people.csail.mit.edu/bdean/6.046/dp/ Dynamic Programming tutorials. DP is a must have for programming interviews. This link only works in firefox.
7. Effective Java - Essentially a Java book but most of this stuff is also applicable for C++.
8. If giving interviews for google, amazon or MS - Bing or another company which works on cloud ccomputing, make sure you read the papers that they have published on cloud computin.
9. How would you move mount Fuji - Not sure how useful is this book is nowadays, was useful for MS SDET interviews sometime back :) . It also has some nice puzzles.
10. Heard on the Street: Quantitative Questions from Wall Street Job Interviews - This book also has a bunch of good puzzles if at all you are interested in.

In the end writing a lot of code and following good design practices helps.

Startup Fever: Which language ?

I have never had my startup ... not at 22 , not many people except a few of my batch mates, have a startup at this age. Kudos to them and many more like them who do not want to be a peg in the corporate machinery but rather wont be different in their own way.

But some experience come in me in the form if co-ordinating for IMG in my college days. As a brief introduction IMG is Information Management Group which is responsible for management of a significant portion of IT resources of the institute. IMG is a student body , consisting roughly of around 40 students mostly taken through an elaborate process of interviews and tests and some others handpicked by giving them small intern projects.

There is in all a lot to reflect from the experiences of managing in a 40 member technical team, most of which can be (i guess) directly applied towards making a startup. I always wanted to cover this stuff here but due to a complete lack of blogging impulses it has always remained in me for almost more than an year now.

Lets not digress further and reach to the point straight away. To any new person starting to write a few bits of code (for oneself) the first question that comes is what language to write. Whenever I write code or asked people to write code for a project. I ask a few questions

Which language am I comfortable with ? Which language is the team comfortable with ? What is the size of code you want to write ? For how many users you want to write it ? What are your coding skills ? (More important) In what language you are most comfortable with debugging ? Most people are not very good code writers, but they need to know debugging pretty well, if you cant debug very well, you are bound to exceed time lines and screw up on big projects.

A good decision is always a mix of gut feeling, logic and a penchant for doing new stuff. If your gut says Java is good, a general survey tells you that people love it and you have a thing for trying out the "new framework" out there.

The problem: "Every language on this goddamn earth sucks to the core if you dont know how to ''exploit it''. " Let us say Java, I coded in java extensively, if you dont know wtf you want to do with it, the thousand s of techniques out there are sure to drive you crazy.

Here is how I decided what to do for a major project. I "knew" java sucks if u cant use it properly, key ?? the key is to understand the problem at hand and come with a design first. My problem had key features:
1. Scalability, the app was to be used by 1000s of users.
2. Familiarity for my team, everyone knew java well.
3. Maintainability for the group, can t use ASP .NET coz nobody is really interested in learning that. Everyone loves java for some strange unknown reason.
4. My penchant for the newly learned Java EE 5 and JDK 5 features !!! My personal choice goverened a few things incidently ;).
5. An elaborate mix of potentially screwing problems that a framework will take loads of code to write and a bad experience with existing frameworks.


Never write code first and than design later !!! unless you want to throw that code write out of the window or are cool with being bankrupt.

We decided to do a high level prototype of all the challenges that we could have faced and than scrapped all that code , just took a month of our time. Than redesigned the application from scratch, included all the features we wanted to and wrote all the code from scratch (no framework BS) and ran it, believe me it rocks !!

Due to our apparent lack of experience we screwed a bit at some places, but hey as far as it runs, it runs fast, is secure and damn easy to maintain ... it suffices all the requirements of a good s/w project ?? (yes it is scalable across layers and compatible across platforms, is standard compliant, has visible design patterns and blah blah blah ).

In conclusion ... the above fundas worked for me, hope they work for you :)

The "No Faith" approach to security

I dont know whether this is a known method or not but I found this approach quite good enough especially for a person like me who has no way to know everything that goes in and out of an (or any) application. The "No Faith" approach assumes that whatever class you are coding will have some malicious code executing it. You can say that you need to check everytime whether the parameters passed to you and the methods called are called by say the correct users, with the correct privileges and they have passed the correct parameters. It is also important to see, if at all you are using an API or your own code, what are the assumptions that are made in the class that you are calling. Sometimes say when you are writing C code the class may be expecting a character array of a particular length and you may be supplying a longer array or it is not null terminated. Or when you write Java (EE app) than you are not explicitly checking whther the user calling the function has the correct rights or not. Or say you are allocating a resource or using a name which already is used by somebody else or is prone to use by any other program.

So the best idea is to not have any assumptions on how things might work. A good example that came to us when coding alumni. There we check for user privileges when someone delets his own message. First it is checked on the page itself so you dont have an option. If you can somehow access that page (God knows how you can do that !!) and again you somewhow execute that call on the JSP (again I wonder how). There will be another check from the session itself that is difficult to surpass (I cant think of any way that anybody can).

The basic idea is dont trust the layers above you, they may have gotten dirty themselves, just keep a check.

I call it "No Faith" approach to security , you may call it whatever you like.

Team Design

The other day I was wondering what are the flavours that are necessary for a good team to function. Let us say I want to start a company and want to choose some colleagues ... people of the same age as myself what will I be looking for in them, or even for a company project. What are the essential qualities that should be present in a team ?

Now one can go at lengths to explain how to pick up the right team and what kind of qualities should one have ... let us keep it for some later time. Let us say that there can be three primary drivers for any project. The drivers come from the problems that a team faces in implementing anything. Let us consider a generic engineering problem and expand it on a managemnt perspective.

To start on any problem one needs good technical skills. So you always need a few guys or at least one person who has good technical skill. The skill-set may not be so important but the ability to evolve and to learn new stuff fast is really important.

Now typically any implementation is faced with hurdles apart from technical. These can be tedious political processes, long corporate cycles or hostile market dynamics. Situations where a person's skills at dealing with people with the right attitude is required. People with attitude are very important to a team which has to do a lot of public dealing. You need to know when to show the right emotion to the right guy.

The last key point is to have feelings about the work you are doing. If people do not feel for their work they can never perform in it no matter how much brain or attitude they carry. One always need to have someone who believes that they have a great idea or someone who believes they are going on the right path. Somebody to move the flagged souls of their peers.

To sum up the three things that make a good team body are brain, attitude and heart. Whaddyasay ?

System Designs and Hacker's Perspective

Back in Roorkee I was occasionaly asked this question: How to be a hacker ? Not that I am a hacker myself... neither I ever claim to be one. To be frank according to the widely popular definition of hacker, I am most certainly not one. Not to digress further, I encountered a howto once on becoming a hacker.

In my very own definition a hacker is a person who has got a really good knowledge of a certain or a class of systems. A hacker can hack a radio, a spectrum , a software or even a car engine. More importantly he cannot be the one who designed the system but has a keen interest in it. To hack is to exploit the system to make it do what you want it to do but was possibly not an intended application. Like you can hack a PSP to play it like drums (somebody has actually done it!!).

So how is system design and a hacker's perspective related ? There can be at least two types of system designs in relation to a hacker's perspective. One that keeps into mind that there will be people who will try to tinker with the original system and try to expand it. The other types of systems are those which are strict about their rules and will not allow anyone to exploit them for any other use.

Let us consider the latter case of the two and divide a hacking problem in two parts. One the component to be hacked and other the platform on which it needs to be hacked. A hacker keenly studies the design of both the systems, typically a top layer and a bottom layer, the top is where the hack needs to be performed and the bottom layer is on which the hack will be done. An analysis of behaviour of both these systems is required. One needs to know both the strong and weak points of these layers and needs to put them together and tweak wherever possible to get the desired output.

Therefore from the hacker's perspective a system can be manipulated if it is layered and each layer there is a possibility to do some sort of analysis and somehow effect the behaviour of system at that layer.