In a corporate development environment, you don't want someone who can only write code based on what they already know. You want someone who can accept a task requiring skills they don't already have - yet deliver quality anyway.
The old adage about "if all you have is a hammer, everything looks like a nail" is what I'm going on about here.
If your candadate only knows one thing ( Java or Delphi, or C++) be wary.
If the candidate knows something useful about a wide variety of things (Java, Delphi, C, C++, shell scripting, XML, XSL, HTML, CSS, Perl, Python, Ruby, batch files, SQL, XQL, servlets, JSP, ASP, PHP...) then you have a candidate that has a variety of tools in their skills toolbox.
Before anyone chimes in with the old myth "you can only know one thing well" - I agree completely, you can only be an expert in one or two areas. But you CAN know a dozen (or two) things well enough to know which to use - one of the brightest developers I've ever met was a guy smart enought to say "I shouldn't do this - it needs X and I don't know it well enough. Give this to person A and I'll pick up what they are currently doing." This same guy scored 100% on the Java certification exam - he's that good.
Ask your candidate what tools they know - from what vendors. Don't settle for one or two - keep pushing for as many as they mention. Ask them to explain how they would choose between tools - if needed, give them a scenario or three.
One of the things you're trying to find with this approach is how well they might understand the principals that underly the languages - just as you wouldn't ask a fish about water, you can't ask someone who knows only one tool to critique that tool.
Another idea is to get your candidate to give a five minute off-the-cuff presentation on something interesting. Limit it to stuff relevant to the position you're interviewing for, but otherwise leave it open for the person to choose for themselves. They'll choose something they know well - look for how they speak, how well they explain, how well they teach. Also shows how they work under pressure.
Unusual for Borland, they have added quite a few extras to their release such as a complete (!) copy of Kylix 3, Borland's port of Delphi to Linux.
Having extras included with your Borland purchase isn't strange at all - every time I've purchased a Delphi edition (1, 2 then 5) it came with a whole stack of CDs.
Delphi 5 came with free copies of C++ Builder 3 and JBuilder 2; IIRC it also included a web site tool (can't remember which), a Companion Tools CD (some free stuff and some demos of 3rd party). Way back when Delphi 2 and 3 were released, each came with bundled Delphi 1 for 16bit development.
Why restrict your considerations to Indian companies?
There are a number of companies here in New Zealand that specialise in providing services to foreign clients. The exchange rate to the NZ dollar makes things very competitive - and you end up dealing with people who can understand your companies culture.
The typical Kiwi (*) developer takes personal pride in his/her work - this can work much to your advantage.
(*) Kiwi is a positive slang term for a New Zealander.
One company I know of is Black Coffee Software(http://www.bcsoft.co.nz) - there are many others.
A number of posters have already pointed out that XSLT isn't a procedural language, so procedural thinking won't be the best approach.
However, XSLT isn't just functional (although functional it is). It can also be characterised as a rule based language.
A match template can be viewed as a rule that defines what actions should be taken in particular circumstances.
As an example, loops often don't need to be explicitly coded at all. Instead of writing some code to say "Find all elements and iterate overthem doing Xyz", you just write a template that says "Whenever you find an do Xyz" and let the stylesheet processor drive things for you.
I'd suggest that the last thing you want to do when writing XSLT code is to think with a Perl mindset (insert procedural language of choice instead of Perl - Java, Delphi, C, C++, whatever).
Instead, concentrate on thinking about the facilities the language does provide. Buy yourself a good book or two - Micheal Kay's "XSLT Programmers Reference" is very good. I keep my copy within arms reach whenever doing something tricky.
Every language has its very own mind set - or paradigm, if you will. Even between languages that have substantially similar capabilities (eg Java and Delphi), the "most right" way of solving a problem can be very different, simply because of the design paradigm the language and library designers used.
XSLT is no different - and because the language is so different to conventional procedural programming languages, you'll tie yourself into great knots if you don't put some effort into learning the "XSLT Way".
A couple of final tips...
... XPath is your friend - learn about paths and predicates.
... Do pay attention to modes (see xsl:template and xsl:apply-templates)
... do search the web and pull apart stylesheets written by others
I've worked for years with Borland Delphi - this now shares the same back end and debugger with C++ Builder (I've even heard that the Delphi debugger can show you the C++ code if you step into some C++ Builder code.)
My suggestion is for you to concentrate on including the Debug information you actually need in the executable - rather than all of it.
Sure, include complete information for your core application logic - but do you need all the debug info for your common libraries?
The company I work for has developed several large (man-decades of effort, dozens of executables) applications for our key client and we have a large (> 500 KLoc) library of reusable code - everything from code libraries and GUI components to Business logic and OO database persistence.
Our experience is that our fundamental libraries are soon well exercised enough that we can be confident there are few, if any, serious bugs. We therefore limit our debugging to the aspects which are unique for each application.
Alternatively, you may also want to investigate the use of runtime packages - by dividing your project into muliple links you may gain considerable flexibility, both for debugging and deployment.
Slashdot Mirror
It's kinda hard to believe an article that gets basic physics wrong.
The actual speed of electrons in wire is very very slow - on the order of milimetres per minute.
The speed of electrical signals on the other hand is normally around 0.6c.
You'd think that the editors at New Scientist would have a clue. I studied this stuff at High School - age 15. It's not Rocket Science.
In a corporate development environment, you don't want someone who can only write code based on what they already know. You want someone who can accept a task requiring skills they don't already have - yet deliver quality anyway.
...) then you have a candidate that has a variety of tools in their skills toolbox.
The old adage about "if all you have is a hammer, everything looks like a nail" is what I'm going on about here.
If your candadate only knows one thing ( Java or Delphi, or C++) be wary.
If the candidate knows something useful about a wide variety of things (Java, Delphi, C, C++, shell scripting, XML, XSL, HTML, CSS, Perl, Python, Ruby, batch files, SQL, XQL, servlets, JSP, ASP, PHP
Before anyone chimes in with the old myth "you can only know one thing well" - I agree completely, you can only be an expert in one or two areas. But you CAN know a dozen (or two) things well enough to know which to use - one of the brightest developers I've ever met was a guy smart enought to say "I shouldn't do this - it needs X and I don't know it well enough. Give this to person A and I'll pick up what they are currently doing." This same guy scored 100% on the Java certification exam - he's that good.
Ask your candidate what tools they know - from what vendors. Don't settle for one or two - keep pushing for as many as they mention. Ask them to explain how they would choose between tools - if needed, give them a scenario or three.
One of the things you're trying to find with this approach is how well they might understand the principals that underly the languages - just as you wouldn't ask a fish about water, you can't ask someone who knows only one tool to critique that tool.
Another idea is to get your candidate to give a five minute off-the-cuff presentation on something interesting. Limit it to stuff relevant to the position you're interviewing for, but otherwise leave it open for the person to choose for themselves. They'll choose something they know well - look for how they speak, how well they explain, how well they teach. Also shows how they work under pressure.
Unusual for Borland, they have added quite a few extras to their release such as a complete (!) copy of Kylix 3, Borland's port of Delphi to Linux.
Having extras included with your Borland purchase isn't strange at all - every time I've purchased a Delphi edition (1, 2 then 5) it came with a whole stack of CDs.
Delphi 5 came with free copies of C++ Builder 3 and JBuilder 2; IIRC it also included a web site tool (can't remember which), a Companion Tools CD (some free stuff and some demos of 3rd party). Way back when Delphi 2 and 3 were released, each came with bundled Delphi 1 for 16bit development.
Why restrict your considerations to Indian companies?
There are a number of companies here in New Zealand that specialise in providing services to foreign clients. The exchange rate to the NZ dollar makes things very competitive - and you end up dealing with people who can understand your companies culture.
The typical Kiwi (*) developer takes personal pride in his/her work - this can work much to your advantage.
(*) Kiwi is a positive slang term for a New Zealander.
One company I know of is Black Coffee Software(http://www.bcsoft.co.nz) - there are many others.
A number of posters have already pointed out that XSLT isn't a procedural language, so procedural thinking won't be the best approach.
...
However, XSLT isn't just functional (although functional it is). It can also be characterised as a rule based language.
A match template can be viewed as a rule that defines what actions should be taken in particular circumstances.
As an example, loops often don't need to be explicitly coded at all. Instead of writing some code to say "Find all elements and iterate overthem doing Xyz", you just write a template that says "Whenever you find an do Xyz" and let the stylesheet processor drive things for you.
I'd suggest that the last thing you want to do when writing XSLT code is to think with a Perl mindset (insert procedural language of choice instead of Perl - Java, Delphi, C, C++, whatever).
Instead, concentrate on thinking about the facilities the language does provide. Buy yourself a good book or two - Micheal Kay's "XSLT Programmers Reference" is very good. I keep my copy within arms reach whenever doing something tricky.
Every language has its very own mind set - or paradigm, if you will. Even between languages that have substantially similar capabilities (eg Java and Delphi), the "most right" way of solving a problem can be very different, simply because of the design paradigm the language and library designers used.
XSLT is no different - and because the language is so different to conventional procedural programming languages, you'll tie yourself into great knots if you don't put some effort into learning the "XSLT Way".
A couple of final tips
... XPath is your friend - learn about paths and predicates.
... Do pay attention to modes (see xsl:template and xsl:apply-templates)
... do search the web and pull apart stylesheets written by others
Hope this helps.
I've worked for years with Borland Delphi - this now shares the same back end and debugger with C++ Builder (I've even heard that the Delphi debugger can show you the C++ code if you step into some C++ Builder code.)
My suggestion is for you to concentrate on including the Debug information you actually need in the executable - rather than all of it.
Sure, include complete information for your core application logic - but do you need all the debug info for your common libraries?
The company I work for has developed several large (man-decades of effort, dozens of executables) applications for our key client and we have a large (> 500 KLoc) library of reusable code - everything from code libraries and GUI components to Business logic and OO database persistence.
Our experience is that our fundamental libraries are soon well exercised enough that we can be confident there are few, if any, serious bugs. We therefore limit our debugging to the aspects which are unique for each application.
Alternatively, you may also want to investigate the use of runtime packages - by dividing your project into muliple links you may gain considerable flexibility, both for debugging and deployment.
Hope this helps.