Home > Archive > Cobol > December 2006 > COBOL interview tests
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
COBOL interview tests
|
|
| krewser 2006-12-25, 3:55 am |
| I interviewed with an organization 18 months ago. During the interview
I was asked to take a COBOL programming test. I've been programming
exclusively in COBOL for 20+ years and the first question threw me for
a loop. Write a program from scratch to merge two files. That was
easy enough but I have never written a COBOL program from scratch since
I studied it in school. I never found out the results of this test. I
didn't get the position and I was never informed as to why but I
believe that it may have been because of this test.
Another position with this organization might be opening up after the
1st of the year and I want to be better prepared for this test. Does
anyone have any information on these types of tests? Such as what are
the questions? What results are they looking for?
Thanks for any help,
Bill
| |
| HeyBub 2006-12-25, 3:55 am |
| krewser wrote:
> I interviewed with an organization 18 months ago. During the
> interview I was asked to take a COBOL programming test. I've been
> programming exclusively in COBOL for 20+ years and the first question
> threw me for a loop. Write a program from scratch to merge two
> files. That was easy enough but I have never written a COBOL program
> from scratch since I studied it in school. I never found out the
> results of this test. I didn't get the position and I was never
> informed as to why but I believe that it may have been because of
> this test.
>
> Another position with this organization might be opening up after the
> 1st of the year and I want to be better prepared for this test. Does
> anyone have any information on these types of tests? Such as what are
> the questions? What results are they looking for?
>
Take with you an example program that you did write and offer that as a
substitute for their silly test. If that won't work...
I've found the following program more than adequate for these questions:
PROCEDURE DIVISION.
CALL 'GET'
CALL 'MULL'
CALL 'PUT'
STOP RUN.
| |
| William M. Klein 2006-12-26, 6:55 pm |
| Did you use the MERGE statement or write your own "merge logic"? Other than
that, I can't really imagine that "test" being very useful.
--
Bill Klein
wmklein <at> ix.netcom.com
"krewser" <wkrusinski@yahoo.com> wrote in message
news:1167022974.195881.14990@i12g2000cwa.googlegroups.com...
>I interviewed with an organization 18 months ago. During the interview
> I was asked to take a COBOL programming test. I've been programming
> exclusively in COBOL for 20+ years and the first question threw me for
> a loop. Write a program from scratch to merge two files. That was
> easy enough but I have never written a COBOL program from scratch since
> I studied it in school. I never found out the results of this test. I
> didn't get the position and I was never informed as to why but I
> believe that it may have been because of this test.
>
> Another position with this organization might be opening up after the
> 1st of the year and I want to be better prepared for this test. Does
> anyone have any information on these types of tests? Such as what are
> the questions? What results are they looking for?
>
> Thanks for any help,
> Bill
>
| |
| krewser 2006-12-26, 9:55 pm |
| I wrote my own merge logic.
I was wondering if anyone else ever ran into this test and what their
thoughts on it were.
Bill
William M. Klein wrote:
> Did you use the MERGE statement or write your own "merge logic"? Other than
> that, I can't really imagine that "test" being very useful.
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
| |
|
| I've interviewed Cobol programmers back when I was in a Cobol shop.
We used to give tests like this ("write a program that <insert simple task
here> ...."). What the programs had to do was really irrelevent. It didn't
even matter to us whether or not the program actually worked - it just had
to come close. We only gave a few hours to get it done. (On the other
hand, we weren't hiring people with 20+ years experience either at what we
were paying.)
We gave a sheet with instructions on where to put the source and how to
compile and run it. The tests were done under Windows, so we assumed
everyone was familiar with Notepad and the basics of navigating Windows.
(Our actual development environment was on Unix, but Windows was the common
denominator.)
In our case, the tests were really just to see if the person knew more than
just how to do well in an interview (or maybe didn't do so well in
interviews, but were proficient programmers). Could they actually write a
Cobol program? You'd be suprised at how many people we interviewed for a
Cobol programming position who didn't know Cobol other than from a few
classes, couldn't write a program, and gave up without anything. Could they
follow instructions to compile and run the program? Could they identify
compile errors and correct them? What would they do to test their program?
No one could really tell you what we were looking for - the programming task
we had people do was just thought up at the time we were hiring and there
was no set "answer" that we were looking for.
As for your situation, where you said you never wrote a program from
scratch - I know what you mean. We usually started with a template, rarely
a blank slate. But when we had people do a test like this, we always
allowed them to use the help file that contained the Cobol manual. I
figured, heck, I had been programming in Cobol for 20+ years and I still
occasionally used the manual, so there's no reason this person shouldn't be
able to also. It was a programming skills test, not a memory test.
"krewser" <wkrusinski@yahoo.com> wrote in message
news:1167022974.195881.14990@i12g2000cwa.googlegroups.com...
>I interviewed with an organization 18 months ago. During the interview
> I was asked to take a COBOL programming test. I've been programming
> exclusively in COBOL for 20+ years and the first question threw me for
> a loop. Write a program from scratch to merge two files. That was
> easy enough but I have never written a COBOL program from scratch since
> I studied it in school. I never found out the results of this test. I
> didn't get the position and I was never informed as to why but I
> believe that it may have been because of this test.
>
> Another position with this organization might be opening up after the
> 1st of the year and I want to be better prepared for this test. Does
> anyone have any information on these types of tests? Such as what are
> the questions? What results are they looking for?
>
> Thanks for any help,
> Bill
>
| |
|
| JJ wrote:
> As for your situation, where you said you never wrote a program from
> scratch - I know what you mean. We usually started with a template, rarely
> a blank slate. But when we had people do a test like this, we always
> allowed them to use the help file that contained the Cobol manual. I
> figured, heck, I had been programming in Cobol for 20+ years and I still
> occasionally used the manual, so there's no reason this person shouldn't be
> able to also. It was a programming skills test, not a memory test.
I was curious about this. Are you not allowed to use a manual? I've
been at this nearly a decade now, but I still rely on my manual,
probably on a w ly basis. From the "how do you" questions, to the
"what does this do" stuff, the manual is an invaluable tool.
With the one question that's been mentioned - a merge. I've *never*
done a merge. Never. Never studied it in class, never written it
myself, never encountered it during maintenance. I'd need the manual
for that question. :)
Without a manual, I'd take a stab at the syntax...
MERGE file-1 file-2
GIVING file-3
Ah - but I have a COBOL manual on my computer. Let's see... Looks like
I'm missing a "USING" clause...
MERGE file-1 USING file-2 GIVING file-3
How about that - I learned something! :)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
"Who is more irrational? A man who believes in a God he doesn't see, or
a man who's offended by a God he doesn't believe in?" - Brad Stine
| |
| HeyBub 2006-12-26, 9:55 pm |
| LX-i wrote:
>
> Without a manual, I'd take a stab at the syntax...
>
> MERGE file-1 file-2
> GIVING file-3
>
> Ah - but I have a COBOL manual on my computer. Let's see... Looks
> like I'm missing a "USING" clause...
>
> MERGE file-1 USING file-2 GIVING file-3
>
> How about that - I learned something! :)
Yeah, but at what cost. You had to make room for something your experience
says will probably never be used.
Say goodbye to the fifth grade.
| |
| krewser 2006-12-27, 7:55 am |
| This test was a little different. It had four or five questions. The
first was writing the merge program. The second one contained some
code that needed to be desk checked to find an error. I don't recall
the other questions.
The interviewer sat me at an empty cubicle with the test, paper and a
pencil. No computer or manuals were involved.
JJ wrote:
> I've interviewed Cobol programmers back when I was in a Cobol shop.
>
> We used to give tests like this ("write a program that <insert simple task
> here> ...."). What the programs had to do was really irrelevent. It didn't
> even matter to us whether or not the program actually worked - it just had
> to come close. We only gave a few hours to get it done. (On the other
> hand, we weren't hiring people with 20+ years experience either at what we
> were paying.)
>
> We gave a sheet with instructions on where to put the source and how to
> compile and run it. The tests were done under Windows, so we assumed
> everyone was familiar with Notepad and the basics of navigating Windows.
> (Our actual development environment was on Unix, but Windows was the common
> denominator.)
>
> In our case, the tests were really just to see if the person knew more than
> just how to do well in an interview (or maybe didn't do so well in
> interviews, but were proficient programmers). Could they actually write a
> Cobol program? You'd be suprised at how many people we interviewed for a
> Cobol programming position who didn't know Cobol other than from a few
> classes, couldn't write a program, and gave up without anything. Could they
> follow instructions to compile and run the program? Could they identify
> compile errors and correct them? What would they do to test their program?
>
> No one could really tell you what we were looking for - the programming task
> we had people do was just thought up at the time we were hiring and there
> was no set "answer" that we were looking for.
>
> As for your situation, where you said you never wrote a program from
> scratch - I know what you mean. We usually started with a template, rarely
> a blank slate. But when we had people do a test like this, we always
> allowed them to use the help file that contained the Cobol manual. I
> figured, heck, I had been programming in Cobol for 20+ years and I still
> occasionally used the manual, so there's no reason this person shouldn't be
> able to also. It was a programming skills test, not a memory test.
>
| |
| Pete Dashwood 2006-12-27, 7:55 am |
|
"LX-i" <lxi0007@netscape.net> wrote in message
news:a940d$4591d576$454920f8$31278@KNOLO
GY.NET...
> Without a manual, I'd take a stab at the syntax...
>
> MERGE file-1 file-2
> GIVING file-3
>
> Ah - but I have a COBOL manual on my computer. Let's see... Looks like
> I'm missing a "USING" clause...
>
> MERGE file-1 USING file-2 GIVING file-3
>
> How about that - I learned something! :)
Yeah, but a REAL programmer would write a 3 way split... :-)
Pete.
| |
| Robert Jones 2006-12-27, 7:55 am |
|
How would you get on if you said they should use the system sort
utility instead?
| |
| Michael Mattias 2006-12-27, 7:55 am |
| "Robert Jones" <rjones0@hotmail.com> wrote in message
news:1167217714.110186.220900@i12g2000cwa.googlegroups.com...
> How would you get on if you said they should use the system sort
> utility instead?
I would point out that in the professional software development arena,
clients/users are responsible for defining the what" but the developer is
responsible for the "how."
If it's some kind of anal PHB I might go so far as to point out that the
COBOL MERGE verb **IS** using the system sort utility anyway.
Being an opportunist, I might even suggest I provide a (paid) training
session in 'merge techniques' for the rest of the staff, showing how there
are at least two ways to skin this cat.
But regardless of path I think it likely that if really pressed on this
point I'd probably end up making some smartasss comment vis-a-vis paying for
assembly-line labor vs. paying for Real World Results and as a result be
excused from further consideration.
Then again, I don't really need the work.
MCM
| |
| Michael Mattias 2006-12-27, 7:55 am |
| "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:2aikh.152992$b%6.23128@fe10.news.easynews.com...
> Did you use the MERGE statement or write your own "merge logic"? Other
> than that, I can't really imagine that "test" being very useful.
I don't know about that, Bill... if I used the word "merge" in my "story
problem" and the prospective employee/contractor did not automatically reach
for the COBOL 'MERGE' verb, I think I'd be at least a tad chary of ascribing
COBOL expertise to that candidate.....
MCM
| |
| Howard Brazee 2006-12-27, 6:55 pm |
| On Wed, 27 Dec 2006 11:57:37 GMT, "Michael Mattias"
<mmattias@talsystems.com> wrote:
>
>I don't know about that, Bill... if I used the word "merge" in my "story
>problem" and the prospective employee/contractor did not automatically reach
>for the COBOL 'MERGE' verb, I think I'd be at least a tad chary of ascribing
>COBOL expertise to that candidate.....
I've written lots of match and merge programs where the MERGE verb
wasn't appropriate. I expect anybody I hire to be able to do the
same. If I was taking this interview, I would mention that
possibility and ask for more information. Getting more information
is what good programmers do.
| |
| Howard Brazee 2006-12-27, 6:55 pm |
| On Tue, 26 Dec 2006 20:42:00 -0500, "JJ" <jj@nospam.com> wrote:
>As for your situation, where you said you never wrote a program from
>scratch - I know what you mean. We usually started with a template, rarely
>a blank slate. But when we had people do a test like this, we always
>allowed them to use the help file that contained the Cobol manual. I
>figured, heck, I had been programming in Cobol for 20+ years and I still
>occasionally used the manual, so there's no reason this person shouldn't be
>able to also. It was a programming skills test, not a memory test.
Back when the SELECT / ASSIGN statement syntax was more meaningful - I
didn't really know the syntax, I just knew which programs to clone
them from.
| |
|
| HeyBub wrote:
> LX-i wrote:
>
>
> Yeah, but at what cost. You had to make room for something your experience
> says will probably never be used.
>
> Say goodbye to the fifth grade.
Not necessarily. Granted, today I could probably write a MERGE without
looking at a manual - but three ws from now, I'd probably forget the
syntax and have to look it up again. Rather than try to memorize every
possible option, I instead like to dedicate a portion of my memory store
to knowing *where* things are documented. That keeps me from having to
memorize the manuals, leaving room for lots of 5th grade memories - even
the one about the girl that wouldn't go out with me.
(On second thought, maybe I *should* study this MERGE thing a little bit
more...)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
"Who is more irrational? A man who believes in a God he doesn't see, or
a man who's offended by a God he doesn't believe in?" - Brad Stine
| |
| Howard Brazee 2006-12-27, 6:55 pm |
| On Wed, 27 Dec 2006 11:00:28 -0600, LX-i <lxi0007@netscape.net> wrote:
>Not necessarily. Granted, today I could probably write a MERGE without
>looking at a manual - but three ws from now, I'd probably forget the
>syntax and have to look it up again. Rather than try to memorize every
>possible option, I instead like to dedicate a portion of my memory store
>to knowing *where* things are documented. That keeps me from having to
>memorize the manuals, leaving room for lots of 5th grade memories - even
>the one about the girl that wouldn't go out with me.
I'm like that with most computer languages. And most languages I am
familiar with. But CoBOL has become native to me - I could leave it
for a decade and come back without having to re-learn old stuff. Sure,
there are occasions when I need to pull out my English language
dictionary with my native English - but CoBOL isn't a big language.
(Now I would have to pull out the manual to do OO CoBOL - not my
manual though which doesn't have any of that).
| |
|
| Howard Brazee wrote:
> On Wed, 27 Dec 2006 11:00:28 -0600, LX-i <lxi0007@netscape.net> wrote:
>
>
> I'm like that with most computer languages. And most languages I am
> familiar with. But CoBOL has become native to me - I could leave it
> for a decade and come back without having to re-learn old stuff. Sure,
> there are occasions when I need to pull out my English language
> dictionary with my native English - but CoBOL isn't a big language.
> (Now I would have to pull out the manual to do OO CoBOL - not my
> manual though which doesn't have any of that).
That last part bring up another conflict I have - I could probably put
forth the effort to learn OO COBOL, and make some small application with
it. I'm sure I would learn a lot along the way. But would it benefit
me past the "gee-whiz" of being able to say that I did it? (Granted,
the "gee-whiz" pull is pretty strong - but I've got some other stuff to
do with already-deployed applications too.)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
"Who is more irrational? A man who believes in a God he doesn't see, or
a man who's offended by a God he doesn't believe in?" - Brad Stine
| |
| Howard Brazee 2006-12-27, 6:55 pm |
| On Wed, 27 Dec 2006 11:53:49 -0600, LX-i <lxi0007@netscape.net> wrote:
>That last part bring up another conflict I have - I could probably put
>forth the effort to learn OO COBOL, and make some small application with
>it. I'm sure I would learn a lot along the way. But would it benefit
>me past the "gee-whiz" of being able to say that I did it? (Granted,
>the "gee-whiz" pull is pretty strong - but I've got some other stuff to
>do with already-deployed applications too.)
In my environment OO is limited to the user interface side. If all
I'm doing is accessing the database (or screen scraping), and
providing XML for the web services - Java works quite nicely - but not
particularly because Java is OO.
I'm seeing a separation of business rules and user interfaces which is
getting wider. Moving the business rules more into the database
realm is what is finally making CoBOL less pervasive.
| |
| HeyBub 2006-12-27, 6:55 pm |
| LX-i wrote:
> That last part bring up another conflict I have - I could probably put
> forth the effort to learn OO COBOL, and make some small application
> with it. I'm sure I would learn a lot along the way. But would it
> benefit me past the "gee-whiz" of being able to say that I did it?
> (Granted, the "gee-whiz" pull is pretty strong - but I've got some
> other stuff to do with already-deployed applications too.)
You're flirting with the 4th grade not even being a memory...
| |
| yankeesoft 2006-12-31, 7:29 am |
| I have done COBOL programming for over 20 years also.
I had one situation where a company asked me to write a program from scratch, and the interviewer sat right next to me to see me coding.
I stood up, walked out the door without even saying Goodbye.
At this stage in technology, any company using COBOL and getting a senior programmer to come in for an interview, should roll out the red carpet, serve him a gourmet lunch and just casually ask him or her one question only:
What are the four divisions in COBOL.
Anyone asking more than that should be shot. |
|
|
|
|