Shortage of qualified Java programmers

[Chris Uppal]

it is vital to understand that in TCP there is no concept of packet
boundaries available to the user. none. to the user, TCP is a stream-
based transport that makes no guarantees as to how the data is sliced
and diced at the system call interfaces and in transit. the only
thing it tries to guarantee is that the same sequence of bytes arrive
in the same order.

I think that you may be missing the point of this discussion. We all know what
the semantics of TCP/IP are, the question is why and how is the server-side
code broken.

A related question which is also being discussed is whether there is a
clientp-side workaround for the problem. In order to find such a workaround
(which might easily be necessary if the server-side code wasn't be under the
control of the client-side developers), you have to understand how packet
boundaries affect the typical behaviour of networking APIs that are likely to
be in use on the sever. One of the effects is that packet boundaries affect
undefined aspects of the behaviour of functions like read().

-- chris

 

[Dale King]

Dale King wrote:




These are questions that tell me nothing about the candidate's ability to
*use* the classes in question.

All those that replied to my post seemed to have miss the sentence
before this where I said:

"If you want to test familiarity with the API then ask general,
open-ended questions about the API. People have given you examples, but
some other examples:"

These are questions to "test familiarity with the Java API", which in
another post I believe you said you want. They are not a sufficient set
of interview questions.

It is silly to test in-depth knowledge of any other than the basic API's
(and which are considered basic has been debated considerably). API's
that you are not familiar with can be quickly learned, but basic
familiarity like these questions show takes experience.

I prefer "problem" type questions as I
think they are better at separating the men from the boys.

Except they separate one group from another and the difference between
those two groups has little to do with the ability to do the job.

Again, I am not expecting a perfect recollection of the API. If they get
some method or constant names wrong I will not penalize them. But if they
make really stupid mistakes it tells me they don't have a clue. For
instance, if they are writing a Comparator and they declare their compare
method as:

public boolean compare(Object a, Object b);

or

public int compare(Object a);

then I know for a fact that they have absolutely no clue what a Comparator
is.

That knowledge can be tested much more quickly using the questions I
described.

My last piece of advice (although you don't seem to listen to it) is
that interviewing is like the weather radar. The result is not a yes/no
result (although sometimes it is a clear no). You don't look at the
weather radar to know if it is raining or not. The purpose of the radar
is to know where it is raining, how hard it is raining, and where it is
not raining. The purpose of an interview is to find out where a
candidate has knowledge and experience, how thorough that knowledge and
experience is, and where they don't have knowledge.

So don't treat the things you are trying to test as a minimum set of
requirements that if you don't know all of them you fail.

 

[Aquila Deus]

In our development shop, consultants were hired to build an asynchronous
messaging communications framework.

However, the consultants hired to do this used TCP and drove the entire
event loop off a single read(), so that every once in a while a larger
message would only be partially read. The stream would then be out of
sync and crash or need to be rebooted.

Not sure why, but this always seems to happen with people who leave and
don't have to clean up the mess left behind.

Uhh, the code is completely wrong, because read() doesn't necessarily
return everything at once, nor is it required to return only one
message (the client may send 2+ messages via one connection -- this can
improve performance a lot).

BTW they don't have to be experts to know this - one can find how to
deal with such a problem in all kind of servers' code

 

[Dale King]

[Chris Smith <[email protected]>]
|
| Excuse me? How does learning TCP help you to deal with that broken
| server?

the way to do it is to fix the broken server. not to add to the
problem by kludging the client code. you are not *fixing* things by
kludging it, you are just adding to the problem.

And in what way did Chris' response say anything contrary to that that
deserved your rude response.

You say way to do it is to fix the broken server. Chris gave a detailed
analysis of how he (and everyone else) believes the server is broken. It
is fairly obvious to someone who knows how TCP works, but the OP
evidently is not included in that group so Chris' response was helpful.
Chris was trying to do what you suggested and teach the OP about TCP.

He also explained how one might work around it, but cautioned that it is
not guaranteed to work. This work around was not news to the OP as he
was already doing it.

So Chris gave a thorough, helpful response that did not deserve your
rude, unhelpful response.

 

[Dale King]

Speaking as an educator, I think it's fair to say that closed-book tests are
often a way to make the grader's task easier -- one can ask a bunch of
easy-to-grade multiple choice or fill-in-the-blanks questions.

That doesn't seem quote fair to the OP in this case; I just meant to say what
happens a lot in academia.

One of the hardest tests I ever had was a 5 question open book test. And
you were given a whole week to complete it! And your grade was 100%
based on that test!

In my case it actually was good for me. I basically did nothing else for
that week and was the first person to ever get an A in the class. I
(along with about anybody else) probably would have failed the class if
it was closed book.

It was a numerical analysis class BTW if anyone was interested.

 

[Aquila Deus]

[Chris Smith <[email protected]>]
| > [Chris Smith <[email protected]>]
| > |
| > | I can tell you why with a fair degree of certainty. The programmers
| > | who wrote the server didn't bother to learn TCP. If you send header
| > | and body content in one message, then they get confused and don't
| > | deal with it properly.
| >
| > hmm, I am not sure I follow you here. what do you mean when you say
| > "in one message"?
|
| Sorry, I mistyped. I meant "in one IP packet".

so what you are saying is that in order for the server to work
properly it is important that the header and body not be sent in
separate IP packets but in the same packet?

uh, you've lost me. how is this important? and how do you guarantee
it?

You don't. The packet reading should be abstracted, and the server
should be able to work regardless of how the packets are sent.

There should be three layers:

top - deal with a single message
middle - return a complete message stream
bottom - return whatever read() gets.

And the middle layer should work whether a message is sent in one
packet, more than one packet, or more than one messages in one packet.

 

[Bjorn Borud]

[Dale King <[email protected]>]
|
| And in what way did Chris' response say anything contrary to that that
| deserved your rude response.

the way I read it it seemed to me like he was advocating "fixing" it
by kludging the client -- in a way that sometimes *might* make it work
if the guess about the server was correct.

-Bjørn

 

[Lucy]

But all I was meaning was that /for the purposes of the interview/
the link to the JavaDocs should be provided. Googling for sample
code would be out.

it depends on how it is done and why. one of the first things I do
when trying to learn how some non-trivial API is used is to look for
implementations that make use of it.

Sure, and that's a perfectly reasonable thing for a "competent programmer" to
do in general, but not in a context where the only point to the exercise is to
investigate the programmer's familiarity with core APIs.

-- chris

There are so many messages for this topic, forgive me in advance for not
reading them all. Isn't there an obvious solution, that being to contract
the
programming out and just pay for results? As long as the deadline is met
and the code works who gives a damn if the programmer used a book or not.

 

[Alan Krueger]

Uhh, the code is completely wrong, because read() doesn't necessarily
return everything at once, nor is it required to return only one
message (the client may send 2+ messages via one connection -- this can
improve performance a lot).

That was precisely my point.

 

[Chris Smith]

the way I read it it seemed to me like he was advocating "fixing" it
by kludging the client -- in a way that sometimes *might* make it work
if the guess about the server was correct.

If you go back and read the beginning of the subthread, you'll find two
simple facts:

1. Pete Barrett can change the client.
2. Pete Barrett can't change the server.

So fixing the server is not a possibility. The only remaining options
that are guaranteed to be available are to (a) abandon the project; (b)
hold off and hope some third party cares enough to fix the server; or
(c) work around the bug in the server.

For some reason, you seem to be in favor of (a) or (b)... but I can't
tell which. Which is it?

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Bjorn Borud]

[Chris Smith <[email protected]>]
|
| For some reason, you seem to be in favor of (a) or (b)... but I can't
| tell which. Which is it?

would it matter? I think gambling on things correcting themselves by
turning off the Nagle algorithm and using flush to try to affect
packet-boundaries and or timing, is bad advice. why is it so hard to
accept that I have an opinion that differs?

we can discuss this in all eternity and I can tell you exactly how
offensive I find it when people give bad advice and then demand that
people show them proper respect afterwards, as if they did something
laudable. he thinks I am being rude, and I think he's giving bad
advice *and* being rude so let's leave it at that.

-Bjørn

 

[Bjorn Borud]

[Chris Smith <[email protected]>]
|
| For some reason, you seem to be in favor of (a) or (b)... but I can't
| tell which. Which is it?

would it matter? I think gambling on things correcting themselves by
turning off the Nagle algorithm and using flush to try to affect
packet-boundaries and/or timing, is bad advice. why is it so hard to
accept that I have an opinion that differs?

we can discuss this in all eternity and I can tell you exactly how
offensive I find it when people give bad advice and then demand that
people show them proper respect afterwards, as if they did something
laudable. he thinks I am being rude, and I think he's giving bad
advice *and* being rude so let's leave it at that.

-Bjørn

 

[Chris Smith]

would it matter? I think gambling on things correcting themselves by
turning off the Nagle algorithm and using flush to try to affect
packet-boundaries and/or timing, is bad advice. why is it so hard to
accept that I have an opinion that differs?

It's not. I was just very confused about what alternative you
suggested. It now appears that you think the entire project should be
abandoned or indefinitely postponed over the matter. I'm glad there are
other options, but that's up to you.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Aquila Deus]

That was precisely my point.

then... why would your shop hire such lame consultants??

 

[Bjorn Borud]

[Chris Smith <[email protected]>]
|
| It's not. I was just very confused about what alternative you
| suggested. It now appears that you think the entire project should be
| abandoned or indefinitely postponed over the matter. I'm glad there are
| other options, but that's up to you.

the problem is that the "solution" is so fragile that when you look at
it, it isn't really any sort of real solution. the only real solution
is to fix the server. the write/flush/write trick with Nagle turned
off *may* work, in much the same way that the original developer
probably got the server to work when running it over the loopback
interface, but there is no guarantee. you are still relying primarily
on luck and timing to provoke packet, or more correctly, buffer
boundaries.

also there's the problem that if you "fix" it, you *own* the bug if it
stops working again. you're effectively taking ownership of someone
else's mistake -- and frankly, if the server has problems of this
sort, there are going to be more bugs.

-Bjørn

 

[timjowers]

eb,

that's a good interview. that's a good way to weed out the crap. i've
seen lots of programmers who cannot even write p-code. oxymoronic. the
questions are the level of the "intro to programming: java 1" class
taught to freshmen at U So. Carolina. Anyone with a B in such a course
can probably do these and still work for intern wages

there always is and always will be a shortage of good programmers
willing to work for minimum wage. probably you need to raise your pay.
the rates are coming back up slowly. the headhunters are still thinking
of 2003 but recruiting for 2005.

timjowers

ps. long live eecummins

 

[Chris Uppal]

There are so many messages for this topic, forgive me in advance for not
reading them all. Isn't there an obvious solution, that being to contract
the
programming out and just pay for results? As long as the deadline is met
and the code works who gives a damn if the programmer used a book or not.

[I'm assuming that you are changing the subject slightly here]

I don't think that works in general. Employers build up a stable of
programmers (either full time employees, well known contractors, or
sub-contractors with whom they have a stable and long-term relationship) for a
reason.

The point is that /before/ the code is written, the customer must have decided
that it was more damaging not to have the code, than to pay for it (in whatever
coin to whomever). So a deal that boils down to "do it right or don't get
paid" is not, in itself, good enough for the customer. If they were happy for
the work not to be done provided they didn't have to pay for it, then the
wouldn't have bothered in the first place. So, even in a "do it right or don't
get paid" deal, they want to minimise the risk that nothing acceptable will be
delivered, since that (by hypothesis) is a negative outcome (even worse than
just doing nothing since time will have been wasted).

So, contracting the work out, is just a special case of hiring someone to do
the work. Maybe you select a sub-contractor with an established reputation in
the business domain. Maybe you select a subcontractor that has proven to do
good work for you in the past. Maybe you hire a contractor you know and have
worked with before. Maybe you turn it over to your pool of permanent
employees. If you do none of those then you are going to be taking a risk (I
mean a bigger risk than the other options), since you are asking someone you
don't know, and who is by definition unfamiliar with your business and existing
code base (a bad starting point), to do some work for you. This applies
whether you are looking for a contractor or looking to hire a new permanent
employee. So, you attempt to minimise the risk by -- amongst other things --
attempting to evaluate their technical competence.

-- chris

 

[Tris Orendorff]

[Tris Orendorff <[email protected]>]
|
| At the risk of tarred and feathered by the readers of this group, I
| suggest that you check to see if they have passed any of the Java
| certification tests from Sun and others. They are two to three hour
| multiple-choice exams where you need to know the basic APIs,
| threads, collections, syntax vs. run-time errors, I/O, exceptions,
| etc. like the back of your hand.

are there any examples on-line of what these tests look like?

Yes. You can search for "java mock exam" to learn more. There is a good list at: http://levteck.com.


--

Sincerely,

Tris Orendorff
[Two antennae meet on a roof, fall in love and get married. The ceremony wasn't much, but the reception
was excellent.]