Craig picked up on my post about source control and it got me thinking. That "From coder to developer" sounds like an awesome session Craig - wish I would see it - maybe you should do a FoxCast
I recall several years ago a post that made its way around the Fox community that were practical questions to ask prospective employees about FoxPro. This had questions like "Why should I use PACK and what are the alternatives?" and "describe the order of a banded report writer" (does anyone have the link for that - it was priceless)
Today, the development world has changed sufficiently that all kinds of other questions should be on there as well. It's not even enough to be certified because that tests your ability to work with various aspects of FoxPro but also about team development.
1. What is the difference between sharing and branching?
2. What rules should you apply before checking in code?
3. What is Extreme Programming?
4. Why should you do a code review?
I also recall that Jim Booth did a hilarious send-up of the answers for the old Foxpro one including :
Q: How does the Transporter work?
A: You step into the circle and say "Scotty, beam me up"
Q: How does a multi-band report writer work?
A: One band is enough for me, I like the Rolling Stones.
Q: What should you check when you PACK a table?
A: Toothbrush, clean underwear, etc - how would you fit a table into a suitcase anyways?
What non-FoxPro questions do YOU ask potential FoxPro hirees?
For that matter, what FoxPro questions do you ask?
FoxBlog
I recall several years ago a post that made its way around the Fox community that were practical questions to ask prospective employees about FoxPro. This had questions like "Why should I use PACK and what are the alternatives?" and "describe the order of a banded report writer" (does anyone have the link for that - it was priceless)
Today, the development world has changed sufficiently that all kinds of other questions should be on there as well. It's not even enough to be certified because that tests your ability to work with various aspects of FoxPro but also about team development.
1. What is the difference between sharing and branching?
2. What rules should you apply before checking in code?
3. What is Extreme Programming?
4. Why should you do a code review?
I also recall that Jim Booth did a hilarious send-up of the answers for the old Foxpro one including :
Q: How does the Transporter work?
A: You step into the circle and say "Scotty, beam me up"
Q: How does a multi-band report writer work?
A: One band is enough for me, I like the Rolling Stones.
Q: What should you check when you PACK a table?
A: Toothbrush, clean underwear, etc - how would you fit a table into a suitcase anyways?
What non-FoxPro questions do YOU ask potential FoxPro hirees?
For that matter, what FoxPro questions do you ask?
FoxBlog
Comments
Jim Booth's hysterically funny retort is around here somewhere...
I question whether you are hiring "coders" or junior programmers or developers or architects or "software engineers" or consultants. There are a wide variety of titles and job responsibilities in this field, and appropriate questions for one are irrelevant for another.
Curriculum that teaches "Computer Science" has a different focus than "Computer Information Systems" or other specialties. Software Development Methodologies are taught to varying levels within these programs and, of course, some far better than others.
"Pragmatic Programming" is a tour de force on the subject of software development, imo. Far better than a Code Complete or the other MSPress writeups, when it comes to SMB development in the real world. http://www.pragmaticprogrammer.com/
And experts still disagree on what qualifies as a good methodology. RUP and XP are just theories. PVCS, SourceSafe, RCS, CVS, Subversion and BitKeeper have different styles of SCC. One may be better suited for a particular situation than another. And Change Management is not the same as SCM thats not the same as SCC, so you need to nail down what you want to talk about.
"What is the difference between sharing and branching?"
A: With sharing, all copies of your code have the same bugs. With branching, you create different bugs in each branch.
Tools, techniques and technologies wax and wane. Someone knowledgeable in people skills and how to learn and how to keep on top of what's happening in our profession is far more valuable than rote learning the "Four Pillars of OOP."
That cracks me up!
Great points Ted - in my case , I was expecting to hire developers who I believe should be aware of at least certain aspects. But you make very good points.
The issue isn't necessaryily one of approach though but rather of awareness. I agree that the tools and techniques may change but the basic concept/understanding of configuration management does not (just like in building a house).