On Wed, 01 Oct 2003 17:38:04 +1000, Rick <rrquick@nospam-com> wrote:
I'm currently preparing for an interview on VB.Net Development.. could
someone please give me an idea as to what type of questions can one ask
(it's a practical test) and what sort of things I should be prepared
for? It's going to be on VB.Net and connectivity with SQL Server
perhaps.. any help would be appreciated. Thank you
Always try to get some detail in advance of the practical. For
example, you say SQL connectivity might be involved. That covers a
lot of area, and may involve ADO.NET or it may be SQL query language.
Though you're better knowing both of course, if you know the scope in
advance you can bone up on it. Some organizations may not tell you,
but most will give you a general list of topics.
Most programming practicals have the basics as part of them, such as
can you write a pre-test condition loop, or basic input/output
statements. They also will usually have simple array questions and a
function/sub creation portion. In VB.NET you may also get basic
controls or user interface type questions. All these are designed to
weed out the applicants who look good on paper but hav no real
programming abilities.
You also may get a couple mini-programming tasks which start as a
vague request, the kind a user might have. You might have one like
"The accounting department needs a way to query monthly telephone
usage from our internal SQL contact database and extrapolate that for
client billing." You need to ask questions of the interviewer about
how the data is to be displayed or manipulated, how thw billing is to
be accomplished and so on. They'll give you the table structure for
the SQL database, and an hour to write the application. Usually what
they're looking for is how you approach the task, how you write code,
what logic you may have involved and so on. These tests are more
common when you're not going to be part of a project team, but they
are good for determining a candidate's thought processes.
The hard ones are often the more obscure questions, dealing with
debugging existing code for example. You need to have a solid grasp
of the syntax as well as the programming design and concept process to
get through these with flying colors. The only way you make it
through these is by knowing the langauge cold and having a working
experience in programming. For an entry level position the score may
not matter on these, or it may be all the interview team looks at.
We usually do a strengths/weaknesses chart of applicants, and compare
them. We never have the perfect candidate, and we purposely use some
interview questions and even testing questions that have no legitimate
answer. These are to see how the applicant reacts, which is often the
deciding factor in hiring. An applicant that approaches the problem,
figures out they don't know how to handle it or that there may not be
a correct answer and admits it is more valuable than one who tries to
fake his way through.
Since we always hire a candidate who doesn't have every single skill
we need, we hire the one who best compliments our existing staff and
who has the ability to learn the missing skills. So don't be
discouraged if you don't get the job even if you seemed like a great
candidate, sometimes the decision isn't based on your ability but
rather the abilities misisng at the hiring organization.
Good luck.
Jeff
