File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Jobs Discussion and the fly likes Other things needed to get a job Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Careers » Jobs Discussion
Bookmark "Other things needed to get a job" Watch "Other things needed to get a job" New topic
Author

Other things needed to get a job

bill bozeman
Ranch Hand

Joined: Jun 30, 2000
Posts: 1070
Just wanted to get other people opinions on this:
I feel that knowing the different languges and knowing how to operating systems or software packages are all good and a huge part of interviews, but I sometimes feel that most programmers forget about the other aspects needed to get job offers.
What I am talking about are the business skills. I come from a business background and I have seen that a good majority of developers and programmers, while great at programming, know very little about business. So what I am saying is in addition to hitting on all of your programming success and deep knowledge, don't forget the other points which can really make you stand out like knowing what the other departments needs are and how the fit into the big picture. For instance you should know:
1. The importance of tracking your time and expenses accuratly and timely. Accounting departments analyze how much they should charge clients and bill rates based on the hours you charge a job. So if you don't keep accurate records and say it took you 10 hours when it really took you 20, then next time they pitch that job to a client they are going to charge only half of what it is worth.
2. Knowing how account services department or marketing people need to feel like you are putting the client first. Most of the times they are your interface to the client and they are going to ask for the world most of the time and want it in 2 days. You need to know how to be diplomatic and say, we can't give you this, but how about we do this. Give and take type of thing.
3. Know that designers want there designs to look the same in there Photoshop file as it does on the web page you put together and it needs to look the same on all browsers and all platforms. Programmers have a tendacy to worry about making things functional and not worrying about the design. Art departments hate that, so working with them to deliver thier beutiful art work is very important.
4. Making sure you do not mess up on copy and content. Writers expect what they put into thier word docs to be exactly what they see in your app or web page. Take the time to copy it write and make sure any special characters are translated correctly.
5. Communication with the project managers and project leads. Don't sit on problems and keep them updated daily on progress. Make them know that you are or are not going to make a schedule and make sure they know weeks before the due date and not hours before you deliver to the client.
6. Spec check all your work. Don't rely on the QA team catch your bugs, catch them yourself. If it is a web app, check it on Netscape and IE and check it on Mac and PC and check it on AOL. Test different scenerios. Try to break your app by throwing in special circumstances and wierd results.

I feel that if you can bring this stuff up somehow in an interview it shows how well rounded of a person you are and shows that you care about the project and company in whole and not just about how well you can code something.
This is just my opinion, I was wondering what others were. To tell you the truth, when I go on interviews I try to slide in points from above and I was curious if some of the people here who interview candidates look at that kind of stuff.
Bill
John Coxey
Ranch Hand

Joined: Oct 24, 2000
Posts: 503
Bill:
What you mentioned is a very, very important part of the interview process. The question now becomes, "How do I relate this to the interviewer".
You do this in what I call Part 1 of the interview. This is what I call the "managerial questions" section of the interview. And the reason I keep recommending the "Knock 'Em Dead" books. BTW/ I am not affiliated with any publisher, etc - just wanted to make that clear.
Part II is the technical interview (for those who are wondering).
----
For the managerial portion (Part I)
Now, what you do (called interview preparation), is come up with 3 or 4 stories (job related) that highlight the points mentioned in Bill's previous post.
When the managerial interviewer asks: "Tell me about a project you succeded in", "Tell me about your most favorite project", you can tailor your story to the question. See what I am getting at here. You work the points that Bill mentioned in his previous post into your story. Don't need all of them - but 2 or 3 points would be nice.
Remember, people love stories. And one of the keys to successful interviewing is good story telling abilities. The worst thing you want to do is give a 1 or 2 line answer and then clam up. Some questions you may need to do this with, but most of the time you generate a story.
-----------------
Going out on a limb here.
Watch the Saturday/Sunday morning "Meet the Press" type interview news shows. There are successfull people (both govt. and private sector) being interviewed on these shows.
Look how they dress. For the guys, every single one of them wears a grey or dark colored suite and tie and classic leather shoes (Florsheim wing-tips we call them).
Pay attention to how they answer questions. You almost (99% of the time), never get a direct "YES" or "NO". Look how some of them take the question and run with it. Most reiterate their strong points thoughout several questions.
These people know the rules of interviewing, and follow them to the letter. They never deviate - at least the successful ones.
I know you never heard this piece of advice before - watching "Meet the Press" - to pickup interviewing skills. But try it sometime.
You don't have to agree with what they are saying. But look at the "body language", and how they respond to questions. They use "ah" and not "um". They NEVER swear - EVER!!. They don't meet questions head on alot of the time. And occaisionally they tell a story or two - and that's where it really gets to be fun.
And yes...I'd rather be fishing that watching some Sat morning news show. But sometimes you just gotta make those sacrifices.
Any other opinions/interview success stories out there?
Johnny
(jpcoxey@aol.com)
[This message has been edited by John Coxey (edited March 05, 2001).]


John Coxey
Evansville, Indiana, USA
Ken Pullin
Ranch Hand

Joined: Jan 29, 2001
Posts: 43
Guys - those are two great posts. I don't people really realize quite how important your business skills are. It's great to be technical, but if you can't communicate with clients, work on a project plan, log hours, etc, then you will have a tougher time finding a job. Rarely do you find a "programmer with a personality", but when you do, that person becomes very valuable.
John Coxey
Ranch Hand

Joined: Oct 24, 2000
Posts: 503
Ken:
Regarding programmers with no personalities:
What I hate are programmers who have been on a project 4 or 5 years and are totally non-approachable for advice/instruction. They do a good job of coding (reason why management tolerates them). But, they are a total pain in the rear-end, and have absolutely no people skills.
The EDS/GMAC account (I hope they read these posts) I used to work for in Dayton, OH was full of people like this. There had to be at least 6 or 7 ladies who had been on the project for 8-10 years.
These ladies were so dedicated to the job, that they "lost" their people skills. Forget about asking them for help. To top if off, they didn't even get along with each other. And they blamed the world because they had no socal life.
No wonder the system was/still is a total nightmare.
-------------
A good interviewer (I think) should be able to "weed out" these types of people. This is why both parts (managerial & technical) of the interview are equally important.
John Coxey
(jpcoxey@aol.com)
Ken Pullin
Ranch Hand

Joined: Jan 29, 2001
Posts: 43
John - I definitely agree with your post. I see so many people that think they are just these wonderful programmers, but when it comes to doing anything else they are completely lost. They don't have the business skills it takes to talk to clients or a lot of times are not even interested in the product or how it works. One of the things I look at with potential new hires is their life outside of work. I like for them to talk about their hobbies, families, etc, to get a real impression of their life as a whole. A person that is well rounded will, in my opinion, be a much better employee that someone that clings to their programming skills. Ken
bill bozeman
Ranch Hand

Joined: Jun 30, 2000
Posts: 1070
John, just as a side note. I am working with EDS and GMAC now on a project here in PA. GMACHomeSolutions.com, this isn't up yet, but will be in another month or so. Our company did the art work and copy and helped with the XML.
Bill
Sathvathsan Sampath
Ranch Hand

Joined: Oct 03, 2000
Posts: 96
I just want to share one of my interview experiences in which I failed. This was one of the big 5 consulting companies for which I was interviewed. The first round was very very technical, but I managed to clear it ( as I gather from their feedback) and were reasonably impressed with me for 2nd round.
The next round was a non-technical one and I failed in that. I started off fairly confident and started getting along well. And then came 2 most obvious questions - 1) Have u ever missed a target - expl that and 2) WHats u r team structure and how do u work?
Though, I haven't attended many interviews since my graduation ( I just attended one interview at collg and got the job) and this was my 3rd interview in my life, I did come with the same story telling pattern what John has mentioned above even though I wasn't aware that this should be one of the approach.
Well, I did manage the 1st question, but messed up with the 2nd question.
I was asked to sketch the team structure on the board. I was totally stupid and just explained how the development was done. I said we had different modules with a bunch developers working on different modules and blah blah..... It was then that evening, when I was returning home after the interview I realized that I had explained my entire proj & the team structure JUST FROM A DEVELOPER'S perspective. Oh dear, I felt absolutely stupid to the core!
Even though, I understood the entire team structure and how the proj was managed (to a reasonable extent), about the requirement capture, devlopement , QA and delivery, support & maintanence and how much budget and other business drivers for the proj, I falied to explain what I knew.
In fact, if I were to be talking to a manager (non-technical), I would probably explain what the proj is all about from a high-level and the business aspects of the proj first and not just from a developers angle. In fact, the interviewer was a IT manager.
But the other questions were more on why I intended to leave my current job etc etc.
I strongly felt that I could have really answered in a much better way than I did. It was primarily due to lack of preparation and self-introspection. My presentaion lacked that touch coz I was answering almost all the obvious questions on-the-fly !
Anyway it was really a learning experience for me and I hope I'll now prepare well the next time and explain things in the story-telling pattern. I'll also do a thorough research first before attending those managerial interview.
Also, if I am correct,I read a post by Mark Herschberg recently saying that if you feel that you could have done better with some important question, you can email the interviewer (if appropriate) in a proper fashion explaining it better. He did caution that this approach shouldn't be over used or used for trivial questions.
Well, reading the above posts are really educating and when one fails in an interview, it an invaluable experience on the whole and an opportunity to intropect the gaps and weaker areas. I am now more confident of doing better the next time....

------------------
- Sathvathsan Sampath


- Sathvathsan Sampath
John Coxey
Ranch Hand

Joined: Oct 24, 2000
Posts: 503
Bill:
- Is your team using a lot of Java for the EDS project?
- I was located in Bethlehem, PA (about 50 miles north of Philadelphia). Bethlehem steel had extra office space, so EDS (their IT supplier) decided to bring in outside work from Dayton, OH (this was the GMAC account).
- I was hired-on as a college recruit when I finished my BS-Comp Sci at Univ of Pgh. There are about 700+ people working on this in Dayton, OH and Detroit, MI. We started with 16 people in the Bethlehem office. All 16 (including myself) left within 2 years.
- Basically, our job was to provide 24*7 production support. The system is written in Pacbase which generates Cobol code. The system runs on MVS-TSO, and uses JCL and ACF2(for security), and uses IBM CONTROL-M (for batch cycle scheduling).
- But, there was no training, no overview of how the system worked. I bet it took a good 2 months before we learned how to get into the system to look at the source code. I had to write to the Pacbase company (in France) to get some system manuals.
- There were some ladies in Detroit who had been with the system since the beginning - but forget about asking them for help.
- The system was / and still is - a total nightmare. 20 yr old COBOL code with GOTO's. It takes 2 days for an account to move into or out of collections. So when you do your trace (once for each day of the cycle) - you have to go through the programs twice. What a total mess.
- I worked on the Collections system. There were 20 batch programs - that you had to go through (in order) every night. The printout of one batch program was about 500 pages long and the print was the size of that in a telephone book. I am not making this up.
- This legacy system would be a perfect candidate for a Java re-write. The screens would be simple, and you could still use the mainframe (so your hardware investment would not be lost).
Best of all, the code would finally be clean and we could have some decent documentation.
- Personally, I think they should take the loss - scrap the system - and start over from scratch. Don't even do a conversion.
- I am so glad I did not have to walk this system through Y2K.
Johnny
(jpcoxey@aol.com)

[This message has been edited by John Coxey (edited March 07, 2001).]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Other things needed to get a job