Michael Morett

Agreed. Don't waste your time "getting" the certs, but do spend lots of time studying for them. The knowledge gained, I think, is very useful. It sounds counterintuitive and someone will say "why not just take the test since you studied for it and are ready to pass it". Personally, when I see SCJP on an email signature, I don't immediately think "wow, this person is good", but rather "this person studied for a few weeks." Then there are those like Craig McClanahan who sport no certs, but you *know* they know their stuff just by the way they express themselves.

Originally posted by Jonathan Hendry:
I think you mean Codd's Rules of what a database must support to be relational.
That might help you with Google.
[ September 17, 2003: Message edited by: Jonathan Hendry ]

I'm glad you cleared that one up. I had no idea what he was talking about. It wasn't a one time typo. He used "codes rule" twice. I kept thinking "what the hell is this guy talking about?"
The fact that he didn't know about Codd is not as important as the fact that he couldn't communicate that he didn't know about Codd. This is another great example of why not to hire someone, regardless of tech skills, unless they can communicate effectively.

Originally posted by Seyi Aluko:
...but frequently "excellent communication skills" is usually a polite way of rejecting applicants on the basis of their accent etc. This view may not be popular but that has been my experience.

Tech skills are not the sole criteria to measure in a candidate. I would argue they are not as important as other criteria. You can teach skills in a few months. You can't teach character and integrity.
You seem to imply accent is not a valid basis to reject a candidate. I don't know US law on this subject, but I dont think it protects people who cannot communicate well, for whatever the reason. Accent may be one reason. Intelligence may be another. Choosing to use slang in business contexts may be another.

I kind of liked the "blind quadrapalegic rhesus monkeys" comparison...


Actually, I'm kidding. But only partially. I remember back when I used Frontpage and could never understand why some people hand coded HTML. I called them snobs for mocking my beloved FrontPage.
hint..hint..

Hi Thomas,
I don't know if you were referring to me in anticipation of a response, but I thought I'd slip in my opinion on your situation.
Your situation is a bit different. You have a medical condition which you have no control over.
(pauses a long time on this one)
I'm hard pressed here. The compassionate side of me suggests we acknowledge the situation for what it is and try to make it work. It's the right thing to do.
Those on former debating teams in college or just in the mood to pick a fight will see that I am easily contradicting myself. "How is he different from others", some might ask.
I guess at the heart of your question is the notion of "reasons" for difficulties in communications--are there some reasons which are deemed acceptable when a person's communication skills are less than a hiring manager or team lead desires.
For me, personally, I'd cut you considerable slack. In my mind, your situation is medical and through no "fault" of your own. "Fault" is a loaded term and I use it cautiously. I see your situation as different than a person who's native language is not english, or is english and they just never learned it well.
Short of playing social worker and digging deep into the candidate's childhood for explanations as to why they never achieved a firm grasp of the language, I'm not sure what to do.
If the reason is related to immigration or foreign nationals, again...what do I do? Jon used the analogy of joining a French team and I think it's a beautiful description of the problem.
What makes the issue of communications so important is that application development is so damned difficult. Go read the javadocs for struts. It's written in perfect english and heavy/audible accents are not an issue. And it's STILL a pain to figure this stuff out. Ditto with EJBs.
I believe the desire to hire someone with excellent communication skills is to have one less layer of "noise" to sift through. One less battle to fight. One less issue to deal with during the duration of the project when so many other things inevitably cause problems.
From personal experiences, I've encountered communication issues with all sorts of people, form (nearly?) all races. For every one person I can think of who is of a particular race which had a communication issue, I can point to another from the same race or nationality who did not--(usually born in the states, however).
The Scots are particulary difficult to understand (for me). And I lived in London for two years! Heaven help the American bosses who hire a native Scot. :-)
This is a problem that is not easily overcome. My New York accent is still with me after leaving the city 11 years ago.
Do not underestimate the negative impact of being perceived as difficult to understand. I can remember too many times not initiating a business/technical conversation due to this very issue. Sometimes it is so hard to understand someone that you feel like an idiot saying "what did you say"..."can you repeat that"..."what was that?" I just dont do it unless I have to.
As I watch the elections on TV, it brought a point to mind. Can you think of a news anchor that has a strong accent? In terms of race or nationality, there are a mix of news anchors out there, though there is a heavy majority of white males. Still, it drills the point home. If I can understand you easily, you will be more successful than if I have a hard time.
When I see some of the posts on this board, it is *clear* (typos aside) that some people cannot communicate effectively. I don't care what their tech skills are. If I were hiring, I know I have a potential problem. The ace in your sleeve is that your impediment is limited to speech. and hearing. Ok. Work with me. We have an uphill battle. But you can make up for it in written form. Use emails or documents to your advantage. Make them ask "who wrote this?....damn this is good".

Good luck!

Very well put Jon. I like the analysis and examples.
Hopefully this will clear up any confusion or misguided assumptions that the hiring manager is racist. It's too easy to place the blame on the hiring manager. Too easy to use the race card.
There are times that I sometimes have trouble understanding fairly complex subjects (ie. struts)--even when delivered by someone with *excellent* communication skills. Imagine knowing that your primary resource on the team for struts has terrible communication skills. It's not a pretty thought.

>>You have to hang in there, somehow you will
>>find a hiring manager willing to look beyond
>>the superficial and hire you because you can
>>really do the job.
Superficial?
"can really do the job" means more than programming. Don't downplay or minimize the impact on communication skills. Assume for the moment that the hiring manager or team lead isn't racist, he may have a legitimate concern.
I have worked with people, whom I liked as a person, but found difficult to work with because they were so difficult to understand. Either it was their accent, their choice of words used or mannerisms (ie. interrupting people in midsentence.)
I have even developed on a few occasions "listening fatigue" where I just became worn out and tired of trying to concentrate really hard to truly understand what he/she was trying to communicate (usually verbal as opposed to written). It became preferable not to deal with these communication issues.
It aint worth it. There are too many coders out there that can communicate effectively.
Forget "coding" for the moment. Software development is more than coding. I'm not gonna preach. You know the routine. It means dealing with a multitude of people in various levels in the project/company/client company. It means LOTS of communication.
Give the hiring manager/team lead a break. He's got a legitimate concern.

Ken,
I wasn't arguing against it. Only trying to describe some of the issues of trying to make use of it on a day to day basis. Sometimes, Struts can be a pain to work with. And trying to make use of much of its rich functionality can be difficult without examples to clarify things.
Let me approach it from another angle. You *know* you're going to structure your app using MVC...that's a given. With this in mind, Struts seems to be the emerging standard implementation of MVC, at least on J2EE platforms. It seems to be gaining strength and popularity. It therefore makes sense (to me) to be fluent in how to use Struts and incorporate it in your overall architecture.
What do I like about Struts? Some of the tags it provides are pretty cool and do save me work (logic tags, nested tags, bean tags). It also makes I18n easier if that's an issue in your app. It's got a hook to Validator to support client and server side validation in one shot without resorting to custom Javascript (though not possible to avoid JS in all cases). It works nicely with Tiles (jsp:include on steroids).
From a pragmatic standpoint, you can either take the time to learn it now (since you are essentially forced to due to your new job), or scramble to learn it later when it gains more momentum. Just like Java, I can see an "I'm certified in Struts" crowd seeking to get their foot in the door for jobs that require Struts knowledge.
I still didn't answer your question. The power of Struts is that you dont have to build this functionality, which you would have evolved to during the course of your project anyway. You get new functionality added to "your" framework over time with no development time or cost on your part. And it does the job of implementing MVC very well.
Could you bypass it? Sure. Do you need Struts? no. But what you would end up with is something less powerful than Struts, yet similar in nature and took development resources to create. As your design evolves, you will end up here anyway. One more time for emphasis...you will end up here anyway so skip the custom development for an otherwise commodity piece of functionality and just implement it. Bite the bullet. Schedule a session with a therapist. Load up on the Advil. Send the kids to Grandma or you may beat them at the slightest provocation. But just dig in and learn Struts. Do it now while Struts is only at 1.1b2. Think of JDK 1.14 and what you needed to learn, and now at 1.4.1 and the difference in number of classes, not to mention J2EE and all it entails (JSP, servlets, taglibs, ejb 2.0, cmp, mdb, etc.)
I don't see it as a religious all or none proposition. And I feel the pain for all those trying to learn Struts. The situation should get better in a month or two.
Good luck.

This is part funny, part sad. Poor Ken is looking for a simple answer to what I believe is a simple question: why use Struts. I've been using it for a few months now, and while I agree it provides an out of the box implementation of MVC, I by no means discount Ken's concern.
Let's first dispense with the predebugged comment. It has bugs (as does nearly every piece of complex software).
Let's add in the horrible documentation with little to no example code to illustrate how to use it. For christ's sake, the Jakarta group uses RT EXPR to denote some parameters when what they really mean is "real time expression". (Come on guys, type it fully once and cut and paste if "real time expression" is too hard on your fingers.)
Add in the XML config file(s) that drive struts, with horrendous choices for seemingly conflicting attribute names...
Add in cryptic error message leaving you to wonder where on God's name the real error is...
You get the point. Yes, it works. Yes, it's MVC. Yes, it's powerful. Yes, it's open source.
But does it speed development time? I will argue that it has a high learning curve. It adds too many "other places to look" to debug code. This makes BASIC's infamous GOTO statement look like child's play by comparison. I went from a simple request.getParameter() to "what the hell do I do now?"
Do I use it? Yes. Do I like it? No.
Ken, I can't sell you on it despite seeing the power of Struts before my very eyes. I don't think Struts is the problem, as much as the lousy documentation available that makes using it a pain in the rear.
If, as someone quoted "you're going to throw it away" anyway...then why spend months learning how to get to the point where you can throw it away?
Fortunately a few books are coming out in the next month or two on Struts. Check Amazon.
And go look up the Command pattern!!!
:-)
(kidding)

I liked questions 1 and 3. But number 2?
(pauses to regain composure)
Barring grammatical errors in the formation of the question, I can't even understand what is being asked. Or the relevance. Is his/her expectation that you memorize algorithms? That you could write them on the spot, presumably on a blank sheet of paper with a pen? No logic errors? No compile-time errors?
A better approach would be to give you the problem to take home to solve (assuming the problem is representative of a realistic scenario to be encountered on the job). At least you could resolve it in a real world environment: you have access to your plethora of algorithm books, an IDE, and time to work out the problem.
Maybe it's just me, but the expectation placed on this guy is immature. None of us work like that. I understand the need to verify skills claimed, but this seems petty.
Those that can pull off that exercise in trivia need to be applauded.

Another thread: "Just say no to headhunter BS"
http://www.angrycoder.com/article.aspx?cid=6&y=2002&m=5&d=29
I thought some of the folks here were fired up and angry. Not even close.

Enjoy. It's a lively thread with real examples of the current trend in attempting to hire God.

http://www.angrycoder.com/article.aspx?cid=10&y=2002&m=5&d=24

It's possibly possible.
But think of the ramifications of applying for that job.
"Yes sir, I have worked with Linux for 5 years and I'd like to do that for 5 more. I don't believe in expanding my horizons and growing my skillset."

No Mark, you got me. I didn't read the following threads on Monster. I think "IT Executive" pointed out that you dont "break in" to IT in a lead architect role. Totally valid.
"oops"
:-)

Hey Mark,
How about this?
http://forums.technology.monster.com/viewmessage.asp?messageid=2261531