Internship
Summer 2005 CS 454
By Jim
Ford-Fleming
|
|
Section 1.1 Finding
Out About Job Openings
Section 1.2 Advertising
Your Availability
Section 1.3 Landing
Your Internship
Section 3.0 – Daily Activity Log Excerpts
Section 4.0 – Career Advice for Current CS Students
Section 5.0 – Internship Value
Section 1.1 Finding Out About Job Openings
Finding an internship that will be
interesting and insightful is a difficult job and it is very important to start
the search early. If I had known that at the beginning of my search it would
have made the process so much easier. By the time I started my search I found
that many doors had already been closed. I had originally thought of pursuing
an internship with a government agency or security firm, but such internships
require a security clearance involving a lengthy approval and background
checking process.
Towards
the end of fall semester one of my current professors suggested a few positions
that may be worth looking into here at the university. They may not have been
security related but at least one of them involved programming. Since the
position had not been listed yet I sent an e-mail to the project lead
expressing my interest, to which he replied and suggested we set up an informal
meeting.
During
the meeting Phil Riley explained what he could about what it is they were doing
and answered any questions I had. At the end he said that he was not completely
sure but thought the position would be open to applications sometime over
winter break on the JMU Student Employment Web-Board. So, when the time came I
filled out an application and sent my résumé. In retrospect, the search need
not be applying for countless positions hoping to get one but rather checking
with people you know and finding something through connections.
Section 1.2 Advertising Your Availability
The résumé is perhaps the most
important part of the application process. While an employer is looking through
applications if there are very many it is all too easy to get lost in the
crowd. The résumé is your first chance to leave an impression and get offered
an interview. That said it is important to customize résumés to each position
you apply for, generic résumés have a greater risk of getting overlooked. It is
also helpful to get several opinions, ask friends, roommates, and professors if
they can look over it and tell you what they think. It is important to write
anything you can think of about yourself that would make you a better choice
than someone else. The main difficulty you should have in writing a résumé is
fitting it on one page, some employers say one to two pages but it is good to
keep everything short and sweet unless you really do have enough experience to
justify several pages.
The Introduction to Technical and
Scientific Communications class is a very helpful source when it comes to
formal writing. I relied heavily on everything I was taught from using positive
active words down to using specific types of fonts to add a level of
professionalism. In fact everything I said earlier I was taught in this class,
this is an important one to pay attention in.
Section 1.3 Landing Your Internship
After I learned about the position I
contacted them to express my interest and learn more. So once the position was
posted I sent my application and résumé and within a week I was offered an
interview. The interview was with Phil Riley, the CIPP’s NSRAM(Critical
Infrastructure Protection Projects Network Security Risk Assessment Model) project
lead, and even though I knew the interview was probably going to be fairly
informal I thought it would still be good to look professional as possible. The
interview took place at ISAT in Phil’s office and was informal just as I had
expected. After he had asked his questions he asked if I had any but since I
had already met with him and did not really prepare any before hand I did not
have very many. As the interview ended Phil said he would try to get back to me
in a week or two.
In
retrospect I probably should have prepared a little better because there were a
couple of questions I felt I could have answered better and did not completely
articulate my skills and knowledge. Maybe the problem was I think the
traditional method of preparing is silly. Some people make lists of questions
and come up with answers which I think is a waste of time instead I think it is
a better use of my time to collect my thoughts which makes answering questions
easier, especially if they have questions that are meant to throw people off
balance. It is also important, particularly with positions involving
programming to bring something you have coded and are particularly proud of.
This more than anything will speak to your knowledge, competence, and ability
as a programmer.
After
the interview I wrote an e-mail thanking Phil for taking the time to interview
me and once again expressed my interest in the position. This is where you need
to be careful, finding the balance between showing interest and badgering. Two
weeks passed and still no word so I wrote another e-mail inquiring if the
position had been filled and received an e-mail that they had not made a
decision yet because they have been busy and they would try to get back to me
sometime next week. Another week and still no word and spring break was upon
me, since there was little chance I would get a reply during spring break or
could even do anything even if I had I waited until classes started again to send
another e-mail. This time Phil went ahead and offered me the position. This
just goes to show that persistence pays off, if I had not kept at it I am not
sure I would have been offered the position.
I worked for the CIPP (Critical
Infrastructure Protection Project) at JMU and was supervised by Phil Riley. I
was a student programmer and worked forty hours a week with three other student
programmers. Hours were generally nine to five, Monday through Friday but the
work environment was fairly casual so when we came and left was generally left
to our digression as long as it did not become a problem. The students worked
in a small computer lab on the second floor of the ISAT building, each of us
having our own computer. Since the project is running off of a grant we did not
really have any customers however the ultimate goal is to develop the NSRAM
(Network Security Risk Assessment Model) into a marketable product.
When I started the team was in the
middle of redesigning the tool to improve performance so students were given
small sections to code while Phil worked on the core engine. Sometimes we would
have to work on something else if the code required engine functionality that
had not yet been implemented. All in all we had enough to stay busy.
Coming into the job I was expected
to be aware of basic programming concepts and JAVA, professional experience
would have been preferred over academic but being affiliated with the
university they felt it was partially their responsibility to educate. The
first half of my internship was definitely a learning experience. My first
assignment was to familiarize myself with all the development tools the team
uses including Eclipse (Coding tool), XDE Tester (Tests functionality and
creates reports), and ClearCase (Document Repository). After that there was the
task of becoming familiar with the NSRAM tool and how everything works from the
developer’s perspective. While one student emphasized reading design documents
over and over to gain an understanding I found that actually starting to code
something gave me a much greater understanding of how things worked. Sure the
design documents give a general overview of how everything works but after
reading it a second time, as suggested, I had no greater understanding that the
first time I read it and really did not do anything as far as teaching me how
to program using these concepts. Another realization I had while trying to
understand how everything worked was that what you learn in the classroom is
completely different from what work is like as a developer. First of all there
is no coding in a text editor and command line compilation and trying to figure
out errors on our own, in fact this is the first thing they break you out of,
they expect the use of a professional editor and emphasize the use of
debuggers, something greatly overlooked and not even mentioned. I found myself
pushing aside everything but the most basic of programming concepts I was
taught in the classroom and rethink any preconceptions I thought I knew about
programming.
Once I gained my footing and began
to understand how I should be programming the tool Phil asked me to revise the
model view code part of the GUI, as simple task to start me out. He also
suggested that I familiarize myself with JGo, which is the graphical package we
used to display elements in the GUI. After becoming familiar with JGo and
drawing heavily upon the API’s I started tackling my assignment. It took me a
while to start out because I was in completely foreign territory, in class you
get used to knowing what every part of your program does and it can be a bit
unsettling knowing less than a fraction and integrating your own code with
other people’s work. Staring out Phil said to ask if I had any questions and to
do whatever I think was needed to get the job done, code-wise, and any problems
will be sorted out during a code review. There was also the problem of writing
code for unimplemented features in which all you can do is write a note and
write what you think will work and return to it later. Towards the end of the
first half of the internship I started feeling really comfortable programming
in the tool because of everything I had learned along the way with a lot of
help from Phil.
During the second half of the
internship the students were given the task of creating a scenario to model for
an upcoming project presentation. First we had the problem of picking a general
scenario, such as electrical system failures or traffic models, and then had to
write up the scenario and send it out to the team for comments and concerns.
Then a meeting was set to discus the proposal as a team and get approval. Once
that was finished there was a long process of meetings and revisions coming up
with details about the behavior of the model which took about a week. After
that document was approved we began working on outlining implementation
including listing out the elements needed and how they interact with each other
and writing pseudo-code where it was appropriate. When working on an intricate
network of elements it really is important to outline these things because we
ran into several problems and resolved them in the outline phase instead of
becoming knee deep in written code rendered useless because there was an
unforeseen problem.
Section 3.0 Daily Activity Log Excerpts
I am still revising the code for model
view in the GUI, yesterday I started implementing the right-click menu’s and
ran out of time so I needed to pick up where I left off. Whoever wrote this
code in the first place needed to make up their minds there are three relevant
classes to what I am trying to do in model view and each one has a mouse
listener and a few have more than one.
Well I fixed a potential problem with
my selection code., cleaned up the listener code, and labeled them so I do not
spend another couple hours down the road figuring these things our again. I got
rid of the ones I could but some are required by parent classes. As it turns
out I had my code right in the first place, all I needed to do was add the
different options to an xml document somewhere, thanks Phil for helping me
figure that one out.
I think that should be just about it
for model view, maybe I should go back and look over some of the code I did
earlier this summer since I finally have a decent understanding of how things
work.
Section 4.0 Career Advice for Current CS Students
First make sure you have the basic
CS courses under your belt such as the JAVA programming courses and Data
Structures. Then if you are looking for a job, talk to your professors they are
more than willing to help and give advice, they may even have some connections
or know people you can talk to. It is also a good idea to take the Introduction
to Technical and Scientific Communications class because it teaches you how to,
at the very least, make your writing more professional.
When
you are offered an interview, look your best and prepare beforehand, you may
not necessarily need to come up with specific questions simply think of what
you have done, what you can do, and what you want out of the position. Go into
the interview relaxed, whatever happens there is no use worrying about it
because that is when you have a greater chance of making a mistake. Being calm
also helps convey maturity, experience, and professionalism. After the
interview thank them for their time and express your interest in haring back
from them. If they have given you a date and you still haven’t heard from them,
keep on it until you get an answer and at the same time do not make a pest of
yourself, if you still have not received an answer give it a week until you
contact them again.
If
you have never done any programming professionally, put aside all but the most
basic concepts you have learned in class and learn from scratch otherwise you
will just confuse yourself. Do not be afraid to ask coworkers for help, in my
case they did not always know the answer so I went higher up to get an answer.
Finally
if you are looking at getting an internship with the government, check early
because jobs that require security clearances usually have an application
deadline in October assuming your applying for the following summer.
I have always been a little better
at coding than most Computer Science students but nothing prepared me for how
different it would be than what I learned in class and on my own. Programming
professionally requires you to be more flexible in that you will not know how
everything works and how to write code to receive and/or give certain
parameters. At the very least I have some professional programming experience
under my belt which will make finding and doing my job after I graduate that
much easier.
At the very least I am a little more
confident in my abilities and my ability to make it as a professional programmer.
I also saw the need for planning before you start programming, at least if it
is a complex problem or involves many parts working together. I also became
better at expressing ideas in a manner that other people can easily understand
and to speak up if I think I see a problem. All in all this was a very
rewarding experience and has helped me grow technically and professionally.