I would not argue with you on the achievements described in resumes of potential candidates. However, it is certainly a fact that candidates who are excited about giving a bunch of floating bits some structure have a very big drawvack. They would not be always comfortable following instructions from their boss. When hiring such personnel, one must be careful that off them, there are a certain few who are not in it for a job....they are in the market for a career. They are good...and have an inbuilt thirst to keep climbing higher.

I think your point about the joy of development is a good one. At the same time, after several years working with a number of frameworks, I can say that I wouldn't want to work on a 'ground-up' project without a very compelling reason. There are so many "already solved problems", and I'd like to spend my time tackling the fun, interesting and occasionally novel problems that occur on new projects. Solving those problems cleanly often takes time and mental bandwidth -- starting "from scratch" means that a large percentage of your time will be spent building template heavy-lifting code that's been done a million times before.

Jeff, I totally agree. Doing good research into tools and frameworks, and using the right tools from other sources, is EXTREMELY important. Just because someone can build from scratch, does not mean that they should do it if they don't have to. And, a person who is good at doing research into "already solved problems" is very valuable to the team. Still, I stand by my observation that if a developer is good, you will find that they have at some time been compelled to build something by themselves. Statistically, it's true. It's an even better, extra positive sign if you investigate this individual project, and find that they did good research and thought about the right tools, libraries, and frameworks. The key interview question when you get to that point is "What would you do differently if you did it again?". If they respond coherently to that question, it's a very positive indicator.

While I agree, I think you have to approach this with caution. The best part of a developer who frequently builds apps from the ground up, is that they are very good at finding/fixing problems. In getting an application built, there are always hundreds of little things that go wrong before you get a smooth build process going. One who has suffered through that alot will be good at keeping things going. The other major benefit is, these developers will tend to have a higher level of motivation. It takes a lot of motivation to get a project off the ground. The ones who can set their egos aside can be great mentors for junior developers. However, there can be a dark side. Many will prefer to reinvent the wheel rather than use library code. Often they will suffer from NIH syndrome and treat maintaining other's apps with disdain. All in all, you just have to get questions around both sides to see if a candidate will work out.

It depends of developer level and technology where he will need to develop a project from the ground. From my experience with rails, I can tell than I will never participate in developing a rails project from the beginning. I started about 5 or more rails projects and such kind of things are boring to me now, I prefer to let other developers that are new to technology to do this and I could tell them how to do it better. Other case is with new technology that I know a little or nothing about it. It is interesting to me and I will participate with pleasure.

I agree with Jeff and sympathize with the developer you rejected. There are two kinds of aesthetic pleasure you can get from programming: the elegance of construction and the elegance and quality of the final result. For the first, build-from-scratch is by far the most satisfying approach. For the second, build-from-scratch is just torture. When I provide software to users, I'm always thinking about all the little touches that would make their lives easier, but which I didn't have time to implement. Automatic updates. Better autocomplete. A better widget for finding the right code to enter in a certain field, out of the 15,000 valid codes. Good performance when displaying a dataset that doesn't fit in memory. Ability to export data to a legacy app that has that one capability that will still be needed occasionally for the next year or so. Better usability so they can use the program without it requiring too much of their attention. These are the things that keep me up at night, which is why, in the context of my current work, I would say exactly what your interview candidate said.

I fully agree with Andy Singleton. An ability to think through hundreds and hundreds of scenarios/possibilities is not something for the faint-hearted. And having said that, as he responded to others, learning from others' experience is also valuable, then he/she also becomes an asset when he's flexible to work as a part of team as well.

Also, I think sometimes we (programmers) need to get away from the conventional thought process such as data validation...
it really depends on the nature of app... ok, this is like rambling, stop right here :)

That is what I learn at my studies. Building a project from scratch. Doing requirements analysis, project planning etc. If you can't do that you're not a developer.

I love building things from scratch - if I was an employer, I'd only hire people who have a passion for their job. There are so many good, intelligent coders out there that are just waiting to be snatched up by someone who will make good use of them. Building your own app from scratch and learning code discipline on your feet is great fun, our first site using the cms/framework that I built should be launching next week sometime and I'm really excited :)

Please define "from scratch". I have built many custom PHP apps for various clients, usually because they needed some goofy solution and I couldn't find anything preexisting to do what they needed. However, I almost always make use of a few preexisting classes. Would this still count as "from scratch"? In my experience, sometimes a coder who is unfamiliar with classes will hack together a solution of their own. However, a 10-second search could have saved hours of development time, and hundreds or thousands of dollars for the client. Not exactly a good thing if you ask me.

First of all, interest in the field waxes and wanes. I've seen it in myself, and in coworkers. I've known people who were at one time building great software on their own, but since then no longer even use a computer at home, and just see their job as a 9-5 necessary evil. Then there's the young'ns with the attitude "I can't believe I get paid to play with my toys. Kewl." A friend of mine once joked, "it's our job to write the software. It's the users' job to like it." I think that sums it up. Interest in the field, yes; user satisfaction, no. It seems to me that a good software developer has a healthy balance of all 3 of these motivations: * interest in the field * customer satisfaction * job security Your post is just about the first one.

awh has expanded the topic with great merit. I would think * interest in the field * is about WHAT; * customer satisfaction * is For WHOM and * job security * is probably about WHY or MOTIVATION.

Btw, does anyone have some idea/thoughts/techniques on convincing/selling something intangle (benefits not immediate) to target customers? Thanks.

I think I have been misinterpreted. My point is that if you are interviewing a new developer, this is a very good INDICATOR of skill. A good developer will almost always have built an app on his own. A poor developer rarely does this. I did not say that it is a good idea to build from scratch if you don't have to. The "build from scratch" somewhere in the past is a great indicator of talent. It's usually not the right recommendation for the next project. I also did NOT want to say that "build from scratch" means that you don't start with as much existing tools and libraries as you can. My definition of build from scratch is that you did not start with a pre-existing application. You thought it up yourself. However, you should do a lot of research into available tools before starting this project, and use existing frameworks wherever possible. If you don't do that, if you want to waste time building from scratch, rather than get to the new parts of the app, then I don't want to work with you. I want to get to the value-added part as quickly as possible.

I guess your last post should clear some misinterpretations regarding this post. This topic is very 'common sense', but is often neglected. It should always be considered when hiring developers.

It shouldn't be misunderstood. Let me use an analog of the consideration (not ability in this case) of 30 bucks for 100 apples. Does that mean I'm going to spend 90 bucks in my pocket to buy 300 apples now or tomorrow for that matter? No unless of course some one just told me in secret each apple is going to be worth a million very soon :)

Re: Don's prior comment; selling intangible benefits Whenever I am selling to a client I am either a) going to save them money or b) going to help them earn more money. What sort of intagible benefit are we talking about?

yes totally agree with Andy Singleton.But i think building from scratch practically may not happen in projects and it should be part of the developer's personal project to achieve the same.

Thanks
Prashant Jalasutram

To zaphod, on your
"a) going to save them money or b) going to help them earn more money.". I agree on its validity for the business environment, however, they probably won't be applicable to some other demographics, say, the college crowd, and let's use facebook as a case.

Regards

Don: what sort of intangible benefits are we talking about? To use the Facebook example, perhaps you are making the case for using a complicated "best practices", whereas the student feels a simpler solution is good enough. In a case like this, I might argue that using best practices will require more work now, but save untold hours of work later, when the Facebook API is altered to include new features. If the issue is security, I would simply link the troublemaker to the latest security exploit, MySQL injection, or MySpace glitch, and then remind them that not only will these security breaches cost time and effort to repair, they will also undermine the faith and credibility of your system.

This makes me think of a number of things. First off, hiring programmers is a tricky business as so many things are involved. When I have had to do this task I always rely on things that are not specifically about programming. I like to present one or two puzzles to see how the canidate reacts. I always give them the option of taking the puzzles home. This is to see if they have "follow through". If they can take the puzzles home and email me with an answer then I have a reasonable example of their ability to follow through. I also use the puzzles as an indicator of creative thinking. One of the candidates I interviewed and subsequently hired took the puzzle one step further than I had imagined it could be taken. This really got my attention. I also give extra points for those who have the gumption to try the solution while at the interview. I leave the candidate alone for ten minutes and check in with them after that time. If they need more time I give it to them. This process lets me guage if the person is a so called "go - getter". Beyond that I rely on the standard interview questions. During that time I'm looking for attitude, cooperation, team compatibility, etc.
Secondly, as to whether someone can build an app from scrtach or not. If a candidate can't do that they can't begin to do what is required in all the other areas of software development. That being said, the idea of truly building from scratch is ridiculous. You better be pulling from all available libraries and if you don't know what patterns are you haven't been paying attention to the ground swell of intellectual insight that has been coming at us for the past five or more years. Paying attention to what is being talked about, written about and lectured about is absolutely important. This stuff is moving so fast that you can become a "has been" in a matter of years. So, if you think that you can come up with all the terrific ideas that the whole community is coming up with you must be delusional.
Thirdly, I've had the great good fortune for the past two years to be building an app from scratch. It is really fun and I'm getting paid for it. I have been using the Agile methodolgy and trying to deliver some new functionality to the users every week or two at the most. Previously I was the head of application development for a financial serivces company and I had a team of five working on a large application when the opportunity to join a smaller company and assume total responsibility for the architecture and the coding of an application came my way. I jumped at the chance.

Lastly here is one of the puzzles that I have used in the interview:

You've been invited to go on a camping trip in the woods with 30 of your closest buddies.

You pile into your cars and drive to the cabin. The next morning, everyone gets up and decides that Cookie is going to make homemade panckaes for all 30 of you. But, he needs exactly two gallons of water.

You are sent to the well to fetch the two gallons. However, you have no measuring device. When you get to the well, you discover there are two jugs there. One says 13 gallons and the other says 7 gallons. Your job, if you choose to accept it, is to come back with exactly two gallons of water.

Can you make two trips to the well? No. You are allowed only one trip.

to zaphod,
Let me first say this, I took a peek at your site, I like its design, did you do it yourself?
Now, on "intangle benefits", imho, stock investment may be considered as one, its benefits are not up front, vs. "tangle benefits" like buying a bunch of apples and you can eat them, taste them right away. And I think in general it's easier to sell "tangles" than "intangles", and your thoughts? Sorry, Andy, we're are deviating your "COURSE" :)

Don: thanks for the kind words; sadly, I don't deserve any credit. It is a WordPress theme called "subtle", available here: http://www.gluedideas.com/ I would also agree that tangible benefits are an easier sell. I also like Franko's riddle above. 13-7=5; 7-5=2. Am I hired? :-)

Zaphod:You've got the math correct but just like coding the devil is in the details. What's the sequence of filling the two containers? You're still in the running. By the way the site looks clean and handsome.

13-7=6, not 5 Fill the 7 gal. bucket, empty it into the 13 gal. Fill the 7 gal. bucked, pour 6 gal. into the 13 gal., filling it, leaving i gal. in the 7 gal. bucket. Empty the 13 gal. bucket, pour the 1 gal. from the 7 gal. bucket into it. Fill the 7 gal. bucket, pour it into the 13 gal. bucket, leaving 8 gal. in it. Fill the 7 gal. bucket, pour 5 gal. into the 13 gal. bucket, filling it and leaving 2 gal. in the gal. bucket.

Yeah - that math was not correct. Don't hire me - I can't pay attention to details.
Bill has the sequence correct. I would consider him a candidate.
It's a good tool but only a small part of the difficult process of choosing the right candidate.

D'OH! I guess I'm off the unemployment line.

..

Whaaaaat... no one person can "build from scratch" not with the size of software projects today. If you're talking about very small projects then everyone has built from scratch unless they skipped their HelloWorld tutorial in CS101. Then value would you get out of it if it were small? Even then you might still be using someone else's software library.

"13-7=5; 7-5=2. Am I hired?" 
 
Zaphod answered the question very well and concisely. If you know enough to ask the question, you know enough to recognize the correct solution. I'd hate to work for someone that didn't know enough to recognize a correct solution.