[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re: Offtopic: How to Design Programming Tests



    I've been given the task at work of designing our Java
>    test for potential programmers.  Given the recent
>    discussions on this list about CS education, I thought
>    many of you would have opinions about what a good
>    programmer should know, and hence what a good test
>    should contain.  My current proposed outline for the
>    test is:

What version of Java are you testing on and going to be using?
There are some new things in Java 2 that they should know if thats
what you are going to use.
> 
>    Q1.  Java nuts & bolts.  .equals() vs ==, objects,
>    classes & inhertance, packages, dispatch
> 
> good point. 
>
What is the relation between interfaces and classes, when would you use one
over the other?

Exceptions syntax, when do you use them, creating your own.

>    Q2.  Write a linked list to spec.  Ability to follow
>    specs and use exceptions.  Possibly defining inner
>    classes.  This is mainly to prove they actually know
>    Java (you'd be surprised).
> 
> write an XML tree to spec. shows them that trees matter. 

I would just concentrate on an inner class test, I wouldn't use XML
as part of the core Java test since that is an add on to Java. Maybe
have an extension test to see what they know about those.

Also, if you're using Java 2 the collection classes there are probably more
useful than
a linked list, so ask them about that.  I haven't used a linked list in
Java yet, been doing
it since it first came out.

>    Q3.  Sockets and servers.  How to send and receive
>    messages over sockets.  The architecture of the
>    typical multi-threaded server (main server thread
>    dispatches to many handler threads).  The use of
>    thread & database pools to improve performance and
>    control load.  
> 
> stress testing first? 

You might want to make this generic since not everyone doing messaging
is using sockets, ie RMI, JMS, some third party messaging tool.

You can also ask about another way of scaling servers, whether they are
singe/multi threaded.

>  Q4.  Threads.  Code the producer/consumer. Give
>   reasons for (responsiveness, blocking IO) and against
>   threading (synchronisation overhead)

What are the diffent types of synchronization you can do.

>    Q7.  Random questions to assess their depth - what is
>    a regular expression?  non-blocking (asynchronous) IO?
>     a lexical closure/first-call function?
> 
> 1. what's a context-free grammar and why does this matter for XML? 
> 
> 2. what's CPS and why is it relevant to writing CGI scripts or servlets? 
> 
> 3. what is a set, set union, set intersection, set inequation and why
> does
>    this matter for understanding the flow of values in a program or which
>    exceptions can be raised. 

Do they use the monolithic or iterative approach to design/coding?

If there is a database involved ask them about jdbc and SQL knowlege.

Would you sacrifice design for performance?

RJA