Ready For Interviews (Summary)

After spending couple hours of time i came up with summary of the Software interview question .I hope it will help full to you.

Tell me about yourself.

A good answer to this question is about two minutes long and focuses on work-related skill s and Accomplishments. Tell the interviewer why you think your work-related skills and Accomplishments would be an asset to the comp any. Do not describe yourself with tired old cliché s such as "I am a team player," "I have excellent communication skill s," unless you u can prove it

Why should we hire you?   

Take several minutes to answer this question, incorporating your personality traits, strengths, and experience in to the job you're applying for. A good answer is to focus on how you can benefit the company. 

As I understand your needs, you are first and foremost looking for someone who can manage the sales and marketing of your book publishing division. As you’ve said you need someone with a strong background in trade book sales. This is where I’ve spent almost my entire career, so I’ve chalked up 18 years of experience exactly in this area. I believe that I know the right contacts, methods, principles, and successful management techniques as well as any Person can in our industry.

What do you worry about?

Redefine the word ‘worry’ so that it does not reflect negatively on you. 

Example: “I wouldn’t call it worry, but I am a strongly goal-oriented person. So I keep turning over in my mind anything that seems to be keeping me from achieving those goals, until I find a solution. That’s part of my tenacity, I suppose.”

What is your greatest strength (or strengths)?

I have the ability to train and motivate people. At Acme Co., employee turnover was very high. Intelligence...management "savvy". 

Honesty...integrity...a decent human being. 

Good fit with corporate culture...someone to feel comfortable with...a team player who meshes 

well with interviewer's team. 

Likeability...positive attitude...sense of humor. 

Good communication skills. 

Dedication...willingness to walk the extra mile to achieve excellence. 

Definiteness of purpose...clear goals. 

Enthusiasm...high level of motivation. 

Confident...healthy...a leader.

What is your greatest weakness s (or weaknesses)? 

Don't answer by claiming that you have no weaknesses. Confess a real weakness that you have, but choose one that isn't particularly relevant to the job you're seeking. Does n o t answer with phony weaknesses such as "I'm a slave to my job" or "I'm a workaholic?" Just state the weakness, tell the interview how it has harmed you in your work life, and what steps you have taken to improve it. A good step one can take to improve a weakness is to read self-help books on the subject. 

“Nobody's perfect, but based on what you've told me about this position, I believe I' d make an outstanding match. I know that when I hire people, I look for two things most of all. Do they have the qualifications to do the job well, and the motivation to do it well? Everything in my background shows I have both the qualifications and a strong desire to achieve excellence in whatever I take on. So I can say in all honesty that I see nothing that would cause you even a small concern about my ability or my strong desire to perform this job with excellence.” 

Instead of confessing a weakness, describe what you like most and like least, making sure that what you like most matches up with the most important qualification for success in the position, and what you like least is not essential.

Do you work better alone or as part o f a team?

If the position you're applying for require s you to spend lots of time alone, then of course, you should state that you like to work alone and vice versa.

Do you consider yourself to be a risk -taker? 

How you answer this question depends on the type of company it is. If it is a start-up company or within a highly-competitive industry, then they are probably looking for those more willing to take risks. If you believe the company is this type, then offer an example of a risk you've taken in business. If the company is a well-established industry leader, risk takers are not as highly valued. Of course, no comp any is looking for employee s who are foolish in their risk-taking behavior r, so a good rule of thumb is to place yourself f somewhere in the middle -- you are neither too foolish nor overly cautious . 

What salary are you expecting?  

You should do some research before the job interview so that you don't ask for too much o r too little. You might be asked to justify why you are worth the salary you are asking, so be prepared with an answer (i.e., tell them how your skills and experience will benefit the company so much that your salary will be a bargain for them.)

Who is your favorite boss?

These are two of the most difficult interview questions to answer unless you understand what the interviewer wants to hear, and if you realizes at you can answer both questions with basically the same answer. Employers are looking for employees who are interested in contributing to the comp any, improving their job skill and making a contribution. So, instead of insulting o r d e meaning your past bosses by telling the interviewer that he was always "hogging all the crew d it" or was "totally in competent",

When can you start?

It is customary for most employees to give at least two weeks’ notice to their current employer. Those in management positions are expected to give long r notice. You will not earn points if you express disrespect toward your current employer by telling the interviewer that you plan to q u it your present job without giving sufficient notice. He will assume you will show his company the same amount of disrespect . It is also a good idea to tell the interviewer you plan to start learning about your n e w position / employ r on your off-hours (i.e., reading employee training manuals, etc.) Telling the interviewer you can't begin work for a few month s b e cause you want to take some time-off is not a good idea

How long can you commit to work with us?

I like new challenges and a chance to grow. As long I keeping getting these, I don’t think I’ll need to switch over. I’d like to believe that this Relationship lasts for many years. However, I haven’t set a time limit as such.

You seem to be drawing a good salary. Will you be OK in taking a salary cut?

I believe that at one point of time in career salary becomes secondary and self-actualization become more important. While taking up any new job, it will be my priority to ensure that the work culture, chances to contribute and grow are sufficient along with the money I am paid. I also believe that any good company who cares about its employees ensures that they are paid well

What do you do to improve your knowledge?

The field of IT is very revolutionary. It is extremely important to keep yourself abreast with the new technological developments and this needs you to take some time out of your work schedule so that you can keep sharpening your saw. To answer this question, you can tell the recruiter about the forums which you keep visiting, blogs which you keep reading. It will be an advantage if you are a member of some local user group

What is more important to you: the money or the work?

Money is always important, but the work is the most important. There is no better answer.

What qualities do you look for in a boss?

Be generic and positive. Safe qualities are knowledgeable, a sense of humor, fair, loyal to subordinates and holder of high standards. All bosses think they have these traits. 

Do you have any blind spots?

Trick question. If you know about blind spots, they are no longer blind spots. Do not reveal any personal areas of concern here. Let them do their own discovery on your bad points. Do not hand it to them.

Can you perform under pressure?

Most of the times, the job of software development is that of working under pressure. Sometimes, it will be the pressure of delivering on time while it can be that of a bug that has sprung all of a sudden in your code. So, expect pressure in everything you do. It is important to maintain your performance and develop strategies to deliver under pressure. You can then go ahead and talk about your way of dealing with pressure and performing under it\

Tell us some of your weaknesses?

The best way to answer this question will be to turn one of your strengths as a weakness and say that others accuse you of having this weakness but you think it is important to work in this manner. For e.g.: “My colleagues accuse me of paying too much attention to syntaxes but I believe it is important when you are writing the code to avoid spending too much time on finding and fixing the bugs later on.”

You do not have all the experience we need for this position?

It is not possible for a candidate to have all the experience an employer requires. Even if you match yourself up to the expectations on technical front, there will be some difference in the work environment. And, it is absolutely fine. 

The best way to deal with this question is to analyses the requirements of the position well and match your skills as close to them as possible. If something is still left untouched, offer your quick grasping power and ability to learn quickly as a solution & back it up with an example from the past. 

What irritates you about co-workers?

The purpose of this question is to see how well you can fit into a team. Basically, you should not have a problem with a person, although you can have a problem with the style of working. So, to answer this question you can simply say, “I understand that IT is about team work, so we can’t afford to problems with co-workers but if someone is not serious about their work or does a low quality work affecting the whole project, I definitely do not like it

For how long do you expect to stay with our organization?

You should ensure that you give an impression that you will pay back more than what you take from the company: 

-You can say I will stay here as far as I see an opportunity for growth, as I am looking for a stability in work place 

-If they stress on number of years say 3-4 years, and more if I can explore new challenges/growth opportunities

Why should we hire you?

-Here you should discuss the profile you have applied for and your strengths/experience with which you can add value to the job 

-Discuss your achievements at your previous job, and say that I have developed my skills to suit my current profile, but I want to develop myself further and face new challenges, and for that I need to change my job. 

- I will always be willing to change roles share responsibilities to suit company requirements

Do you have any questions? 

This question is usually the last one an interviewer will ask as it is a logical way to end the interview. Never go to an interview without preparing questions to ask beforehand. Avoid asking about salary, vacation time, employee benefits, etc. until you have asked a number of other questions that demonstrate your interest in working for the company. Good questions to ask the interviewer:

What is your idea of an ideal company?

Do not go over board and ask for, it might give an impression that you are too demanding, some of the answers could be:

-An ideal company provides maximum opportunities for growth of employees. 

-They provide comfortable and flexible work environment, so that employees can perform at their best and work towards company’s benefit. 

-A company that encourages learning 

-A company that encourages opens culture

Why is this position available?

Is this a new position? Ho w long has this position existed? 

How many people have held this position in the last two years? 

Who would be my supervisor? To whom would I report? 

Whom will I supervise? 

With whom will I be working most closely? 

What do you like about working for this company? 

What are the current plans for expansion or cutbacks? 

What kind of turnover rate does the company have? 

How financially sound is this company? 

What projects and assignments will I be working on? 

What happened to the person that held this position before? Was he promoted or fired? 

What is this company's culture, (i.e., is it rigid and formal or relaxed and flexible?) 

What are the current problems facing the company (or my department)? 

What do you like the most about working for this company? The least? 

What is the philosophy of the company? 

What do you consider to be the company's strengths and weaknesses? 

What are the company's long and short term goals? 

Describe the work environment. 

What attracted you (the interviewer) to this organization? 

Why do you enjoy working for this company? 

Describe the typical responsibilities of the position. 

What are the most challenging aspects of the position? 

Describe the opportunities for training and professional development. 

Will I receive any formal training? 

What is the company's promotional policy? 

Are there opportunities for advancement within the organization? 

When can I expect to hear from you?

For Code Breakers

Here's a short collection of quotes from Clean Code, with my comments added after each quote.

"Later equals never."

In our youth we always said, "I'll clean up the code later", but of course we never did. "Later equals never" is known as LeBlanc's Law.

"The only way to make the deadline -- the only way to go fast -- is to keep the code as clean as possible at all times."

The only thing I'd change in that quote is to say, "the only way to constantly go fast". You can go fast in the short term by taking shortcuts, but not in the long term.

"Clean code always looks like it was written by someone who cares."

This was written by Michael Feathers. This quote reflects something I stress during training and mentoring sessions. Programmers need to think of themselves as craftsmen, and take pride in their work. Maybe customers can't see your work, but other developers certainly can, and you should take pride in writing crisp, clear code that other programmers can easily read and comprehend.

"Leave the campground cleaner than the way you found it."

This is similar to the previous quote. I didn't know it, but this is a Boy Scouts of America rule/slogan. In Alaska they have the exact same statement about using the Public Use Cabins here, leave it in better shape than the way you found it.

"The ratio of time spent reading (code) versus writing is well over 10 to 1 ... (therefore) making it easy to read makes it easier to write."

This was something I never really thought about before, but Uncle Bob Martin makes a very convincing case that when we're working on software projects with other developers, we're constantly trying to understand existing code when writing new code, to see how our new code should work and fit into the system.

"You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem."

That quote comes from Ward Cunningham (inventor of the Wiki, inventor of Fit, co-inventor of eXtreme Programming, and much more), who seems to be one of the greatest programmers of our time. I haven't met him yet, but whenever I read his writing, he blows me away. That statement alone sold me on this book.

Make your code read like a story

"The LOGO language used the keyword 'TO' in the same way that Ruby and Python use 'def'."

I never worked with LOGO, but the author begins describing how code should read like sentences in a book. Later he adds:

"Make the code read like a top-down set of TO paragraphs.

Eventually he takes these thoughts to this excellent conclusion:

"Master programmers think of systems as stories to be told rather than programs to be written."

For me, that's a very powerful phrase. I suspect you probably need to read his book to really understand what he's saying here, but if you read the section where he writes about the LOGO "TO" statements, he makes his point very well.

"In order to make sure our functions are doing 'one thing', we need to make sure that the statements within the function are all at the same level of abstraction."

This is another great line, and something I hadn't thought of consciously before. If code in a function is doing one thing at a high level of abstraction, another thing at a medium level, and another at a low level, it's going to be very hard to read, whether you consciously know why, or not. (This really is an excellent observation.)

Functions

"The first rule of functions is that they should be small."

As you've probably read elsewhere, a function should do one thing, and only one thing.

"Functions should do something, or answer something, but not both."

As he states, a function should change the state of an object, or return some information about that object, but not both. I've run into many functions over the years where a function was named "setSomething", and then when I looked at the source for that function, I found that it did several other things besides the "set" it claimed to do.

"Methods should have verb or phrase names."

Very true. I'm always naming methods "handleXYZ", "getXYZ", "calculateXYZ", and so on, trying to use verbs and action names.

"One way to know that a function is doing more than 'one thing' is if you can extract another function from it with a name that is not merely a restatement of its implementation."

This is another great observation that I've never thought about consciously. Many times you can look at a function and obviously know it's trying to accomplish more than one thing, but other times you look at a function and all you can tell is that it's wrong ... it doesn't seem right for some reason, but you can't put your finger on it.

Comments

"Every time you write a comment, you should grimace and feel the failure of your ability of expression."

Like many experienced programmers, the author has been burned by out of date comments, useless comments, and so on, and has come to the conclusion many others have: Most comments are not needed, and if you feel the need to write a comment, you should consider rewriting your code to make it more readable.

"It is better to extract the bodies of the try and catch blocks out info functions of their own."

This is a clever technique that can be used to make try/catch blocks as readable as they can be.

Clean Code, and the Principles of OOD

VERSION CONTROL

Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later

Local Version Control Systems

Many people’s version-control method of choice is to copy files into another directory (perhaps a time-stamped directory, if they’re clever).programmers long ago developed local VCSs that had a simple database that kept all the changes to files under revision control.

Centralized Version Control Systems

The next major issue that people encounter is that they need to collaborate with developers on other systems. To deal with this problem, Centralized Version Control Systems (CVCSs) were developed. These systems, such as CVS, Subversion, and Perforce, have a single server that contains all the versioned files, and a number of clients that check out files from that central place.However, this setup also has some serious downsides. The most obvious is the single point of failure that the centralized server represents. If that server goes down for an hour, then during that hour nobody can collaborate at all or save versioned changes to anything they’re working on. If the hard disk the central database is on becomes corrupted, and proper backups haven’t been kept, you lose absolutely everything—the entire history of the project except whatever single snapshots people happen to have on their local machines. Local VCS systems suffer from this same problem—whenever you have the entire history of the project in a single place, you risk losing everything.

Distributed Version Control Systems

This is where Distributed Version Control Systems (DVCSs) step in. In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don’t just check out the latest snapshot of the files: they fully mirror the repository. Thus if any server dies, and these systems were collaborating via it, any of the client repositories can be copied back up to the server to restore it. Every checkout is really a full backup of all the data