Agile's Dark Side
Being a self-proclaimed Agile Advocate I seem to find myself in discussions regard the bad points about agile. Books, articles, and talks on the subject of agile always paint the rosy happy story about using agile. I'm no fool, and I realize that things aren't quite as happy as some people make it out to be. No one said that agile was a silver bullet. The reason that I'm an advocate for it is because I believe it is simply a better way to write software. Let's get down to the meat of things. What is the "Dark" side of agile?
1)Increased Visibility can cause organization crisis. Agile, if nothing else, exposes all of the problems an organization has. If no one wants to take responsibility for these problems, then a crisis can (does)arise.
2)Lose of titles. What does it mean to be a "Senior QA Tester" on an agile team? Since everyone is responsible for getting the product done, titles/roles get blurred. Some people have definite problems with this. Especially when it comes time to do the yearly performance review.
3)People have to work together. Which, going back to item one, creates those pesky people issues. Normally you can avoid this on a traditional project by segregating opposed personalities. It isn't easy to do in an agile project.
4)Projects fail fast. This is a negative because in a traditional project, money from the budget usually keeps coming in because everything is "moving smoothly". But in an agile project more visibility may produce angry bean counters if the project goes directly into a dive. Again, there is no where to hide your dirty laundry on an agile type project.
5)Sustainable pace. We are used to slacking off at the beginning of a project and death marching the end. So most traditional projects see spikes in productivity. Agile projects push to establish a sustainable pace among the team. This means the developers are always busy and don't get a "break" from work. People are turned off by that (odd I know).
6)Feeling of micro-management. Agile promotes increased visibility. How do you get increased visibility? Your workers update their statuses in a daily manner. This can cause a definite feeling of micro management amongst the team.
7)Less up front design. Architects are perhaps the most difficult types of people to convince to use agile. This makes sense because these people are the ones who try and minimize risk from a technical aspect. Having a methodology that says, just do the minimum that is needed, to them is risky and goes against everything they have been trained on. I think it is important to remember that agile doesn't mean no design, just no unneeded design.
8)Flawed implementation of agile. If you rush, don't plan, are unsupported, and don't get team commitment you are likely to leave the organization with a mess on it's hands. The organization is likely to stay away from anything agile after getting such a bad taste in it's mouth.
9)Physical reorganization costs. A team is likely to want to remove the cubes and create a team room. Or at the very least reorganize their cubes in order to be closer to each other. There is a cost associated with doing this. Same is true for when the team demands newer hardware to do development. I'm all for new hardware, just realize that again, this is a cost that isn't obvious to an adoption of agile.
10)Loss of privacy. Well, no one said you had privacy at work anyway. But when you implement agile, this loss becomes a bit more apparent. Team rooms, pair programming, these things all attribute to some loss of privacy. Have to make a personal call? Before you may have sat in your cube. Now with agile you might have to go outside the office to have it be personal. Want to check your personal email? That is harder when your workstation is in the middle of the team room.
Change is hard, take time and do things the right way and make sure everyone understands what is happening. Remember that these problems listed above are not show-stoppers. With good leadership and good people they can all be moved out of the way. But I don't want you to go into this with your eyes closed. Know that there is a large possibility that you will see some of these dark sides. Be prepared and don't give up.
Posted at 03:38PM Sep 18, 2006 by Aaron in Agile | Comments[9]
Benefits of Pair Programming
This post is in response to a blog entry at beyondng.com entitled "How much pair programming is cost justified".
Well, if we assume the perfect development environment with all top-notch developers, then yes, I agree Pair Programming probably has a low ROI.
For the rest of the world though, the following benefits to me show a ROI in short and long term. The benefits are:
1)Two pairs of eyes on the code. Yes, I understand that a pair of terrible coders will still produce terrible code. This also isn't an excuse to not do code reviews with the team. To me team code reviews should be coarse grain dealing more with design/functionality than syntax details. This is where the extra eyes on the code comes in handy.
2)Increases involvement. That is, as a single programmer, there are times where you are either way off task or just plain stumped. By having your pair with you it is more difficult to go surf to digg or slashdot. Thus your personal daily involvement with doing work increases.
3)Rapid learning. Pairing should allow a more open communication between people of different skill levels. Because of the increased involvement each person is more acceptable to learning new things. When the mind is focused and engaged learning is much quicker.
4)Higher actual time vs ideal time. A single coders actual coding time per day is not eight hours. It is more along the lines of 2-4 per day. This is due to the numerous other tasks that we handle along with whatever meetings we attend. By pairing up, each of the coders are committing to a chunk of time to work. I find it harder to interrupt two people working hard on a problem than a single person. Thus the actual time doing productive work goes up when pairing.
I'll finish up with stating that pairing is NOT for everyone. It isn't that they don't see the benefits; it is that they just don't like doing it. To me this is fine. In no way should it ever be forced upon a team. I would much rather a full team try it out and buy into it than have one person shove this technique down the team's throat. However....I also think that everyone should give it at least a couple of weeks when trying it out. One day or a couple hours isn't enough for a test run.
Posted at 09:22AM Aug 23, 2006 by Aaron in Agile |
Agile 2006 Conference Day 1
After leaving Des Moines at 8:00am I arrived at the Hyatt Hotel in Minneapolis for the Agile 2006 Conference. The afternoon session that I attended was the "Intro to Agile Session". I am currently trying to introduce agile into a company and thought it would be interesting to see how someone else presents it. I got a few new tips from the presenter, Hebert Smits, and might write about them after the conference is over.
In the evening was an "Ice Breaker" event at the hotel ballroom. I was privledged enough to meet Jeff Sutherland, one of the creators of SCRUM. We had an interesting discussion regarding a paper he had submitted to the conference.
I also met Jim Highsmith, signer of the Agile Manifesto and James Shore who is showing off his new project Card Meeting. He was gracious enough to give me a sneak peak at it and I think it is pretty nifty. Kind of an XP collaboration tool for distributed teams.
That is all for Day Number One. Off to bed to get ready for a fully day tomorrow.
Posted at 09:23PM Jul 23, 2006 by Aaron in Agile |
Agile 2006 Coverage
I'll be headed to Minneapolis on Sunday to attent the Agile 2006 Conference. Stay tuned to the blog as I plan to be agressively posting to cover what is going on each day during the event.
Posted at 12:29PM Jul 21, 2006 by Aaron in Agile |
Happy Independence Day USA
Just wanted to say yeah for fireworks and grilling! I'll be on the lake all day grilling, swimming, and boating. Hope everyone enjoys themselves today.
And for those not in the USA, hope you have a great day at work.
Posted at 08:41AM Jul 04, 2006 by Aaron in General |
Career Paths for Coders
Something has been bothering me lately. You could say that it is another reason I'm Curmudgeon. Once a coder hits a certain point, say senior level, in his career he will plateau. There are only a few ways to continue moving up on the career ladder.
- Start your own business
This isn't for the non-risk takers out there. Basically it is assumed that after five to ten years of experience in the field, you can start your own business. It can either be consulting out to other companies or maybe you have a great idea you've always wanted to make. Either way, you can continue on your career path by starting your own business. Be warned though that you will need to know how to run a business and thus may still need that MBA. Which leads us to our next option. - Become a manager
I think that this is the most common path that senior level coders take. Either by going back to school and getting an MBA, or by simply being "promoted". Companies seem to think that the low level code is beneath the senior coders so we need to manage instead. There is a small problem here. That problem lies in the fact that great coders don't always make great managers. Heck, I doubt that they even make good managers. Yet companies still force us into this role with little to no training and then wonder why a great coder failed as a manager. Go figure. - Become a teacher
The third option for continuing with your career is to go back to the academic world and teach. You will still be able to do research on "cool" things, but your pay will most definitely drop. If you aren't coding for the money, then this may be an attractive option. Personally I find mentoring a very rewarding experience and given the opportunity would love to teach some classes. Another way to teach is by writing books and going on tour with a conference such as No Fluff Just Stuff. This might not be as fulfilling to you as teaching a class full time, but I would wager the money may be better.
I know that our profession as a whole is very young, but are these really the only options that I have? If I want to be a professional coder for 30+ years what more can I look forward to? Maybe we need to rethink the current standard of what it means to be a "senior" developer. Many people that I interview seem to have really just one year of experience repeated five times.
This is what I propose. In order to have a year of experience it must be in doing something you have never done before. My definition of experience is "things learned from failure". Thus you need to do something new and fail in order to really have experience with it. So working ten years with the same company might only net you three years of "experience". This would push the salaries up for people who really are senior level, and perhaps make companies rethink forcing great coders into that management position.
What do you think? Do we have any other options besides these three?
Posted at 08:57AM Jun 30, 2006 by Aaron in Java | Comments[17]
Five Reasons I am a Curmudgeon Coder
These are my top five reasons for being the curmudgeon old coder that I am.
- Unnecessary Meetings i.e. Sink Holes of Evil
Enough said. And how to fix them? Try this
- Coding is becoming simpler
Yup, this is the "Back in my day.." reason, but with a twist. We are abstracting coding up higher and higher. Closing connections? Blah, don't worry, the framework will handle it. Memory allocation? Its okay, the garbage collection will handle it. Now don't get me wrong. I do appreciate the fact that because the abstractions are moving higher, I am left with more time to solve business problems. However, therein lies my problem. See, if I don't have to be an expert with bits and bytes and shifting, you know, that low level stuff; then that new grad from college doesn't need to worry about it either. And guess what? He's going to be cheaper than I am so who is going to get the position? I think we are abstracting ourselves out of a job. If ANYONE can program, then EVERYONE will.The second problem with going higher and higher with abstractions is that, well, sometimes they leak. If your abstraction leaks and something breaks, will you be prepared to fix the problem? For example, Hibernate is an abstraction for mapping a database table row to an object. Is there anyone out there who has NOT pulled their hair out because of a leaky Hibernate abstraction? Its okay to admit it, really it is. Millions of people admit it everyday on IRC, message boards and newsgroups. The abstraction leaked and now you are stuck with a problem that is over your head. So yeah, coding is becoming easier and we are creating abstraction zombies as the next generation of coders. Bleh.
- XML
Repeat after me, XML is not a programming language. Say it again a couple times. Feels good doesn't it? I have to admit that I was an XML groupie for a bit. XML was supposed to save us all. Every bit of data in the world was supposed to be wrapped in XML goodness and be shareable between businesses. It was a great happy plan. And then something terrible happened. Developers got a hold of XML. We ruined it, at least for me we did. The thing that ruined it...ANT. ANT and I have a love/hate relationship. I do really like ANT but sometimes, a build just needs to be scripted. You know, things like conditionals and loops? XML is NOT a very willing friend when it comes to scripting. ANT and I, we want a good relationship, really we do. But XML just keeps getting in the way. Oh, and while I'm discussing XML, why oh why does EVERY SINGLE PROPERTIES FILE NEED TO BE IN XML?!?!?! Sorry, I feel better now. Onto number four.
- The coders aren't in charge anymore
Since when did management become experts in how to create software? It used to be that the business would have a problem and want us to make software to solve their problem. We would work with them and create the appropriate solution. Everyone was happy, we got to do things our way, and business got software to make their jobs easier. Somewhere along the line management felt they needed to step in. "You need to understand, business people can't understand you, and you don't know business". This was their excuse...I think it is BS. So now we have business people who no longer trust us to make what they want. We have management who dictates the who/why/when/where/how of us building the software. And we have been reduced to...well, code monkeys?To those of you who are working in an environment where this is not the case. I applaud you and would just like to say that I am jealous of you. The best I can seem to manage are some guerrilla tactics followed by a campaign of "shock and awe". This is also the appropriate to mention that I believe Agile methodologies will become our answer to building trust again with the business. But until it becomes more mainstream we are going to continue to get beat up at the workplace.
- Fixing the effect of a defect, not the cause of a defect
This last reason is becoming more of a trend and I think it relates up to reason number three. Our army of abstraction experts are developing a knack for applying band-aids to defects. Let's use Hibernate again for our example. Session closed errors are a big thorn in developers sides. What is the correct way to fix these problems? Well, there isn't a "one size fits all" fix. Instead, you might actually have to dig into the code. Message boards and newsgroups are a great source of information, but the debugger is your friend. Learn it, use it, become intimate with it. Please please please do not cut and paste solution X from a message board into your code base. Please? With sugar on top? Use the debugger, find the CAUSE of the problem and fix it.
What reasons do you have to be a Curmudgeon Coder? Feel free to share in the comments below.
Posted at 09:58AM Jun 28, 2006 by Aaron in General | Comments[8]
How to Succeed at Outsourcing
Outsourcing is becoming a very popular trend at large and medium sized companies. Who can really blame them though? The thought of having the same work done for less cost is very attractive. Less cost means more profit, which means bigger dividends for the shareholders. At least...that is the idea.
I've been on three different projects with four different outsourcing companies. On each project at the end MANAGEMENT deemed the project a success while EMPLOYEES saw it as a failure. Management's main criteria for success was the line item balance sheet. If that showed a bigger revenue than loss, success! The employees viewed success in a different way. They looked at the quality of the product, because ultimately, THEY were responsible for it.
And thus this leads to the body of this entry, how to make it so both management and the employees are happy with outsourcing a coding project.
The first step in success is to tighten up every single feedback loop your company has. If you are having weekly meetings make them bi-weekly. If management only meets once a month, make it bi-monthly. If the feedback loops in the project become smaller and more efficient, any problems will show up sooner than later. This should in effect make the communication across all boundaries of the project become stronger. And in my opinion, communication is the number one thing to make or break an outsourced project. Another very important feedback loop to tighten up are the code reviews.
Which leads us to step number two. Make it clear between the on-site team and the offshore team where the final authority in code quality. Code reviews are a necessity for a successful outsourcing projects. The employees need to be involved and see the code that is going into the project which they will have to maintain. This is where the code review comes into play. It should be made clear that the employees have the final word on accepting code into the source control system, and that the code will be reviewed.
Ah yes, step three is have excellent source control management. Development is going to be happening 24 hours of the day. So when one team sleeps, the other codes, and visa versa. If your source code control system (you do have one right?) is not managed properly, it will cause some very unexpected problems. Make sure all your branching, versioning, merging procedures are in place and well documented.
Step four is...documentation. Remember step one when I talked about communication? One part of communication is the written part, or documentation. Everything needs to be documented BEFORE you start a project. Not during, not after, before. You are hiring a whole team, department, company to do your work. If you don't provide precise direction as to how you want things to work, then it won't be as you want it. The unfortunate truth is that an outsourced project needs MORE documentation than an in-house one. Teams that are overshore tend not to call you at 4am to ask simple questions and instead make a decision for themselves. Thus, document every single thing.
Step five, commitment to steps 1 - 4. Everyone in the company needs to be onboard with doing the outsourcing thing. If only one developer is doing code reviews, that person will not catch everything. Management must recognize the time needed to do documentation and be willing to let the employees create the necessary docs.
Step six find the right outsourcing company. There are many many outsourcing companies in this world. Your company needs to do the due diligence and select the right one. In the end, the people will make the difference. For example, one outsourcing company was being used as a jumping point for junior developers. They would hire a "developer" who had taken a single class in Java. Then put that person to work on our project. The on-site team would then basically have to train this person how to code by continually rejecting that person's work. Admittedly, the person would in the end become better, but then they would leave for a hiring paying company. Thus, starting the cycle all over again. If a bit of scrutiny was done before hand by my company, it would have saved us quite a lot of time.
Step seven your on-site team must be able to talk directly with the outsource team. Outsourcing companies seem to want to protect their developers. This will lead to questions being filtered through one person and a stone wall erected between the developer teams. Remember step one? The teams need to be able to talk and discuss issues that may arise. Tunnelling all communication through one person creates an obvious bottleneck. Make sure that this is agreed upon before starting and that the channels are fully open. Publishing an e-mail list is one excellent way to acheive this. If the outsourcing company refuses this..refer to step six.
I'll stop with these seven steps. With any change comes pain, and outsourcing for the first time is a huge change. I hope that with these seven guidelines that everyone in your company can honestly say that it was worth outsourcing that project.
Posted at 02:37AM Jun 26, 2006 by Aaron in General | Comments[6]
Prime Number Fun
Today we shall visit the subject of prime numbers. Yup, Math.
So first the definition of a prime number is a number such that it is only evenly divisable by itself and 1. But you already knew that right?
To test if the number n is prime, you can use the following algorithm which takes use of the modulus operator:
for (int i=2; i < n; i++){
if (n%i==0){ return false; }
}
return true;Alas, we have to loop through every single number up to n-1 starting at 2, so it will be n-2 iterations. We can do a little bit of work and make this a bit better. First of all, if a number is divisible by another number, say x, then there will be one more number, say y, that it is also divisable. Such that n/x = y and n/y = x. There is a kind of reflection that happens along the number line. It can be observed that this reflection's pivot is at the sqare root of n. So our first improvement would only be to iterate up to the sqrt(n). Secondly, if the number is odd, we can safely start at 3 and jump up every two numbers from there. So only check 3, 5, 7, etc... This will also reduce the number of iterations that are necessary.
Okay, so here is our enhanced algorithm. Note I make no claims on if it performs better than the other as I haven't benchmarked it. I can only show that the number of iterations will be less.
public boolean isPrime (int n){
if (n<=1) return false;
if (n==2) return true;
if (n%2==0) return false;
int m=Math.sqrt(n);
for (int i=3; i<=m; i+=2){
if (n%i==0){
return false;}
}
return true;}Now then, what if we want to examine a set of numbers and pull out all the primes in a set? Well, one way to do that would be to loop through each number and determine if it is prime or not. That algorithm is below:public int[] findPrimes(int set[]){
int[] returnInts = new int [set.size];
int index = 0;
for(int x = 0; x <= set.size; x++){
if(isPrime(set[x]))
{returnInts[index++] = set[x];}
}
return returnInts;}Unfortunately that means we have to loop first through the set, and then loop from 3 to qrt(n) on each of the numbers in the set. That is a lot of looping. Insead we can use what is knows as The Sieve of Eratosthenes.
See the wikipeda entry for how it works exactly, but basically, we start with the set and remove all numbers which are a multiple of 2 (but not 2, since 2 is prime). Then remove all numbers which are a multiple of 3, then of 4, etc up to the square root of the largest value in the set. Below is the algorithm for this.
// n here is the largest value in the set and we are assuming all the numbers from 1 to n. But we can easily modify this // to be operated on a given set. This algorithm returns an array of booleans which represent if the number is prime or not.
public boolean[] sieve(int n){
boolean[] prime=new boolean[n+1];
Arrays.fill(prime,true);
prime[0]=false;
prime[1]=false;
int m=Math.sqrt(n);
for (int i=2; i<=m; i++)
if (prime[i])
for (int k=i*i; k<=n; k+=i)
prime[k]=false;
return prime;}
Posted at 11:22PM Jun 25, 2006 by Aaron in General |
How to Reverse a String
As stated in the How to Interview a Java Programmer post one question that you can ask which doesn't require a computer to answer is "Write a reverseString method". I asked this question to my co-workers and got quite a few different responses. Then another co-worker put the responses together and benchmarked them. Below is the results.
Kevin responded with how to reverse a String in Ruby:
"Hello World".reverse
"Hello World".split(//).reverse.to_s
reversed = []
"Hello World".split(//).each{|c| reversed.insert(0,c)}
reversed.to_s
My initial approaches are below:
String s = "Hello World";
________________________________________________________
String returnS;
for (int i = s.length() - 1; i >= 0; i--) {
returnS += s.substring(i, 1);
}
return returnS;
_____________________________________________________
StringBuffer buffer = new StringBuffer(s.length());
for (int i = s.length() - 1; i >= 0; i--) {
buffer.append(s.substring(i, 1));
}
return buffer.toString();
_______________________________________________________
StringBuffer buffer = new StringBuffer(s);
buffer.reverse();
return buffer.toString();
______________________________________________________________
StringCharacterIterator iterator = new StringCharacterIterator(s);
char[] chars = new char[s.length()];
int i = 0;
for(char c = iter.last(); c != CharacterIterator.DONE; c = iter.previous()) {
chars[i++] = c;
}
return new String(chars);
______________________________________________________________
int length = s.length(), last = length - 1;
char[] chars = s.toCharArray();
for ( int i = 0; i < length/2; i++ ) {
char c = chars[i];
chars[i] = chars[last - i];
chars[last - i] = c;
}
return new String(chars);
Tim had another variant of the array based approach:
String s = "Hello World";
int length = s.length();
char[] chars = new char[length];
for (int i = 0; i < length; i++){
chars[length - i] = s.charAt(i);
}
return new String(chars);
Josh responded with a interesting file based approach:
CharArrayWriter caw = new CharArrayWriter(s.length());And Eric showed how to use the Apache StringUtils and ArrayUtils:
for(int i = s.length()-1; i >=0; i--){
caw.write((int)s.charAt(i));
}
char[] letters = caw.toCharArray();
DataOutputStream dos = new DataOutputStream(new FileOutputStream(new File("helloWorld")));
try{
for(int i = 0; i < letters.length; i++){
dos.write((int)letters[i]);
}
}
catch(Exception ex){
// if this failed, we can't read it back
throw new EndOfTheUniverseException();
}
finally{
dos.close();
}
DataInputStream dis = new DataInputStream(new FileInputStream(new File("helloWorld")));
caw = new CharArrayWriter();
try{
caw.write((int)dis.readChar());
}
catch(Exception ex){/* looks like we're done */}
finally{ dis.close(); }
String returnS = new String(caw.toCharArray());
return returnS;
return StringUtils.reverse(s);
________________________________________________
char[] chars = s.toCharArray();
ArrayUtils.reverse(chars);
return new String(chars);
Last but not least here is the benchmarks from 2 Strings and the code to exercise the methods:
import static java.lang.System.currentTimeMillis;
import static java.lang.System.out;import java.lang.reflect.Method;
import java.text.CharacterIterator;
import java.text.StringCharacterIterator;
import org.apache.commons.lang.ArrayUtils;
import org.apache.commons.lang.StringUtils;
public class ReverseStringTest {
public static final void main(String... args) throws Exception {
new ReverseStringTest().runTest();
}
private void runTest() throws Exception {
String s = "Hello World, what would you like to do this fine evening?";
for(int i = 1; i < 10; i++) {
Method method = getClass().getMethod("method"+i, new Class[] {String.class});
out.println("method to be ran = " + method + "with output = " + method.invoke(this, new Object[] {s}));
long begin = currentTimeMillis();
for(int j = 0; j < 1000000; j++) {
method.invoke(this, new Object[] {s});
}
long end = currentTimeMillis();
out.println("time taken to run = " + (end - begin) + " milliseconds");
} }
public final String method1(String s) {
String returnS = "";
for (int i = s.length() - 1; i >= 0; i--) {
returnS += s.substring(i, i + 1);
}
return returnS;}
public final String method2(String s) {
StringBuffer buffer = new StringBuffer(s.length());
for (int i = s.length() - 1; i >= 0; i--) {
buffer.append(s.substring(i, i + 1));
}
return buffer.toString();}
public final String method3(String s) {
StringBuffer buffer = new StringBuffer(s);
buffer.reverse();
return buffer.toString();}
public final String method4(String s) {
StringCharacterIterator iterator = new StringCharacterIterator(s);
char[] chars = new char[s.length()];
int i = 0;
for(char c = iterator.last(); c != CharacterIterator.DONE; c = iterator.previous()) {
chars[i++] = c;
}
return new String(chars);}
public final String method5(String s) {
int length = s.length(), last = length - 1;
char[] chars = s.toCharArray();
for ( int i = 0; i < length/2; i++ ) {
char c = chars[i];
chars[i] = chars[last - i];
chars[last - i] = c;}
return new String(chars);}
public final String method6(String s) {
return new StringBuilder(s).reverse().toString();}
public final String method7(String s) {
StringBuilder buffer = new StringBuilder(s.length());
for (int i = s.length() - 1; i >= 0; i--) {
buffer.append(s.substring(i, i + 1));}
return buffer.toString();}
public final String method8(String s) {
return StringUtils.reverse(s);}
public final String method9(String s) {
char[] chars = s.toCharArray();
ArrayUtils.reverse(chars);
return new String(chars);}}
Posted at 10:21PM Jun 25, 2006 by Aaron in Java |
How to Interview Java Coders Soft Skills
In the first part of this I discussed the technical interview. After the technical interview, we like to examine the candidate's "soft" skills.
Some of you might argue that since the candidate passed the technical part, there are no more questions needed. I disagree with this. In our profession we are not sitting in a room alone with no human contact. Daily we interact with our team, management, and the stakeholders. If our people skills are not up to par with our technical skills, then the performance as a whole will suffer.
One important distinction between the technical and the soft skill interview is that the interviewee drives the technical while the candidate drives the soft skill. So you should find yourself doing much more listening in the soft skill interview than in the technical. This is the time that you want the candidate to be talking, and hopefully making sense.
The question I start with for every soft skill interview is "Tell me about your current project and role in that project". Now sit back, relax, and let the candidate talk. Some things to look for:
1) Does the candidate feel comfortable talking to you?
2) Do you get a sense of excitement or ownership from the candidate?
3) Imagine the candidate talking about your project, is this how you would want it portrayed?
Once the candidate is finished describing the project the interview can go in many directions. Here are some ideas of where to go next. As you do more soft interviews, you will start to get a better feel of what to ask next.
- What was your biggest success during your career?
- Describe the hardest bug you have tracked down and how you fixed it.
- If you could change something on your current team, what would it be and why?
- Tell me about your ideal work environment
After the candidate is finished there are two things left to do. First is give the candidate an opportunity to ask questions to you. Try to answer these as truthfully as you can, lying to the candidate will come back at you if you hire the person.
The last thing to do is to give the candidate a sales pitch about your company. Developers talk amongst themselves. So take this time and sell your company to the person. Maybe you won't hire the candidate, but your chances to have your name mentioned has now increased.
Posted at 09:56PM Jun 21, 2006 by Aaron in Java | Comments[1]
How-to Interview Java Coders
Interviewing to me is definitely a trained skill that you have to practice with. Your goal is to extract as much information from the candidate so that you can make a useful recommendation. If you get too little information then your recommendation will contain more of a risk.
Each candidate that is interviewed is a different person and thus each interview is slightly different. For example: A candidate directly out of college will be asked different questions then a person with 10 years in the industry.
Regardless of the person, if they are wanting work as a professional programmer then they need to know a few of the basics. For the most part, it comes down to communication. When you interact with other programmers you have a basic vocabulary that is used. If the candidate doesn't have that vocabulary, then communication between the candidate and the other developers will be hindered.
I also am a strong believer that if you are going to work in the industry, you should at least have a basic understand of the underlying workings of a computer. Thus my questions are more general, yet still technical.
So this is my personal interviewing technique. One thing to note is that I try very hard to not ask trivia questions. These questions are things like "What does transient mean?". Guess what, I can look it up if I need it. I'm much more interested in if the candidate has a good solid base to grow with.
The first thing I hit on is what is a bit and a byte. From there I ask the primative types in Java and their sizes. The sizes question shouldn't be difficult if the candidate understands basic memory storage. Simply start with byte and work your way up, increasing the power of two each time.
Directly following this is a discussion about Data Structures. Remember your old friends (Map,Set,List,Array,Tree,Graph,Stack,Queue)? Hopefully you can name a couple of these, explain what makes each of them special, and have an example of when to use them. Oh, and a good side discussion regarding the equals() and hashcode() methods is good here as well.
Next is basic OO terminology. This is that vocabulary I discussed above. Polymorphism, encapsulation, interface, inheritance, overloading, overriding, pass by referrence, object, class, abstract class. If you don't know these then how can you a)communicate with your co-workers and b)create object-oriented software?
After OO I look at the resume and determine if they have database experience and if they are comfortable answering database questions. If yes then I would discuss primary keys, relationships, common database problems, and joins.
To round off the technical portion of the interview I discuss software designing. Things like coupling, cohesion, design patterns, tiered architecture. Usually I also go through a modelling question as well to see what types of behavior and attributes the candidate can come up with. The modelling question has been an item of hot debate with the team and we have yet to find a question that we are happy with.
My final technical interviewing requirement is asking the candidate to code. What? Code at an interview for a job that requires coding? That's crazy! The sad fact is that I have never been asked to code at any interview I've gone through. Would you hire a knife throwing juggler without seeing him or her juggle? NO! So why do we allow people to code without seeing them, well, code?
It doesn't take long to come up with some sort of coding exercise that can be written on the board or a piece of paper. Yikes! No IDE for help? Well, yeah, see the idea is that the exercise shouldn't really need an IDE. It should be simple enough to finish in 5 min, yet hard enough to get some sort of information from it. Currently the "Write a function to reverse a string" question has been working well.
If the candidate passes the technical portion of the interview, then it is onto Step 2, the soft skills interview.
Posted at 11:50PM Jun 20, 2006 by Aaron in Java | Comments[19]
Showing compiled JSPs in WSAD
Today I figured out how to go view the precompiled JSPs in WSAD. This always bugged me that I couldn't see what gets generated. I know that with frameworks and stuff this is "magic" but I want to see the spell behind the magic darnit.
Anyway, without further ado, here is the incantation. Open up the ibm-web-ext.xmi file. In there add these two tags as child elements of <webappext>
<jspAttributes xmi:id="JSPAttribute_1" name="keepgenerated" value="true">
<jspAttributes xmi:id="JSPAttribute_2" name="scratchdir" value="C:\jsptemp">
Make sure that the folder specified already exisits on your file system. Restart your server and you should now see the .java and .class files in your scratchdir.
Posted at 11:06PM Jun 20, 2006 by Aaron in Java |
The Build Diagram
This is my favorite graphical representation of what a complete build is and what it should do. The graphic is from www.sdtimes.com.
Posted at 11:02PM Jun 20, 2006 by Aaron in General |