Coolbits Tips

Lance's Whiteboard contains a recent post about how the success of a project is ultimately determined by the habits, attitude and style of the team members and project members, rather than the project methodology.

Oh, how true.

Back when I worked at SRM there were a number of projects that went badly. This occurred during the IT boom, when there was so much IT work everywhere and consulting organizations were just trying to keep up. We hired tons of people, some experienced and some fresh out of school with little or no experience.

When things went badly, we decided we weren't managing things very well, and that we needed to add more process to our approach. So, a group of individuals got together and developed a Project Consulting Framework (PCF). It was supposed to guide us through a project from sales to final sign-off. The organization spent a ton of resources building the framework, developing a curriculum and training the staff. It was seen as a worthwhile investment, because it would help us prevent bad projects that hurt our bottom line and our reputation. And they tried to make it part of the culture - we had company parties where we played PCF Bowl, and we had PCF awards.

I don't really know if PCF made a difference. I learned a lot of interesting things during the training, so I'm sure it had some effect.

But...

After a while, I realized that not everyone followed the framework. And some people followed it in a way that was counter-productive. They used PCF as a way to justify the goofy thing they were trying to do.

Even one of the persons principally involved in developing PCF wasn't as good at following through with communication. Apparently, he was a lot better at telling other people about the importance of effective communication than he was at effectively communicating on a project.

Which brings me back to Lance's Whiteboard. In the end, we can use all the tools and methodologies and frameworks that we want to, but it really doesn't matter as much as the people involved. If you are hire talented individuals, who care about the craft and the business and each other and the customer, there is hope of success. If instead, you just trying to set-up a bunch of rules and processes and hope that it will make up for the limitations of your team, you are in for a rude awakening.

1) Break down the tasks to no larger than a few days work, and hopefully smaller. The larger the pieces you are estimating, the more likely you are forgeting a task or step. So break it down into smaller bits.

2) Have someone look over your estimate. Or have them put together their own estimate separately. If you both come to roughly the same numbers, you can feel more confident about your numbers.

3) On medium-sized or larger projects, encourage customers to build in a change budget up front. Then, you've got a place to go for the funds when a change is required, and your customer contact doesn't necessarily have to get lots of approval from others.

4) A lot of people build a "fudge factor" into their estimates. I recommend adding a buffer based on your confidence in the estimate. For example, if I'm familiar with the customer and am comfortable with how they work, my confidence is higher and my buffer might only be 5% or 10% of my total estimate. But if I'm less familiar with the customer, or the technology, or something else decreases my confidence level, I might add a buffer of 25% or more.

5) The people who will actually write the software should create the estimates. Different developers have different skill sets and levels. What might take one developer 2 hours might take another 10.

6) Historical information is the best predictor of the effort required to develop software. Look at past similar projects for clues on a new estimate.

What makes someone a good software developer? Or more precisely, what qualities does a software developer exhibit that makes me interested (or even eager) to work with them again? Here are the things I am looking for in a fellow software developer:

Asks questions appropriately. Meaning: don't ask for help on every little stupid thing, and also don't beat your head against a wall for three days before telling me - "okay, I'm stuck".

Asks about priorities, if unsure about them. For example, don't assume that the deadline is the most important thing, unless I've already told you that.

Adheres to the standards on the project. I worked with a guy once who set his tab spacing to 8 characters. Can you imagine what that was like to try to read? Okay, that's a dumb example, but do it the way we have already agreed to, unless you can convince me that you have a compelling reason not to.

Demonstrates reliability. Stop telling me you only need two more weeks, since you told me that 2 months ago, and it doesn't look like it is getting any better. Give me a real number, or don't bother making one up.

Admits it when he/she is wrong. No one is perfect, myself included. But I can't take you seriously if you won't admit your mistakes.

Doesn't constantly reinvent the wheel. If there is code already out there that will do what we need, why are you wasting 2 days on writing something you like better? Just use what already works and MOVE ON! (Okay, I'm guilty of this one too sometimes!)

Takes personal responsibility for the quality of his/her code. I saw a guy once who was supposed to design and code the reports for a project. His design was useless. Everyone signed off on the design, because we were crammed for time, and well, he was writing the code anyway, so people thought he had it all in his head. Not so. The reports were slow and didn't work correctly. Another group of people came in and had to re-code the entire thing! Meanwhile, no one wanted to work with this guy, so he was put on the bench, where he started learning new technology - in other words: playing! Every day, people came in and re-wrote his crappy code, and he was goofing off. If it would have been me, I would have come in every day and offered to get those people coffee, donuts, lunch, whatever, because I would have felt guilty. If this guy felt bad - he didn't show it to the people who suffered.

Communicates with me (and others). Tell me what is going on. Tell me if you think you'll be done early - maybe someone else needs some help. But more importantly, tell me when things are going badly. Please, I really need to know.

Isn't selfish. You know, other people are working on this project, too. We don't appreciate it if you take all the credit, and slap us with the blame when things go wrong. Also, don't keep all the "fun" work for yourself, and dump the crappy work on the rest of the team.

A lot of these items may look as if they only apply to software developers who are working on team, but I think they can apply even if you are programming alone. It is still important to communicate with your manager, or your customer, or the end users. And they will quickly realize if you are selfish or unreliable.

These are the things I look for when putting together an effective programming team.

ASP.NET security has bitten me again. This time, I got to fight with Windows Server 2003/IIS 6 and ASP.NET. Here are a few things that you might find useful when you are configuring this yourself.

Remember how classic ASP used to run under the context of the SYSTEM account by default, and how annoying it was when you switched to ASP.NET and nothing worked until you learned your app was running under the ASPNET account instead? With IIS 6, instead of using the ASPNET account by default, it now uses another account. I don't know if this changes depending on the type of Windows Server 2003 install, but in my case it was the Network Service account. Giving this account NTFS rights to the physical folder for my virtual directory solved my particular problem (which was a 404 error.)

A google search described several other causes of a 404 error for Windows 2003 server, including ASP.NET not installed correctly, the extension mappings not set-up properly, the default page not set properly, issues with IIS 5 compatibility mode, and issues if your app requires version 1.0 of the framework. I'm not going to post solutions for all of these items, because there seemed to be plenty of good info out there via google, but it is something worth mentioning.

I was just relieved I figured out my particular problem. I don't really understand why the default account for ASP.NET had to change (yet again), but I hope that it stays the same for a while (like at least until Longhorn!)

[Update on 01/30/04]: Based on Julia's report, it appears that the Network Service account is also used if Windows 2003 is a domain controller. That's a good thing to know - I would have expected it to be the IWAM account.

One of the features of my product Mister Lister is that it creates a list of the records in the database. I do this with an ASP.NET datagrid control. Since users can select which columns should display in the list, the columns are dynamically generated at run-time. Up until now, I had been doing this with a bound column.

However, while Graham was doing some testing yesterday, he discovered that he could generate errors with certain key combinations. As it turns out, I had left the ValidateRequest attribute set to True, and ASP.NET was warning me that some of the data looked a little like script and was potentially dangerous.

At first, I looked at ways of using a regular expression to trap this within a validation control instead of generating an error. But I'm no regular expression expert, and the examples I found were too limiting on regular input (in my opinion). I realized that the problem isn't really when I save the data, it is when I redisplay it to users. I just need to make sure that I am using HTMLEncode when displaying the data in certain controls like labels or literals.

No problem, I thought. I only do this on the list page. However, this meant that I couldn't dynamically generate my datagrid with bound columns, because I couldn't format the data with a bound column. So, I needed to change to a dynamically generated template column.

Most of the examples I found for this were in C#, or didn't seem to work properly. (I even had trouble with the example in MSDN.) So, I've included my code for doing this here. Hopefully this will help some other person who is trying to do this in VB.NET.

First, I created a separate class that implements ITemplate. In my case, I used a constructor that would pass in the column name and column type, since I need to do different formatting depending on the type of data.

By implementing the ITemplate interface, you need to override this method. Within ITemplate, I used AddHandler to hook the DataBinding method of the container to subroutine within the class to format the data. Here's what this new class looks like:

As I prepare to release version 1.0 of Mister Lister, I have discovered yet another limitation of the setup projects you can generate within Visual Studio .NET. I'll admit, however, that this particular limitation may be related to the MSI format itself.

I am creating a standard setup project (for a WinForm application). However, since I know Mister Lister will require IIS, I am also adding IIS as a launch condition within the setup. This should prevent anyone from installing Mister Lister unless IIS is on the machine. By default, a launch condition is already established for the .NET Framework.

I would prefer that my setup check for IIS BEFORE it checks for the .NET Framework. That way, IIS will be installed BEFORE the .NET Framework is installed, which will (hopefully) limit support issues related to .NET not being registered with IIS properly.

However, the .NET Framework condition seems to always be checked FIRST. At first, I thought this might be related to the order they are displayed within the Launch Condition view within VS.NET. So, I tried renaming my condition so that the .NET condition would show up after the IIS condition. However, this did not solve the problem.

I did discover a message via a google search that identifies the problem. If the InstallURL property is empty, the condition will be checked AFTER all the conditions where the InstallURL is not empty. I thought perhaps I could use Orca to manually change the order. However, I have discovered something. If the InstallURL property is not blank, the launch condition shows up in the VsdLaunchCondition table. However, if the InstallURL property is blank, then the condition ends up in the LaunchCondition table. Editing the VsdLaunchCondition table will not help, because the Url value in that table cannot be NULL anyway (which is probably why it gets moved by VS.NET).

So, anyway - what can you do? Well, one possibility is to add a URL that points to the Microsoft site with information about IIS (something like: http://www.microsoft.com/iis/). Keep in mind that you'll want to adjust your message so that it tells the user what to do. For these launch conditions that have a URL, the dialog box is a Yes/No box, with the Yes prompt loading the URL. So, your message could add something like: "Click Yes to read more about IIS on Microsoft's website."

This was the approach I was going to use at first, but I have come up with something that I think is better. Instead, I have changed the InstallURL property to read: "control.exe". This loads the control panel when the user clicks on "Yes", which is closer to what they want, since they will need to use Add/Remove Programs to install IIS. (Anyone know how to directly load Add/Remove Programs? If so, I'll switch to that!)

A lot of applications I build require roles based authentication. Also, I generally utilize forms authentication for my applications. (Not always, but frequently.) When implementing forms authentication in ASP.NET, sometimes the role implementations are simple and sometimes they are complex. For simple implementations (just a few roles), I like to use the UserData property of the FormsAuthenticationTicket object to store a simple list of the role values. Then, later on in my code I can just retrieve the ticket with the user data, decrypt it, and see if the specific role I am testing for exists in the UserData.

This works great, as long as you do NOT use the RedirectFromLoginPage method. This method does not use the cookie created from the custom ticket, and so the UserData is lost. Instead, always retrieve the redirect URL from Request("ReturnURL"), and then manually redirect to the appropriate URL.

If you are using Visual Studio .NET, are you using code regions? This is a feature that is easy to forget about, but really offers some great functionality for organizing your code within a class or module.

To use, simply wrap the desired code as follows:

#Region "Database Routines"

...Code here

#End Region

Now this code can be expanded or collapsed as desired. One section of code for me ended up looking like this:

Now I can also work with this code more easily. (I also look forward to the additional code outlining features provided in Whidbey!)

Something that can be a bit confusing in VB.NET (especially to those who upgraded from VB6) is the use of the Imports statement. I'm often asked - when should I use Imports? Isn't adding a reference enough?

Actually, these two tasks perform different but related functions. Adding a reference to DLL in your project makes the objects in that DLL available for use within your project. So if you have built a component for use within all your projects of your commonly used functions, then the best way to access your component is to add a reference to it from within a project.

Using the Imports statement has more to do with ease of use. If you merely add a reference to a component, and don't use Imports, you can still utilize the objects within the component, but you'll need to enter a fully qualified name for each object. So, for example, my function to fix quotation marks in strings so that the database will store them properly must be referenced like this in code:

CodePoet.Common.StringHandler.FixQt(strVal)

As you can imagine, this can be a bit of typing after awhile.

However, if I choose instead to use the Imports statement, like this:

Imports CodePoet.Common.StringHandler

From within my code, I merely have to type the function name, like this:

FixQt(strVal)

Also, if it appears that there will be overlap in the function names of the assemblies I am referencing, I can utilize aliases to separate things. To do this, I indicate the alias in the Imports statement like this:

The other day I was working on on the web setup project for Mister Lister. I was having a problem with some of the application settings in the web.config. These settings indicate path information for files necessary for Peter's Date Package and Professional Validation and More. The files are installed with Mister Lister in sub-folders of the main application. In the web.config, I was referencing the folders like this:

Of course, that's great until the user installs Mister List in a virtual directory other than "Lister". I spent most of today thinking about adding a custom action to my setup that would change the entries in the web.config (ick!)

It just dawned on me that instead, I can use the tilde (~) character. This represents the application virtual directory. Now, my entries look like this:

<add key="PDP_ScriptVirtualPath" value="~/DatePicker/Scripts/" />

It doesn't matter which virtual directory they are installed in, the web.config is fine. Or, I can even install Mister Lister in the application root. Yippy! Problem solved.

Lorenzo Barbieripoints out that the IIS Lockdown tool is important for IIS security, and it should really be executed on all servers (production, staging and development). However, this tool will prevent your staging and development servers from utilizing debugging mode. He also suggests the symptoms and cure. Thanks!

One of the things I always struggle with are how to handle installations for web applications. I like using the web setup project template available in VS.NET, and for simple things I've had some success. But one thing that frustrated me was that during the installation process, it always asked the user to indicate the virtual directory I want to install to. That's great, but what if I want to install into the root folder of my website?

No problem, because all you need to do is remove the text in the textbox. You are allowed to have the virtual directory name to be blank, which will automatically put your installation in the root folder for the website. Here are few other facts:

If you have multiple websites defined on your webserver, the install will not prompt you to select the website - it just selects one for you. If you stop all but the correct site, it will install into the running site, so I use this trick to get my installation into the correct website.

If you like to define a different location for your website or virtual directory, I recommend that you create the site or virtual directory first, pointing it to the desired physical location. During installation, your files will then be located in the correct place.

Dave Burke's blog mentions something that was unknown to me - classic ASP is disabled by default in Windows Server 2003. If you search to an ASP page, you'll get a generic 404 error, unless you enable it within the Web Service Extensions in IIS.

Definitely something to keep in mind if you are migrating more than ASP.NET applications to Windows Server 2003.

Managers of software teams often ask “How can I make my team more productive?” If there are members on your team that are less experienced developers, then an easy way to begin is to focus on improving their productivity and effectiveness. One method to accomplish this is through mentoring. Here are some suggestions for establishing mentoring relationships on your teams.

Selecting the right personSelecting the right person to mentor team members is very important. Not all technologists make good mentors. The best mentors have the right attitude, demeanor, and skill set. If possible, a senior developer on your team may be the best place to look for mentoring material. Mentoring is a good manner for senior developers to expand their skills into other areas (such as training.) Also, mentoring can provide a good opportunity for team members to learn to work together. If a senior team member has a willingness to help others and a positive attitude, they may make an ideal candidate for a mentor.

It is possible that a senior developer may not be the right choice for a mentor. Perhaps there isn’t a senior developer available right now. Another problem may be that the veterans on your team may not have the personality/disposition to work well with green team members. Once a project technical lead complained to me that he couldn’t get anything done because the team he had been assigned was all inexperienced. After speaking with the team, I realized that one person he was referring to was actually more experienced than he was - he just didn't take the time to learn about his team. He clearly wasn’t the right choice for a mentoring (or technical lead) role.

Depending on the size and level of experience on your team, you may want to consider outside help. For example, if you have two or more untried team members who you think would benefit from mentoring, you might be able to hire a consultant to be available part-time to answer questions, provide direction, and perform quality checks like code reviews. Depending on the size of your group, what you are trying to accomplish, and the amount of time they might need to spend with your developers, the increase in productivity over the long term might be worth the initial investment. Successful mentoring should, over time, increase your team’s productivity by at least 20% within the first six months (and possibly more, if your team is very inexperienced.) This could give you a return on investment in the first year, and hopefully make it unnecessary for you to hire a new full-time permanent employee.

Can a manager also be a mentor? Generally, I recommend that managers do not also try to fill the role of mentor. First, since a manager can influence or set a developer’s salary, a developer (especially a less experienced one) may be less likely to ask a manager for help, wanting instead to prove that they can figure things out on their own. Also, in many cases a manager is too far removed from the technology to be helpful except in a more general way (“Did you look here for the answer?”)

Still, in some instances a manager can be a successful mentor to an inexperienced developer. You’ll need to evaluate for yourself if this make sense for your software team.

What should the mentor do?Here are some suggestions for making the most of the mentoring experience.

AvailabilityAvailability is very important. Good mentors make themselves available frequently and regularly, in order to encourage questions to come to them.

Encourage ExperimentationLess experienced developers need support and encouragement. Often they feel insecure and unsure of their contribution to the project. They should be encouraged to ask questions, guess, and experiment. Good mentors don’t complain or abuse junior developers when they try something that doesn’t work. (This does not mean that there are no expectations for junior developers – see the next section.)

Set guidelinesWhile you want your team to experiment and learn by doing, you also have projects to complete. So set guidelines for your developers about how long they can “wrestle” with a particular problem before they bring it to you for guidance. Depending on your particular deadlines and projects, this might be one hour or one day. This way, you won’t find your project seriously out of hours because a developer was “stuck” for a week on a particular problem.

Teach Them to FishThe old adage goes “Give a man a fish and he’ll eat for a day; teach him to fish and he’ll eat for a lifetime.” It is true that the best mentors don’t just answer a developer’s questions – they help them to answer their own questions. This is an approach I have been successful with:

When a developer comes to you with a technical problem:1) Ask, “What have you done so far to find the answer?”2) Suggest possible locations for the answer to the problem.3) Request that they research those areas, and report back the results (did they find an answer that worked, or are they still stuck?)4) Follow-up with the person yourself if they don’t come back to you within a reasonable amount of time.

Mentoring, not babysittingMentoring cannot solve all productivity problems. If your team is non-productive for other reasons, then no amount of mentoring will solve it. Take care to diagnose the correct problem. Just because your team is less experienced doesn’t mean that’s the primary problem. I’ve seen developers sit in a corner for 3 months, and produce nothing but one page of design documentation. When confronted, they’d argue that they didn’t have everything they needed, or that no one would answer their questions, or whatever.

Professional people do not need people standing over their shoulders making sure they aren’t playing solitaire all day long. No amount of mentoring is going MAKE a person do their job, and if they aren’t doing their job – get rid of them. They will cause you more problems in the long-term if they aren’t following through already.

Good candidates for mentoring have three essential qualities:1) A desire to learn2) An ability to adapt and change3) A professional attitude and manner

How many developers can one mentor help?Of course, this depends on many factors: the other responsibilities of the mentor, the amount of experience of the personnel he or she is mentoring, project factors, etc. However, typically a good mentor can assist no more than 2 or 3 junior developers at one time. Don’t expect that you can hire six people with no experience, and make them all productive in a few months, unless you also have two or three mentors to work with them.

An effective mentor for your software team can make your team more effective and productive.

Recently I was having trouble configuring a new virtual directory on a production server. The virtual directory would contain an ASP.NET application that worked on other computers. However, on this server the application would always provide a Windows log-in prompt, which never accepted any entries - even the admin for the machine!

I had changed all the NTFS permissions about a million times (providing, I'm sorry to say, tons of rights that should have been unnecessary), and still the site was inaccessible. I had also repeatedly checked the IIS directory security settings, but these appeared to be fine. Finally, I checked the web.config for the application, and noticed that there was no authorization section. I added the following section (allowing snonymous access), and everything was fine from there.<samp> <authorization> <allow users="?" /> </authorization></samp>I'm not sure why it is required in some situations and not in others, but if you are having trouble with security for a site that should allow anonymous access, give this a try!

Adding the right software developer to your team can improve productivity and help to make your project a success. Adding the wrong person is to certain to have the opposite effect – a drop in team efficiency and the possibility of making your project fail (or at a minimum, making it a miserable experience). So, finding the person who can best help your team work effectively and productively should be a top priority.

Here are some tips I have found helped me find talented software developers during the interviewing process.

#1: No TricksDo not ask trick questions in an attempt to confuse the candidate. This includes questions designed to identify “original thinkers” or people who “think outside the box”. Someone’s ability to answer a question like this doesn’t necessarily reflect his or her ability to write code. In fact, someone who can answer your “trick” question might fail miserably at the next one you ask. Also, keep in mind that the candidate is also interviewing you and your organization. Just as you are trying to determine if they will make a good fit for your company, they are also trying to figure out if they want to work for or with you. Asking irrelevant, tricky questions will not convince them your company is where they should be.

#2: Be considerateRead the applicant’s résumé before meeting with them. Reviewing it beforehand provides you with two benefits. First, you will have a picture of the candidate’s experience that you will then be able to probe in detail about. For example, a description of the candidate’s experience discusses an eCommerce application that was built; you can ask specific details about the project (i.e. number of development team members, number of users supported, role on the project, challenges encountered during development, etc.) Second, you’ll let the candidate know you cared enough about meeting with them that you took the time. If a company doesn’t bother preparing for a meeting with me, why would I want to work for them?

#3: Self-evaluation isn’t enoughDo not accept a candidate’s self-evaluation of their skills on a particular technology. Everyone uses different criteria for determining if they are a beginner or expert, and it is better to find out now what the person can really do than after you have hired them. I have seen this work both ways. I have interviewed candidates for development positions when they rated themselves highly for almost everything, but couldn’t answer basic questions about specific technologies or operating systems. One told me “I’ve been told ‘Jack of all trades, master of none’ but I don’t believe it. I am a master of all trades.” Yet when I asked him about what he could do that justified his “expert” rating on Windows 2000, he told me he could create user accounts (and declined to offer any further information). That’s it?! I’ve also interviewed candidates who felt that they were only beginners with SQL Server 2000. Yet, they could create a normalized database, create views and stored procedures, and create complex queries effortlessly. So ask probing questions to get more details.

#4: Communication is keyCommunication is an important component of any software development position. I’ve known several people who were hired because their technical skills were excellent, but they needed help with their communication skills. I disagree with hiring people on the basis on their technical skills, without looking at other important professional components. Software development teams work most effectively with developers who can (and do) communicate with each other. Even if you are hiring for a team of one developer, that individual will still need to communicate with users, project sponsors, or someone. In fact, I would argue that in many cases, technical skills can be learned and improved. While this is also true of communication skills, these are more intransient and difficult to change as time goes on.

How do you evaluate the communication skills of the candidate? First, I always give candidates an opportunity to ask me questions about the position. Candidates with good communication skills use this time to find out more specifics about the company, the team, the types of upcoming projects, and the kind of development work they might get to do if hired. Excellent candidates will demonstrate clearly that they have been paying attention to the rest of the interviewing process by asking questions about things they learned during the interview. (For example: “You mentioned that some of the projects here are not using .NET. Can you tell me more about which projects fall into that category, and why?”) Candidates without good communication skills will not ask any questions at all, or will ask simple, boilerplate questions.

#5: It’s about problem solvingProblem solving are important skills in all software development jobs. Every developer needs to have an approach for solving problems they have never encountered before. There are two ways you can evaluate the problem-solving skills of any candidate you interview. First, you should be prepared to ask questions about specific problems the candidate might reasonably encounter in the job.

For example, you might ask something like this: “A client-server application written last year has recently started behaving sluggishly. It uses a SQL Server database, and was written in Visual Basic 6. How would you resolve this problem?” Hopefully, they will be able to tell you several areas they might investigate (checking the indexes to make sure they are optimized, determining when the performance problems are occurring to see if there are blocking issues or problems due to other jobs executing at the same time, verifying if the joins are created in the most efficient manner, just to name a few things to check). I use questions like this to see how many different possibilities a candidate comes up with. I am usually wary of a candidate who can only provide one or two suggestions for a broad trouble-shooting question like this.

Another way you can evaluate the candidate’s problem solving skills is to ask them directly: “How do you solve problems?” or “What do you do when you get stuck on a technical problem?” Experienced developers have a variety of sources they can go to for answers. I have interviewed candidates who have answered this question by saying “I check MSDN for the answer.” Of course, checking MSDN is a perfectly reasonable approach, but it is hardly the only place where you can find answers to problems, and it certainly isn’t the most complete. Candidates who are the most experienced know that the public newsgroups and list servers also can provide answers to technical challenges. Seasoned developers also generally have their own network of colleagues they bounce ideas off of, or a few other favorite websites or books they use for resources on certain problems.

Remember – software development today is very broad and everyone gets stuck occasionally. The developers who are most successful are those who know where to find the answers to technical problems.

#6: Set standardsIf you have certain coding standards or approaches that you want the team to adhere to, make sure to ask questions about that philosophy to make sure that the candidate can work within your boundaries. For example, if the development standards for your team are to never use bound controls, then you should definitely ask the candidate if they typically use bound controls, and how they feel about the standard. First, this gives you an opportunity to express your standards and expectations up front. Also, it might give you an opportunity to learn something new, perhaps a different approach or something you hadn’t yet considered. Finally, it again gives you the opportunity to learn more about the candidate, and how they might fit in with your team.

Finding the right new developer for your team can make your group more successful and productive. Pay attention during the interviewing process, and you will end up with great new employee.