A repository of my thoughts, a blog, a source to get insight, know-hows, my views on Software Development and everything else in between......
Monday, August 17, 2009
Difference Between Interface and Abstract Class
--contain only abstract methods
--interface can't be inherited from a class
--using interfaces we can achieve multiple inheritance
--doesn't allow accessibility modifiers (Public/Private/Internal)
--can't contain fields, constructors
--is must implementable & its scope is upto any level of its inheritence chain.
Abstract Class
--contain both abstract methods as well as concrete methods
--can extend another class and implement multiple interfaces
--we can't achieve multiple inheritance
--allows accessibility modifiers
--can contain fields, constructors
--class Abstract class is must inheritable & its scope is upto derived class
Wednesday, March 04, 2009
Interviewing a Software Engineer
Imagine the following interview with two interviewees, “Player A” and “Player B”:
Interviewer: “Okay, sir. Let’s say a ball is hit a little bit to your left. How do you field it?”
Player A: “Well, I’d take a few steps to the left and try to get my body in front of the ball. I’d use my left-hand to field the ball, switch the ball over to my right hand, and throw it to first.”
Player B: “I’d take a few steps to the left, keeping my body bent at the knees and the back so I could respond to any strange hops the ball might take. If I can get completely in front of the ball, comfortably, I will, but I might have to field it with one hand to the left of my body, if I can’t get my body in front of it. Depending on the direction I’m moving, the time it took me to get to the ball, and whether I got completely in front of it or not, I might have to throw it on the run.”
Based upon the two player’s answers to this question, Player B gets hired.
This might seem like the right call. The problem is that Player B is a recent college grad that majored in English and played intramural ball. Player A is Derek Jeter (Yankees shortstop) before he was really known as the Derek Jeter.
What if you were the interviewer and you had made this decision? You would’ve just altered the entire course of your team. There’s a good chance that from this decision forward you’d be losing a lot of games to the team that hired the person you let pass by.
The above scenario is analogous to the sad state of interviewing in the software industry. Interviewers ask inane questions that don’t have anything to do with whether the interviewee is a good software engineer. I’m not against a company asking basic questions in an attempt to weed out people that don’t have any idea at all about building software, but I am against getting through that process and then being asked similar questions in the next stage of the interview process. That’s almost always the way it goes, right?
One problem that arises when trying to solve this dilemma is that the software world is littered with posers[1] that don’t have any idea how to build software, and then these people are asked to interview people. It’s not even their fault in some cosmic sort of way: they are asked by management to interview the prospective employees. Uninformed managers asking unskillful developers to do such important activities is not a good way for an organization to operate. Since ignorance is bliss, though, these people have no idea what’s going on. Is it really their fault?
If you’re serious about hiring a good software engineer there is only one, effective way to hire serious candidates:
- Conduct a screen interview that weeds out any people that truly don’t belong. In this interview ask relatively basic questions about constructing software. By “relatively basic” I don’t mean totally simple questions; I mean questions that aren’t based on some obscure piece of information you read in the latest technology magazine you subscribe to. Ask questions such as “What is an interface?” or “What problems do you associate with using the ‘static’ keyword?” or “What can you tell me about responsibilities within a software system.” Don’t ask questions such as “How does the compiler optimize a for loop?” Such questions have no relevance toward the creation of software unless you are building software that optimizes for loops. Questions such as this are only asked when the interviewer wants to consciously or unconsciously appear “smart.”[2] There is no time for such silliness if you’re a serious person—and there is certainly no value in such questions for the organization you represent. If your company builds software there are not many more important decisions than hiring good software engineers, so get serious about it or get flattened by the competition. Someone out there is doing things right and they will annihilate you if you don’t clean up your mess.
- This is the most important step: sit down with the person you are hiring and develop something together. It doesn’t matter what it is. The goal is to get a feel for what the person is capable of when actually developing software and to see if the candidate can fit somewhere in your team. Before a sports team signs a player to a contract the team watches him play. The team doesn’t talk to the player about playing.[3] It shouldn’t be much different in the software world. Sit down and develop something together. The candidate doesn’t have to do things exactly like you or your organization. For example, if you’re a TDD shop like we are you don’t have to make sure the interviewee fully understands TDD; all you have to do is to see if writing software with her feels right. There isn’t even a perfect definition of “feels right.” It’s all up to you. In the case of TDD you’ll more than likely force the coding to follow TDD principles whether the candidate has ever done TDD or not. Going through this process will uncover a lot about the potential hire: What kinds of questions does she ask? What are her thoughts regarding TDD? Does she really seem willing and able? More answers than you have questions for will come to the forefront. Having answers surface to unasked questions is always a good thing in an interview, and the nuances of a person’s personality will flow through when you work together. You’ll be amazed at what you learn if you learn to pay attention.
If you’re not serious about hiring a good software engineer then you’re a poser. May as well make it easy and flip a coin.
Post Mortem:
In the end, it really doesn’t matter what you do. The outcome of whatever interview process you choose will be directly proportional to how much the interviewee’s abilities reflect your own. If you only ask the candidate questions, the questions you ask will be based upon your skill and experience in the software world--and the answers you seek will reflect your own answers.[4] If you’re not very good you’ll more than likely hire someone that isn’t very good, regardless of what you ask or do. If you do sit down and develop a piece of software with the candidate, you will develop it according to your ability and look for traits in the candidate that match your own traits. But, at least in the case of writing code together, you will get a much, much more accurate assessment of the interviewee than you will get by asking questions. An overriding reason for this is because coding together is a dynamic, exponentially greater reciprocal relationship than asking questions is. Asking questions generally flows in one direction—from the asker to the answerer—instead of equally in both directions.
In the case of an interview, bidirectional transport wins.
[1] A poser is a faker, but worse. A poser is a faker, only a poser doesn’t understand they are faking. Such people are incredibly annoying and boring. In this way one could say that Poser derives from Faker. I’d probably prefer to have Poser implement IFaker, but that is an argument for another day.
[2] Knowing an answer to this kind of question has nothing to do with being smart. There is a lot more to being smart than keeping extraneous information in one’s head. Intelligence has much more to do with how one associates information with other information, not how one collects it.
[3] A team may talk to a potential player about playing, to get a feel about their attitude and personality, but this is a fraction as important as how the player plays the game. Occasionally a team will let a good player pass by, but only if the player has enough personality baggage that it would get in the way of their playing upside.
[4] It is possible that you are very intelligent and very wise, but inexperienced. If so, you will ask questions and look for answers you currently believe are correct, but you might interview a candidate that is just as intelligent as you but much more experienced. In this case--if you are very wise--you would be prepared for and open to the possibility the candidate is actually better at developing software than you. You would hire him or her on the spot. Many people do not set aside their ego well enough to reach this level of maturity.
Thursday, February 26, 2009
Wednesday, December 05, 2007
ASP.NET : Interview Questions
* What is the difference between encoding and encryption? Which is easy to break?
* Can we use multiple web services from a single application?
-- Yes, you can use.
* What do we need to deploy a web service?
* What is the significance of web.config?
* Can we have multiple web.config files in a sigle web project?--- Yes but not in single folder.
• Windows authentication: - In this methodology ASP.NET web pages will use local windows users and groups to authenticate and authorize resources.
• Forms Authentication: - This is a cookie based authentication where username and password are stored on client machines as cookie files or they are sent through URL for every request. Form-based authentication presents the user with an HTML-based Web page that prompts the user for credentials.
• Passport authentication :- Passport authentication is based on the passport website provided
by the Microsoft .So when user logins with credentials it will be reached to the passport website ( i.e. hotmail,devhood,windows live etc) where authentication will happen. If Authentication is successful it will return a token to your website.
• Anonymous access: - If you do not want any kind of authentication then you will go for Anonymous access.
* What is GAC?
* What is machine.config?
* What different types of session state Management we have in asp.net?
* What are cookies?
* What is Cache?
* Is
* What is an Assembly?
* Can an assembly contain more then one class?
* What is strong name?
* What is the difference b/w client and server side?
* What is the purpose of IIS?
* Difference between http and https?
* What is purpose of aspnet_wp.exe?
* What is the purpose of Global.asax?
* What is side by side execution?
* Can we have two different versions of dot net frameworks running on the same machine?
--- Yes.
* What is CLI?
* What is CTS?
* What is .resx file meant for?
* Any idea of aspnet_regiis?
* Any idea of
* What is the difference between stroed procedure and stored function in SQL?
-- Both functions and stored procedures can be custom defined and part of any application. Functions, on the other hand, are designed to send their output to a query or T-SQL statement. For example, User Defined Functions (UDFs) can run an executable file from SQL SELECT or an action query, while Stored Procedures (SPROC) use EXECUTE or EXEC to run.
* What is connection pooling? how can we acheive that in asp.net?
-- Connection pooling behavior is controlled by the connection string parameters. The following are four parameters that control most of the connection pooling behavior:
* What is the difference between typed and untyped dataset?
* What is the difference bewteen accessing the data throgh the dataset and datareader?
-- Data Reader is forward only, read only access method and it is faster compared to dataset.
I request those who read this to send the interview questions which they feel should be included. And also request all to add good answers to the questions.