Special ORDER BY handling without accepting any default sorting option of DB

select * from users where id in (11,10) order by field (id,11,10);

SELECT * FROM "comments" WHERE ("comments"."id" IN (1,3,2,4))
ORDER BY CASE "comments"."id"

10 skills developers need in next five years

For those looking to get ahead in your field or simply stay employed, this is not the time to be complacent. Find out what skills to work on now to maximize your future job prospects.

With the recent changes in the economy, a lot of developers are focused on their short-term job prospects.

At the same time, it's important to make sure that you get the most bang for your buck when it comes to taking the time and energy to learn new skills. Hence, here is our list of 10 skills you should be learning right now to make sure that your resume is relevant for the next five years.

The list is hardly exhaustive, and there are huge swaths of the industry it won't cover (mainframe developers, for example). Nonetheless, for average mainstream development, you can't go wrong learning at least seven of these skills--not only to the point where you can talk convincingly about them at a job interview, but actually use them on the job.

1: One of the "Big Three" (.NET, Java, PHP)
Unless there is a radical shift in the development world (akin to an asteroid hitting Redmond), most developers will need to know at least one of the Big Three development systems--.NET (VB.NET or C#), Java, or PHP--for the near future.

It's not enough to know the core languages, either. As projects encompass more and more disparate functionality, you'll need to know the associated frameworks and libraries more deeply.

2: Rich Internet Applications (RIAs)
Love it or hate it, in the last few years, Flash is suddenly being used for more than just animations of politicians singing goofy songs. Flash has also sprouted additional functionality in the form or Flex and AIR.

Flash's competitors, such as JavaFx and Silverlight, are also upping the ante on features and performance. To make things even more complicated, HTML 5 is incorporating all sorts of RIA functionality, including database connectivity, and putting the formal W3C stamp on AJAX. In the near future, being an RIA pro will be a key resume differentiator.

3: Web development
Web development is not going away anytime soon. Many developers have been content to lay back and ignore the Web or to just stick to "the basics" their framework provides them with.

But companies have been demanding more and more who really know how to work with the underlying technology at a "hand code" level. So bone up on JavaScript, CSS, and HTML to succeed over the next five years.

4: Web services
REST or SOAP? JSON or XML? While the choices and the answers depend on the project, it's getting increasingly difficult to be a developer (even one not writing Web applications) without consuming or creating a Web service.

Even areas that used to be ODBC, COM, or RPC domains are now being transitioned to Web services of some variety. Developers who can't work with Web services will find themselves relegated to legacy and maintenance roles.

5: Soft skills
One trend that has been going for quite some time is the increasing visibility of IT within and outside the enterprise. Developers are being brought into more and more non-development meetings and processes to provide feedback. For example, the CFO can't change the accounting rules without working with IT to update the systems. And an operations manager can't change a call center process without IT updating the CRM workflow.

Likewise, customers often need to work directly with the development teams to make sure that their needs are met. Will every developer need to go to Toastmasters or study How to Win Friends and Influence People? No. But the developers who do will be much more valuable to their employers--and highly sought after in the job market.

6: One dynamic and/or functional programming language
Languages like Ruby, Python, F#, and Groovy still aren't quite mainstream--but the ideas in them are. For example, the LINQ system in Microsoft's .NET is a direct descendent of functional programming techniques.

Both Ruby and Python are becoming hot in some sectors, thanks to the Rails framework and Silverlight, respectively. Learning one of these languages won't just improve your resume, though; it will expand your horizons. Every top-flight developer I've met recommends learning at least one dynamic or functional programming language to learn new ways of thinking, and from personal experience, I can tell you that it works.

7: Agile methodologies
When Agile first hit mainstream awareness, I was a skeptic, along with many other folks I know. It seemed to be some sort of knee-jerk reaction to tradition, throwing away the controls and standards in favor of anarchy. But as time went on, the ideas behind Agile became both better defined and better expressed.

Many shops are either adopting Agile or running proof-of-concept experiments with Agile. While Agile is not the ultimate panacea for project failure, it does indeed have a place on many projects. Developers with a proven track record of understanding and succeeding in Agile environments will be in increasingly high demand over the next few years.

8: Domain knowledge
Hand-in-hand with Agile methodologies, development teams are increasingly being viewed as partners in the definition of projects. This means that developers who understand the problem domain are able to contribute to the project in a highly visible, valuable way. With Agile, a developer who can say, "From here, we can also add this functionality fairly easily, and it will get us a lot of value", or "Gee, that requirement really doesn't match the usage patterns our logs show" will excel.

As much as many developers resist the idea of having to know anything about the problem domain at all, it is undeniable that increasing numbers of organizations prefer (if not require) developers to at least understand the basics.

9: Development "hygiene"
A few years ago, many (if not most) shops did not have access to bug tracking systems, version control, and other such tools; it was just the developers and their IDE of choice. But thanks to the development of new, integrated stacks, like the Microsoft Visual Studio Team System, and the explosion in availability of high quality, open source environments, organizations without these tools are becoming much less common. Developers must know more than just how to check code in and out of source control or how to use the VM system to build test environments. They need to have a rigorous habit of hygiene in place to make sure that they are properly coordinating with their teams. "Code cowboys" who store everything on a personal USB drive, don't document which changes correspond to which task item, and so on, are unwelcome in more traditional shops and even more unwelcome in Agile environments, which rely on a tight coordination between team members to operate.

10: Mobile development
The late 1990s saw Web development rise to mainstream acceptance and then begin to marginalize traditional desktop applications in many areas. In 2008, mobile development left the launch pad, and over the next five years, it will become increasingly important.

There are, of course, different approaches to mobile development: Web applications designed to work on mobile devices, RIAs aimed at that market, and applications that run directly on the devices. Regardless of which of these paths you choose, adding mobile development to your skill set will ensure that you are in demand for the future.

Keep management roles in a project separate

Clear separation of three distinct roles--project manager, technical manager and relationship manager--gives projects a better probability of success and client satisfaction.

I've been on both sides of the desk in IT projects; I've provided services to corporate clients as an IT project manager and consultant, and I've worked for large corporations as an IT executive.

Something I learned from these varied experiences is that, whether providing IT services as an insider or an outsider, every IT initiative is an engagement. Every IT effort requires that the service provider play three distinct roles: project manager, technical manager, and relationship manager. While many independent project managers and consultants attempt to play all three roles, they do so at the risk to themselves, the project and the relationship.

Requirements of a successful IT engagement
Every engagement, inside or out, must have: a clear business meaning, a defined success criteria, a technical plan, and a project plan, as well as sponsorship and stakeholder participation.

Whether you're engaged as an outside project manager to manage the development of a huge data center, or you're an inside IT tech migrating users from Windows XP to Windows Vista, these requirements are constant. These unchanging elements of a successful IT engagement require project managers to think carefully about how many hats they try to wear and to separate their roles into different, often conflicting, responsibilities.

On tiny projects, such as replacing one worn-out server in a departmental data closet, it may make sense from a financial and an efficiency standpoint for the project manager (if she's got the technical chops) to assume all three roles. Once projects get any bigger, my view is that it's good practice to have three individuals in the roles of project manager, technical manger, and relationship manager.

Three elements to manage
I often tell my clients that every engagement requires the superior management of three elements: the process, the content, and the relationship. Here are more details about each element:

• Managing the process is the project manager's role. She must ensure that a clear scope has been written, a meaningful estimate has been derived, and a complete project plan has been developed, along with all the other process elements required by her chosen methodology.
• Managing the content includes all the technical decisions: the technical specifications, the materials list, the software stack, and the integration of all these components.
• Managing the relationship requires that the needs, expectations, emotions, and politics that are an inevitable part of every human endeavor be successfully managed so that the perception of the end product matches the client team's vision.

I'd wager that every working project manager has a horror story to tell about an engagement that circled the drain, or outright failed, because at least one of these elements was mismanaged.

Three roles of management
So why do I believe so strongly that it's a mistake for the project manager to try and take on all three roles (except in the smallest engagements)?

First, it's a skills and temperament issue. My experience is that project managers who excel in the process elements--following their chosen methodology and focusing on the details of time, scope, and function--often haven't developed their technical and relationship skills to the same degree.

The never-ending debate in the project management community over whether project managers must be technical proves that this is still perceived as an issue. There are exceptions, but developing strong project manager skills, getting certifications, and keeping those certifications current is challenge enough without also trying to stay ahead of the surging wave of technology developments.

More important than the skills and temperament issue is the simple fact that trying to play all of these roles is an irreconcilable conflict of interest.

I tell my students that project management is not a popularity contest; the project manager's role is often to play the "bad cop". The project manager needs to be the one to tell the client that the inside IT team is not pulling their weight, that the bug list is growing instead of shrinking, or that their genius developer is not such a genius after all.

While it's important for project managers to use diplomacy when delivering these messages, they must ensure that the client gets the message.

The technical manager must take ownership of the entire technical design, which is a daunting task, especially as projects grow in complexity. He doesn't need (and is often unprepared) to deal with the process and relationship issues that arise from his recommendations. The necessary actions of the project manager and the technical manager can lead to strained relationships if not handled with subtlety.

This is where the relationship manager comes in. In a contractor relationship, this manager is often the salesperson who introduces the contracting organization to the client and must keep that relationship on an even keel in order to get the current engagement delivered and to mine for additional projects in the account.

In this case, the relationship manager has a financial incentive to closely manage the relationship. Yet, even in inside IT initiatives, someone needs to ensure that the client and the stakeholders are satisfied, are getting the results they expect, and are willing to trust the IT delivery team to do future projects.

There are practical issues to this separation of roles. For instance, not every engagement can afford to have three team members doing these duties, and not every engagement is complex enough to require them.

Joomla Some good Plugins/Extensions

Joomla Some good Plugins/Extensions

Menus - swMenu

Events : redEvent

Newsletter: ccNewsletter

Photo Gallery: expose4

Video Gallery: expose4

Team Building and employee motivation techniques

One of the most important steps of a project is to carefully choose the team. This is not an easy job to do, because it requires a lot of objectivity and you must keep in mind the goal of the project and not the sympathy for certain persons. Before choosing the team you must think what kind of specialists you need exactly and this is the main thing you must consider when you choose the members: their specialty and your need for it.

Most of the times, having to choose a team means forgetting about sympathies and friendship and doing the right thing for the sake of the project. And because team building means more than just choosing a team, and also growing it and educating it, this also represents forgetting about yourself sometimes, especially when you’re the Project Manager or the responsible person for the success of the project.

The qualities needed for every project are patience, involvement, openness to suggestions and indications, pleasure and easiness for team working, etc.; but besides these there are also others to keep in mind and that regard strictly the type of project you’re working on.

It’s good to remember that team building means a lot of team coordination, a lot of suggestions and indications to give and a lot of questions to be asked. And this is something that takes place starting with the beginning, when you choose the people, and ending with the reach of the goal, when you finally take a break and celebrate.

Team building means talking, discussing, asking and answering, being ready for brainstorming or for working more than usual, listening and asking for suggestions, respecting and following the indications received, keeping the moral as high as possible and motivating the people when needed. All these are team works so, basically, team building doesn’t regard only the project manager’ tasks, but the whole team’.

Most important steps for a successful project

How many times have you heard about or been involved in a project that failed miserably? Or perhaps it just was not as successful as it needed to be. Did you ever spend time looking back to see what caused the project to go wrong. Next you have a few tips to help you understand what it takes to build a successfull project.

First of all you must know exactly what's your project about. You must discuss it with your team(if you have any) and you must agree precise specifications for it. You cannot start working until you have a well-defined idea in your mind.

Second of all you must plan the project. Here you should consider the time you need to finish it, the team you can relly on, the activities that must be done, the resources you have, and, of course, the financials.

During working time it's very important to communicate a lot with your team, to let them know what you managed to do, to ask questions and to give answers when needed. A lack of communication can lead to the failure of the project.

Also you must keep in mind to motivate and encourage your team when needed. You started the project as a team and you will finish it the same.

When the project is almost done you must check, measure and review it's plans. If you notice that something's wrong, you must inform you team and correct the errors. It's recommended not to leave this for the last moments when you don't have enough time to change anything.

After completing the project you must review it once more.If you are not pleased, don't start changing things because it could only be worse. It's very important to keep the armony and the well-organized shape of the project and changes on the spot can seriously affect that.

Some tips about project initiation

To efficiently initiate a project you need to keep in mind a few steps that will only lead to a good and organised work. So, first of all, you must document the business opportunity and find alternative solutions available. You can even search for similar ideas that have already been developped.

Second of all, you must conduct a Feasibility Study to investigate the chance of succes that you and your project have. This requires a lot of objectivity. It's important to know exactly how you stand and what are your chances of failure.

Third of all, you must consider new technologies for your project. It can be very helpfull, but it can also represent a risk because if anything can go wrong, it usually does. So don't try to make your work easier because you risk you make it harder.

And of course, after planning and discusing the project, after all the calculating part, you must start working. But you must keep in mind that the most important part of a good project it is it's initiation. When you start something like you should, it will be good. And when you don't, it will surely be a total mess.

Developing key performance indicators in projects

should preferably meet the following essential criteria:

• Be direct (no complex calculations)
• Be objective
• Be adequate
• Be quantitative
• Be practical
• Be reliable

Developing key performance indicators is best done in a kick-off meeting during the planning phase of a project.

It involves the following steps:

• Carefully consider the results desired
• Avoid overly broad results statements
• Develop a lot of possible indicators during a short brain storming session.
• Assess each indicator against the above criteria (be direct, be objective...)
• Select the best performance indicators

It can be an iterative process: if the resulting indicators do not look too good, restart a new brain storming session.

Hold People Responsible and Accountable

Generally responsibility for a project means: delivering on plans and commitments, being part of the team, acknowledging when there are problems and being willing to adjust personal priorities in favor of the overall project priorities.

First of all inside of each project and teams there must exist a set of rules that must be respected by all team members. For not respecting these rules there must be also penalties because most of the times people respect rules just because they fear the penalties.

Responsability also means being honest with yourself, understanding and accepting the quality of your work and the stage of your project. You cannot fool yourself because this only leads to failure.

Each person involved in a project has his own responsability. The Project Manager for example is responsible for clearly defining what is expected from each member of the team. The members of the team are responsible for maintaining conssistency, for asking help when they need, for reporting the problems that appear, for asking advices when they need.

Responsability also means feeling compasion and understanding a team member that doesn't fit in the project team and trying to help him. But this should never overcome incompetence because the final goal of the project counts the most.

Even if it's hard to do it, sometimes responsability also means removing someone from the team when he's guilty for intolerable situations like: abusive treatment or language, any discriminatory or derogatory words or actions, violence (including verbal assault) or any other physically inappropriate behavior.

Mainly responsability is knowing all the time what you want to do for that project, how it's supposed to be and dealing with people according to this. A lack of responsability can lead to a failure or to disputes between team members that's why it's good to maintain the objectivity no matter what.

How should I deal with changes to my project?

Changes to projects are something that always happen and we can't help from feeling them. It's normal to deal with changes during a project because during the project work progress you make new discoveries, you encounter problems which you must fix and you have new ideas that can improve the progress.

Generally speaking, there are 3 main categories of changes:

• changes that regard the time (the deadline of the project),
• changes that regard the resources available (people and money needed)
• and changes that regard the output (the form of the deliverables.)

You must keep in mind that any of these categories of changes can affect the end of your project and it depend of you to control it.

Generally changes occur step by step during one project and they are not so significant. But there are also situations when changes can be major and they can have a serious impact on the project.

In order to protect yourself and your project from big changes that can damage it, you should be ready for them and when they appear analyze them very well. To do this, you must consider the following questions and ideas:

• who needs the change,
• what is supposed to be changed and why,
• how important is that change for the project
• and what will happen to the project if you make the change.

It's important to know how to deal with important changes. Because those can really cause damage to your project and you should know very well their results before actually doing them. So if you are not sure that a change will affect in a good way your project, then better don't do it or do it very carefully.

Another thing that you should consider before changing something to a project is the authority that you have or don't have to do this. Because you wouldn't want to change something that will end up bad without being authorized to do it. If you are sure your change will be a good one, ask for permission first and then act. Don't rush into taking decisions or making changes because you might be wrong.

While you make a change you have to be very careful and to pay a lot of attention to it because it can have unexpected repercussions. For example when you change one of the team's member because he's more qualified for that job you can seriously affect team spirit.

The most important thing to remember about changes is that they simply occur. Sometimes because they are needed and sometimes by mistake. But If you pay enough attention to them the situation of your project can improve or at least remain the same, without being damaged.

When to reward your team

Traditional practices of rewarding project members at the end of a project or the month are far too common to give your team’s motivation that edge they need to really focus on their work. Instead, you should look at more creative and personalized solutions to rewarding your team. Not only will it build better rapport and boost team morale, the end result in terms of your project is likely to be much improved in quality.

Adjust your bonus policy to incorporate giving mini-bonuses throughout a project (or even at the start of one). Too often organizations get caught up in the thought that if you give your employees too much too quickly, they’ll start lagging behind in their work and take the organization for granted. As project managers, it would help to break out of the mold and instead, reward your team when you decide it will help their productivity the most. Giving a team member a break (or an effective rotation policy) during a project can very well boost their productivity by several levels. A short break can even be given before the start of a grueling project.

Similarly, if you are awarding monetary bonuses, there’s no need to wait till the end of the project (especially if this a demanding project). If a team member really excels at a certain phase, it’s much better to reward them with a mini-bonus right there. This will not only motivate them further, but also provide other team members incentive to improve.

Why over-delivering should be part of your project plan

Over-delivering has become the buzz word in internet marketing circles, and there’s good reason for that. Going beyond the expected requirements of a project not only gives your team a sense of accomplishment (especially if it is a tough project), but it also raises the bar and motivates the team to work harder and better. Ideally, over-delivering should not be part of the initial solution but something that is factored into the internal project requirements. Subsequently, it should be monitored, the additional requirements evaluated and milestones (if any) realized just as other components of the project.

Over-delivering isn’t always easy. For one, it sets a standard that you are then expected to follow, and this can turn into a vicious cycle if not taken care off. Instead of blowing the roof and doing twice the amount of required work, keep the over-delivering to a maximum of 10 to 20 percent of the total work. This sort of value-added delivery not only endears you in the eyes of your clients / superiors, it automatically adds to the benefits you and your team receive as a result. In the long run, a committed approach to over-delivering on your projects will afford you more clients, and within an organization, a reputation for doing the best work. That can only help you and your career.

Software Project Management

Part 1: Overview of software project planning

Software development has inherit problem with determining the time it takes to complete it. Software programming is quite different than say, nail production. When one produces nails it is known how many nails machine produces per hour. If you need to produce x number of nails figuring the time it takes is easy. If you need 12h of time, you know that one of your workers can handle the overtime and omitting for the sake of argument certain safety concerns, your worker will be as productive at hour 1 as hour 12. Unfortunately, software development is much harder than nail manufacturing. There are many more unknowns - risks that have to be accounted for.

• Risk management
• Avoiding common mistakes
• Practicing development fundamentals
• Following practices leading to best possible schedule

The reason for "might" is the risk based aspect - as mentioned before things may go right or wrong. It's all about leaning in favor of successful resolution instead of using methods that increase the chance of failure. One of the methods that increase risk, but are widely used due to their simplicity, is programmer total commitment. This disorganized way of project management has its successes, however these successes are a result of inefficient, hard work - not of smart work that can be achieved by following above four principles.

Part 2: Development speed

• The speed with which project is completed depends on four competing factors that are pooling the project in their respective directions.
• To achieve rapid development, you need to optimize all four factors listed underneath:
  • People - select top talent that is motivated in well organized team structure
  • Technology -
  • Process - create customer oriented software that incorporates high level of quality achieved with help of development fundamentals. Manage risks with lifecycle model and efficient use of resources.
  • Product - remember that size does matter, flexible requirements help in shortening of schedules.

Part 3: Most common mistakes

• People
  • Management decreased developer motivation.
  • Under-trained developers, developers with low qualifications.
  • Keeping problem developers (non-team players) on the team against wishes of all other team members.
  • Company encouraged developer "heroics", emphasis on "can-do" attitudes.
  • Adding people to projects that are over-running their schedule.
  • Working environment that prevents developers from focusing on their work. Customer interactions that are too frequent or lead to open conflicts.
  • Unrealistic expectations, usually in the area of project scheduling, wishful thinking.
  • Absence of executive project sponsorship, absence of agreement between all parties involved in the project.
  • Absence of customer involvement in the project causing delivery of software that doesn't meet customer expectations which in turn cause feature creep.
  • Involving developers in company politics more than is necessary.
• Process
  • Schedules that are to short for the project at hand - too much emphasis on optimism.
  • No risk management or insufficient risk management.
  • Problems with contractors (part of risk assessment)
  • Luck of, or insufficient project planning. Throwing out plans when placed under excessive pressure to complete project. Deliberately omitting non-code related activities, like design, due to excessive pressure.
  • Spending excessive amounts of time on project approval and budgeting.
  • Poor design and poor quality assurance.
  • To few controls placed on the development process causing schedule slips to go unnoticed.
  • Attempting to enter project "polishing" stage to early or more than once (frequent attempts to get it shipped).
  • Thinking that project which is in trouble can be saved by "catch up" later on.
• Product
  • Too many requirements, attempting to build systems that can do everything.
  • Adding to many new features to the ongoing project - feature creep.
  • Allowing developers to use new technology project for reasons other than project requirement.
  • Attempting to treat software research as regular software development.
• Technology
  • Silver bullet technology syndrome, over-estimating benefits of new tools and technology.
  • Changing tools or methods in the middle of the project.
  • Failure to keep code backups, no source control software.

Part 4: Software development fundamentals

• Development fundamentals reduce time and cost needed to develop software. However, they are not sufficient to develop software quickly, they are only necessary conditions for rapid development (ie if you don't have them you are almost certain to fail, but if you have them you are not guaranteed success).
• Development fundamentals can be divided into three areas that share fuzzy boundaries, non-technical, technical and quality assurance
• Non-technical fundamentals control all aspects of well known trade-off triangle (time, cost and product quality)
  • Ability to estimate project size. Once project size is narrowed down, ability to estimate effort needed to develop project based on project size. When effort needed is known, rough schedule can be created.
  • Ability to plan and stick to the plan under pressure. Planning can be further broken down into these components:
    • Team members, team size and team organization.
    • Lifecycle model choice.
    • Control over feature set.
  • Measuring progress through milestones (or micro milestones), reports, meetings etc.
  • Recording project statistics, at least cost, schedule performance and quality (three aspects of trade-off triangle).
• Technical fundamentals require knowledge of programming principles and experience in their application.
  • Ability to manage requirements can be further broken down into smaller parts:
    • End-user or customer involvement in requirement gathering process, for example through interviews
    • Making sure requirements are complete
    • Preventing frequent changes to requirements
    • Using requirements analysis methodologies, like object oriented analysis
    • Good graphical modeling of whole or partial systems, for example database diagrams
  • Good design
    • Good design starts with a choice of design style, for example object oriented design
    • Each design style has its own set of design concepts, for example inheritance
    • Using patterns to solve well known problems
    • Use of design software for large projects
  • Production of code that is of high quality
    • Naming and inline documentation conventions, rules for creation of new files and packages
    • Standard practices that lead to good code, like use of constants for values that don't change over time
    • Error detection
    • Unit testing and integration rules
    • Code refractory and optimization
    • Use of other software programs in creation of code, for example IDE choice
  • Management of software configuration deals with keeping the project feature set under control, most important feature set management technique is a change board. It decides what features are in and what features are out.
• Quality assurance is more than just testing
  • Ensuring that code created is of high quality (as described above). Code used for testing purposes should also be of high quality.
  • Focus on defect detection in early stages of project development, not just in code but also more importantly in earlier stages, such as requirements gathering.
  • Re-writing of all pieces of code that have high defect rate.
  • Remember that testing final product can show that it is of low quality but it cannot prove its of high quality.
  • Reading code is a good bug catching activity
  • Formal inspections are used to check adherence to project specifications on "industrial" scale. Each inspection team member has a specific role. Inspections are done on each major stage of project development. Inspections start with requirement inspection and end with final product inspection.

Part 5: Risk management in software development

• Risk management in general is a relatively new discipline, with software risk management playing the role of one of it's most recent advances.
• Risks come in three different forms, each associated with a branch of the "trade-off triangle". Software projects deal with risks associated with schedule, cost and quality.
• The goal of risk management is to minimize crisis management and failure and fix management styles while at the same time maximizing the prevention and elimination of problematic areas of the project.
• In order to achieve above goal risks have to be assessed first and then put under control.
• Risk assessment is made of:
  • Risk identification
  • Likelihood of events identified as risks
  • Impact study of each risk, with priority given to most dangerous scenarios
• Risk control is made of:
  • Preparing list of actions that have to be taken when each predicted event takes place
  • Making sure risk resolution plan is followed
• There are too many different types of risk to be enumerated here. Risks generally are mirror image of best practices, for example, inadequate design is a risk, while good design is a best practice.
• Risk exposure is the likelihood of the event multiplied by the impact the even will have. Events that are common but have small impact will produce the same risk exposure as events that are rare but have large impact.
• Risk resolution techniques can be as simple as avoiding the task that is risky, to as complex as development of contingency plans.
• Risks don't stay static throughout project development, they change. Risks need to be monitored. A good way to monitor risks is to keep a list of the most current top 10 risks.
• Be aware of projects that are very risky, projects with more than 90% failure probability. These projects don't pay in the long run.

Part 6: Choosing right development style

• There is no one single best practice that leads to the best software development method. For each specific project a method has to be chose that is appropriate for it. For example, mission critical software products have to be of much higher quality than a screen saver software.
• Not all projects need to optimize their development speed, many upper managers ask for speed but mean other things. For example, client will talk about quick development when they really want to minimize project overall cost.
• Unless product has a strong schedule constraint development speed might not be of top priority. If speed is not the most important factor, concentrate on quality.
• Remember, you can deliver projects with only 2 branches of the trade-off triangle.

• There is an absolute limit on the minimal time it will take to complete any given project.
• Projects cannot have 100% probability of completing on any given time because they involve risks (not everything in a project is certain) thus we are dealing with probabilities of completing on a given date.
• Projects that are rapidly developed can be seen by customers as slow because they don't provide a lot of feedback as to project progress.
• Remember that cutting time from the top most (done 1st) stages of the project will force you to pay back in time many times over in lower stages of the project. For example, design flow will cost much more to fix in the construction phase than design phase.

Part 7: Choosing right lifecycle model

• Lifecycle model gives order to operations performed from the time of project start (when the software is just an idea) till project completion (when project is absolute, no longer supported).
• Every project uses a lifecycle model, even if such model is not defined at project's start. You are using it even through you don't know about it.
• Every lifecycle model (other than code and fix) has the following essential phases:
  • Software concept - initial idea
  • Requirements gathering and analysis
  • Software design
  • Detailed software design
  • Coding
  • Debugging
  • Testing
  • Software delivery, project completed
• If an organization doesn't know what life cycle model they are using when asked, it means they are using code and fix lifecycle model.
  • Code and fix model was introduced together with the earliest software, in 1950's.
  • Through most organizations see this model as "evil" it does have few advantages and legitimate uses.
  • This model doesn't require any training - its natural, everyone knows how to use it without any training.
  • It shows signs of progress immediately since no formal planning is performed, programmers jump into coding phase right after initial software concept gets approval of upper management.
  • This model is good for tiny projects or for throw away one time only code.
  • For larger projects the list of problems with this model is very long, lets just leave it as an exercise to the reader to come up with a list based on premise "if you don't plan ...".
• The most basic and earliest organized life cycle model is called waterfall lifecycle model
  • This model goes from one stage to the other of software development in linear fashion
  • The waterfall model is old and has many known weaknesses, however, for some projects it is still very useful. It works well with complex projects that have very well known architecture. This model places emphasis on software quality, not on speed or cost of the software development.
  • Main weakness is outlined above already, most projects don't have requirements written in stone. Waterfall model is very inflexible - it is not the model that accepts change even in moderate amounts. It is a fact that most end-users, the customer that requests the project, don't know what they exactly want before project is commenced. Thus, the waterfall lifecycle model is not practical when faced with realities of everyday life.
  • Other problems include excessive amounts of documentation and very few signs of progress.
• Spiral - cinnamon roll model
  • The main idea behind creation of this model was risk control. This model is designed to minimize risks associated with software development.
  • This model divides the whole software development into a series of iterations. Each iteration can include the following five steps. Note that these are only basic steps iteration can include, depending on aim, some steps can be omitted, some may be added.
    • Plan out iteration objectives, prioritize objectives, plan alternatives.
    • Identify risks associated with objectives and route to their resolution.
    • Develop objectives (for example code).
    • Check whatever objective aim was achieve, quality assurance.
    • End current iteration, start planning next iteration, if one is needed.
  • Note that iteration(s) are needed for each of essential software phases.
  • This model is highly customized, the main idea is that of an iteration. Some iteration can take a form of another lifecycle model. For example, you may start with "regular" spiral model and finish with waterfall model once all risks are taken care of.
  • This model has one noteworthy disadvantage. All this flexibility comes at a price, this is one of the most complex lifecycle models. The trade-off is simplicity for flexibility. Note that most simple models like code and fix or standard waterfall are easy to master.
• As deficiencies of waterfall model became apparent a number of modified waterfall lifecycle models were created. Each of these models resembles standard waterfall in that it is easy to learn, but attempts to fix at least one weakness of the standard waterfall model.
  • Sashimi lifecycle model is a standard waterfall model with overlapping stages. It allows more flexibility in movement between consecutive phases. This comes at the price of unclear progress as phase boundary is fuzzy.
  • Waterfall with sub-projects lifecycle model trades increased (perceived and maybe real) speed of development for increased risk. In this model after software architecture is designed (on high level, not detail) project is divided into a number of small waterfall based projects that work in parallel. The idea is that some of these will produce results quicker than others. Problems could arise if unforeseen system inter dependencies are discovered between projects that are assumed to be separate.
  • Risk reduced lifecycle model was already discussed under spiral model as a possible modification. In this model risk is reduced by using spiral model for initial project design and proceed with standard waterfall model from detailed design till project delivery.
  • Staged delivery model proceeds as standard water cycle model until end of design phase. At this stage the project is divided into a number of phases that include all other stages of waterfall model. Important functionality is implemented in early stages allowing the customer to use the product as soon as few stages are complete. The main disadvantage of this project deals with large amount of planning needed for each stage. This model can also be adopted for projects on tight schedules. When a deadline that is immovable is reached, product completed some of its planned stages and can be shipped with most important functionality already implemented.
• Evolutionary prototyping model starts with a prototype that implements as many prominent visible features as possible. This initial prototype is then modified as per customer input until it is shipped as completed software product.
  • This model is great for projects that have rapidly changing requirements, projects where customers don't know or are unsure as to what they want.
  • The main disadvantage of this approach is related to the risk that uncertain customer brings to the project. If we don't know what the customer wants, we cannot know how long it will take to build.
  • Care must be taken to avoid morphing evolutionary prototyping model into a code and fix model.
• Evolutionary delivery model is a hybrid of evolutionary prototyping and staged delivery. In this model each prototype completed and a stage.
• There are many more lifecycle models to choose from. Each project is different. A choice of lifecycle model should be made with these point in mind:
  • How well do customers know what they want.
  • How well does the developer know system he needs to build, its architecture.
  • What is the overall system quality that is expected.
  • Future version planning emphasis.
  • What is the level of risk in this project.
  • What is the schedule like, is there a deadline that cannot be moved.
  • How much visible progress does the customer want.
  • How experienced is the development team.

Part 8: Project estimation

• Project planning is based on the ability to estimate project size and create based on size estimate project schedule.
• Software schedule estimation is "hard" because initial estimates are based on process plagued by multiple unknown factors. Thus, initial estimates are very inaccurate. As more is known about the project, schedule can be refined.
• At product definition stage there are many unknowns, thus projects estimated effort (and size) has a potential error of +500% and -%30 (with some large confidence interval, say 95%).
• Confidence intervals are used in statistics to measure how sure is the statistician that the phenomenon measured will fall within the range computed. Common confidence intervals are 90%, 95% and 99%. As confidence interval approaches 1 the range widens since it has to account for many unlikely events. 95% confidence interval is a good start.
• It is a good idea to refine project schedule after each milestone or stage is complete. Schedule should be more precise as it is based on more stable data.
• Parkinson's law: work expands to fill in available time. This implies that schedules that assign to much time to a project just to be safe risk loosing efficiency.
• In order to produce an estimate, the following estimates have to be completed:
  • Product size estimate - can be number of lines or number of function points (IBM method) or using special software
  • Product effort estimate - how many man-months will it take to complete project of given size
  • Schedule estimate based on effort needed, easy compared to above two steps, many formulas exist for automated computing
• Function points are also known as IBM method of 1984. A function point is assigned per certain level of complexity of either input or output to the software system.
• Jones's First-Order estimation is a method of deriving a rough estimate from function point count. A table is used to determine, based on software class, the exponent to which function point count needs to be raised in order to get number of months project will take to complete. For example, for average business software the exponent is 0.43.
• Lines of code make for an easier then function point estimate, however, same task written in different language requires different amount of code lines. For code line count only lines with the actual code are counted. Tables are used for projects that will need at least 10000 lines of code. Anything less than 10000 is usually done by single person and is correlated to abilities of that individual.
• The following are best practices for software estimation:
  • Never make "quick estimates". If you are forced to provide a number, make sure you provide a disclaimer as to its luck of accuracy.
  • Don't argue about the estimate or schedule - they are fixed and non-negotiable. Instead try to change inputs that produce the estimate.
  • Commitment based scheduling, where each developer commits to a schedule has a major problem related to natural tendency of developers to be too optimistic. The encouragement of optimism by managers makes for very inaccurate scheduling.
  • When estimating make sure you compare results to similar past projects. Make sure your estimates include trivial, common or obvious tasks.
  • When presenting an estimate use a range and/ or confidence interval. You don't need to be precise in range estimates, for example, you may say that in the worst case project A will be completed in the middle of December.
  • The best tool in project effort estimation is company's historical data.
  • You cannot refine project estimate before project start, even with more time. Refinement can only occur once project progresses.
  • When project is missing milestones, multiply the project estimate by 1 + amount of slip / old estimate - current project progress. For example, if a project with original schedule of three months is late one week, 6 weeks into project, then new schedule = 3 * {1 + 0.25/(3-1.5)} = 3 * 1.166 = 3.5
  • Project almost never catch up once they are behind unless project cost and/ or project features are changed in order to decrease project effort.
• Schedule can be derived from the following formula: schedule in time periods = corrective factor * man time periods ^ 1/3. Most typical time period is a month. Corrective factor varies, it can be anywhere from 2.5 to 3.5, with 3 a good guess.
• Schedules can be compressed:
  • Schedules can be compressed, however, compression of a schedule requires exponential increase in required effort.
  • Compression factor = desired schedule / initial schedule
  • new effort = initial effort / compression factor
  • It is believed it is impossible to achieve compression factor of less than 0.75.

Part 9: Scheduling

• It is rather easy to go from project size to project size and then to schedule estimate when compared to the task of getting schedule accepted.
• Higher management almost always pushes for overly optimistic schedules.
• Problems with schedules can be traced to wishful thinking of management/ customers and poor negotiation skills of the project manager.
• Most common scheduling mistakes:
  • Start project polishing procedures earlier than planned
  • Not adhering to plan when project runs behind schedule
  • Luck of good project planning
  • Too much pressure on development team causing dramatic increase in error count and loss of team morale.
  • Forgetting about the customer.
• Remember that you cannot cut out of the schedule non-code related activities since skimping on them will cause dramatic, as high as 10 to 100, increase in coding and testing.
• Good negotiation technique that is easy to learn is based on creation of "win - win" scenarios for both sides of the negotiation. This technique has four aspects that need to be followed:
  • Make sure objective criteria are used while discussing the schedule - the most important criteria is related to the schedule for given work - this is written in stone and cannot be changed, what can change is the work effort or expected cost (trade-off triangle).
  • The focus of the conversation should be aimed towards interests of both parties, not their positions/li>
  • The discussion is about the schedule, not people on either side of the table - as little emotions as possible
  • Aim at options that are going to benefit both sides, play with the trade-off triangle
• Insist on the schedule you have come up - its better to stand by and weather the rain then be under the drainpipe later on, once the project gets out of hand if your schedule is not followed.

Part 10: Developing for a customer

• The supreme goal of every software project is to create a product that is going to satisfy product users - customers. When customers are happy, everyone else in the company is happy.
• Not all solutions created by the developers are good for the customers.
• One of the most costly mistakes that can plague project development are related to development of products that end-users don't want to use. Creating something that was not expected by the customer leads to massive waste of money, as ultimate goal of producing what the customer wants is as (almost) as far away as when the project commenced.
• In order to produce product that customer(s) want, the following techniques of communication can by applied:
  • Requirements analysis - you need the "real" requirements, use techniques like user interface prototyping and focus groups to find out what customers really want to see in the product you are creating for them.
  • Project planning - you need to find out who you need to satisfy and establish good communication with that group of people.
  • Design - what you need to create is never written in stone, also, things will evolve later on as no project stays final for long. Thus, plan to change, create flexible designs (but not too flexible).
  • Actual coding - customers like to see project progress, it makes them feel safer, your job (as well as everyone else's in the company) is to keep customers happy - thus make progress visible to your customers.
• What customers expect and what developers can deliver frequently is not written on the same page. This leads to problems later on in project's life. Make sure customers know what they should expect as far as project cost, speed and functionality is concerned. Never lie to your customers, as a lie will sooner or later come out of the closed and poison your relationship with your customer.

Part 11: Developer's motivation

• Developer motivation is the most important factor in determining that developer's productivity. The difference in productivity between unmotivated and very motivated developer can be as high as 1:10.
• It is hard to measure effects of motivation on productivity since motivation is not a material entity.
• Different people are motivated by different things, for example, software developers are motivated as a group by different things than average manager. The difference is quite wide - developers frequently motivated by opposite factors than their managers.
• Some of the most important motivating factors for developers are:
  • Achievement recognition - set a goal that developers can aim for, be it fastest code or shortest amount of code. Let developers take control of the project, like setting up their own ambitious schedules.
  • Growth in their chosen IT profession - make sure your staff is up to date in their IT skills. Developers love to learn new tricks, make sure you train them or allow time off for training.
  • Enjoyable work - developers like to do important tasks that involve use of their technical skills. The dislike producing low quality products. Make sure your developers are distracted as little as possible by people or administrative tasks.
  • Ability to have fulfilling family life - when rewarding developer remember that he would rather have time off than sit at the desk for 10 more hours.
• Other things that will make developers happier and thus more productive:
  • Flexible office hours - it is a great idea to let the programmers choose their office hours as people are most productive (and less sleep deprived) at different times of the day.
  • Private space, a room for every programmer is a good idea.
  • Good PC support, up to date hardware, easy access to all office supplies.
  • Easy access to newest reference books.
• In order for something to motivate an average developer it has to be logical - for example, a deadline that is not achievable when careful project planning is done will not motivate developers but their managers. Only a deadline that is achievable (but possibly hard to achieve) is going to motivate you development team.
• In order for your developers to stay at your company you need to reward them for their work frequently. Don't underestimate the power of non-monetary gifts. Team t-shirts and other small items are reminding developers just how much you appreciate their hard work.
• People by nature like to discover things, they like to travel and they perform better if they are part of a study. Take advantage of this natural tendency, also known as "Hawthorne effect". People do better if they know they are part of an experimental software group.
• Avoid these activities that kill morale - these are opposite to the factors that increase morale.
  • Don't lie to your staff - fake deadlines are easy to spot.
  • Too much pressure is exactly as it sounds, too much. Your stuff will loose their ability to work efficiently.
  • Make sure that managers which don't know too much about technology stay away from your stuff. This also applies to sales and marketing department members - their role in the company doesn't include developer harassment.
  • All decisions that effect developers should be discussed with them. It is a bad idea to make decisions for your staff, since they no longer feel that they are part of the team. They are no longer on a mission but are experiencing hardship.

Part 12: Teamwork

• Team is made up of up to 10 people that agree on common goal and way to reach this goal. People that make software teams also have complementary IT skills.
• Performance differences between teams are almost as great as performance differences between individual developers.
• All high performing teams have common characteristics which are listed underneath:
  • All team members share the same goal, this team mission is well understood by every team member.
  • All team members share the way team goal is to be achieved.
  • Teams are separate entities, there is a sense of pride of being in one team versus another, competitiveness vs. other teams. Members of a team are no longer individuals - they are team members. Team success is much more important than individual success.
  • Every team member is an expert in his or her area. Team has to have balanced technical skills to be effective, no amount of work is going to push a project if team members simply don't know how to do push. Non-technical, soft skills are also needed in support roles.
  • Every team member trusts and respect every other team member.
  • Working with the rest of the team is very enjoyable for every team member.
  • Team members communicate well with every other team member, sometimes using team exclusive terminology.
• The following is a list of what can go wrong with a team in addition to negative of characteristics listed as good team properties.
  • People that are "members" of a team but chose to sabotage team efforts. These are problem employees and they should be removed from the team as fast as possible. Ignorant and secretive as to their work people have no place on a development team.
  • Factors that prevent teams from doing their job, like inappropriate management involvement.
  • As with individual developers, teams need to be recognized for their hard work.
  • The whole team shares successes, but as in a marriage, the whole team shares failures as well. Everyone is contributes to team success, thus everyone is accountable for team mishaps.
• Software managers should be concerned with clearing development roadblocks and allow the team to be more efficient. His or her role is that of a supporter, product could be developed without the manager but not without the developers. Managers should deal with non-technical issues.
• Technical leads are programmers with extra responsibility. They are responsible for technical aspects, like design, on a single team. They should leave as much non-technical work as possible to managers.
• It is OK to let teams sit idle for short period of time - it is much more expensive to build new team from scratch later on.
• Teams, as individual developers, should be kept away from company "politics".
• As with lifecycle models, there is no one perfect team structure. Team structure is the way team members are organized inside the team.
• There are three main team types, you choose a type based on project objective. As there is no best lifecycle methodology, there is no best team structure - it all depends on what you want to achieve.
• The following list outlines most common development team models:
  • Business team - most common in the industry due to its simplicity. This team has a lead developer with a group of developers of equal standing. Lead developer is usually the team contact person for the management and the developer who has the last say in technical disputes. This team structure is very flexible, it can work on any project, but its flexibility comes at the price of not being the best model for any particular problem.
  • Surgeon and nurses team - in this team bulk of design and code is done by a star developer. Other team members specialize in different areas of surgeon support. This model is well suited to projects that either have a good plan or need creative mind.
  • Skunk works - if your goals are extraordinary you need to loosen usual rules. A Skunk Works is often a small (in order to reduce communications overhead) team that develops something in a short time with minimal management constraints. Can be used to spearhead product design that later will be developed according to the usual rules. Can be used for secret projects - great for research projects.
  • Feature selection team - has representative from every party concerned, ie development, management, marketing, quality assurance etc. Good for problem solving areas as it has great decision power due to representation from the whole company.
  • SWAT/ Commando teams - used for emergencies made of highly trained individuals that form a permanent team structure. All members are trained in specific area of development, for example in ASP.NET. Used for both problems situations and where there is a need to quickly execute a plan.
  • Firefighter team - this team can be assembled and put into action at moments notice, at any time. Used for emergencies - problem resolution.
  • Theater - developers play different roles with the manager acting as the producer. Roles developers are assigned don't change. Good for multimedia projects which have to do a lot with art.
• Team models are applied to solve three main types of tasks:
  • Specific problem resolution
  • Research and development
  • Plan centered execution
• On every team there should be a person responsible for the conceptual integrity - a team leader.
• On large teams communication overhead can slow development. Break large teams into smaller ones, of no more than 8-10 people each - form a hierarchy. It's a good idea to use military as the model, where squad leader is the person that has the most people under him (8-9). Officers have at 3-4 people they directly command.

Part 13: Feature-set control

• One of the most common reasons why planned schedules don't reflect real schedules is the problem of creeping project requirements.
• You need to take control of the feature set:
  • Use minimal documentation - avoid wasting time on non-essential document preparation, prevent documents from becoming obsolete due to problems with their maintenance, constrained design - luck of flexibility that will allow developers to create features faster.
    • Make a short introductory project paper, about 5 to 10 pages in length.
    • Common vision specification - one time only approximation.
    • Create manual that will serve as a specification.
    • Create visual story book - pictures are worth 1000 words each.
    • Create project vision as to what is the overall mission/ goal.
    • Make sure you don't omit critical features.
    • Don't gold plate anything.
    • Be advised that minimal specification will limit your abilities to participate in parallel activities.
    • Remember that you should use minimal specification only when project allows for flexibility - your goal is to trade speed for some fuzziness in the overall design your team is going to use.
  • Remove and clean requirements - if something is not needed it can be removed, if it doesn't have to be coded and planned for then it doesn't require any effort. This is one of the best ways to shorten your schedule.
    • Remove what is not needed.
    • Simplify everything that is needed.
    • Use less ambitious options for most time expensive features.
  • Understand sources of changes and how to control them - note that developers, end-users and marketers will try to change the requirements. Avoid commitment to impossible goals, frequently proposed by people that want to create a "killer" application.
• You should not assume that there never will be any changes, or that you can prevent any change requests from occurring. Needs of your customers will dictate what you need to create. You don't want to produce a product that is inadequate due to your resistance to change.
• Control of requirements stability is important to overall success as one of the more critical mistakes that you can make is to assume that your requirements are stable while they are swinging back and forth.
  • Work on the requirements closely with the customers, use prototyping techniques, lifecycle processes that give a lot of feedback to the customer.
  • Provide cost and schedule estimate for every change - even small changes late in the project can have large cost.
  • Move features to the next version - quick release cycles help a lot.
  • Create a group of people responsible for change request processing - make sure process is not to bureaucratic.
  • Implement software development method of triage - where only the most important changes get to be implemented.

Part 13: Productivity tools

• Productivity tools help with development work, however, remember that they usually never help as much as marketing department of the company that produces (sells) them.
• Remember that every new tool and every new technique requires learning time. During training tools use might decrease development speed instead of increasing it. Without training in the usage of the new software your team might not be able to use it efficiently, negating all the gain that the tool would have brought with it in terms of time savings.
• No tool or technique will provide dramatic improvements when used alone - don't get fuelled by empty claims of software vendors.
• Tools are great at helping with tasks that computers were designed to simplify - for example, they can eliminate need to repeat any aspect of development work. Good HTML development environment will provide closing tags to all open tags entered by the developer.
• Higher level programming languages trade speed for decreased detail control. If you don't have tight specifications and are able to satisfy your customer with standard application look then savings will be noticeable.
• You may consider creation of a special team of experienced developers responsible for new tool acquisition. This team will analyze and suggest new tools.
• All software that you going to buy should not only satisfy your current needs, but also your needs in the foreseeable future (not too far away future - only the one you can see from planning).
• You should by software from reputable vendor of good quality (version 3 and above show that the "baby bugs" are mostly eradicated and that the vendor will be less likely to cancel further tool development work).
• Total payoff from the usage of a tool should be counted against the area the tool acts in. For example, if you switched from C to Visual Basic you should expect most savings in coding, less in design, none in testing.
• Savings in effort needed due to the use of a tool don't linearly correspond to savings in schedule.
• CASE tools are in most cases (except where high amount of database work is involved) high end diagram creation tools.
• Object oriented programming is great for reusability of code, however, it doesn't offer any improvements as far as ease of use is concerned. Contrary to popular claims, OO is not more natural way to program (if it was so natural we would all be great OO programmers - everyone knows that is a false statement).

Part 13: Project recovery

• The key to placing project under control is to go back to the basic ideas of software development.
• Don't rescue projects that are just having small problems. Through it might seem wise to try to cure the problem early on, before it develops into a full-grown disease. Rescue that is started to early will be seen in negative light by upper management, which will never see any problem with the project as it was. They will, however, see you, project manager as the one crying for help prematurely - whistle blower.
• When you want to regain control, don't shorten any development phases. If you do, you are loosing control over the project rather than gaining it (as you known less about what is going on).
• You need to be realistic as to what can be done, ask your team members what they can do. Developers will not commit to objectives that are out of their reach (they are too logical to do so).
• The following is a list of steps you should follow when you begin project rescue:
  • Find out what is going on in the project - make a quick reckon of project accomplishments so far and its goals.
  • Do anything in order to restore your teams morale and commitment to the project.
  • Remember that one of the classic mistakes that you can do is to add people to the project when it is in need of help, sometimes this can help - but it needs to be very well planned operation.
  • Make sure you eliminate as many classical development mistakes as possible.
  • Your developers task completion should be evaluated using binary system, either they done their task 100% or not (anything less than 100%).
  • Small milestones should be scheduled. Project and individual developer recalibration should be done on weekly basis.
  • Make sure project requirements don't change - you don't want to chase shadows. If possible, remove as many features as possible from project specification.
  • Remove broken parts of the code - re-write them if necessary

Project Manager Interview Questions

Questions That Examine Leadership Potential

1. How do you handle non-productive team members?
2. How do you motivate team members who are burned out, or bored?
3. How do you handle team members who come to you with their personal problems?
4. What are your career goals? How do you see this job affecting your goals?
5. Explain how you operate interdepartmentally.
6. Tell me how you would react to a situation where there was more than one way to accomplish the same task, and there were very strong feelings by others on each position.
7. Consider that you are in a diverse environment, out of your comfort zone. How would you rate your situational leadership style?
8. Give me an example of your leadership involvement where teamwork played an important role.

Questions That Examine Personal Strengths and Weaknesses

9. Why are you interested in this position?
10. Describe what you think it would be like to do this job every day.
11. What do you believe qualifies you for this position?
12. What have you learned from your failures?
13. Of your previous jobs, which one did you enjoy the most? What did you like the most/least? Why? What was your major accomplishment? What was your biggest frustration?
14. Tell me about special projects or training you have had that would be relevant to this job.
15. What are some things that you would not like your job to include?
16. What are your current work plans? Why are you thinking about leaving your present job?
17. Describe an ideal job for you.

Questions That Examine Judgment

18. What would you do if you found out that a contractor was in a conflict of interest situation?
19. If I were to contact your former employee, what would he say about your decision-making abilities?
20. Give me an example of a win-win situation you have negotiated.
21. Tell me about your verbal and written communication ability. How well do you represent yourself to others? What makes you think so?
22. Give me an example of a stressful situation you have been in. How well did you handle it? If you had to do it over again, would you do it differently? How do you deal with stress, pressure, and unreasonable demands?
23. Tell me about a tough decision you had to make?

Questions That Examine Experience

24. Describe what you did at your work place yesterday.
25. How would you solve the following technical problem? (Describe a typical scenario that could occur in the new position.)
26. What strengths did you bring to your last position?
27. Describe how those contributions impacted results?