Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

Job Questions

by PerlSufi (Friar)
on Nov 18, 2013 at 15:17 UTC ( #1063118=perlquestion: print w/replies, xml ) Need Help??
PerlSufi has asked for the wisdom of the Perl Monks concerning the following question:

Hello Monks, I have only been programming perl in a professional setting for about 8 months now. I currently use it to create documents of various kinds like pdf, postscript, excel, etc in a small-medium size shop kind of setting. Recently, I was contacted by a recruiter for a job developing CGI for a large web hosting company. After the initial phone interview, I decided to go through with the interview in the near future- at least for the experience and to see if they pay more. I have composed some questions to ask them in my mind that I did not have the experience to ask for my current $work..

- How much of what I am going to be working with is legacy code?
- How closely do the scripts conform to perl best practices? Do they use strict and warnings?
- How much of the job entails talking to clients?

Those are the main things I would like to know, aside from technical details like what OS I would be using, etc. I was wondering if any of you wise, experienced monks had suggestions for other questions to ask and what to look for in a perl $job in general. You guys have been an immense help and I certainly wouldn't be here without you. Thanks, PerlSufi

Replies are listed 'Best First'.
Re: Job Questions
by daxim (Chaplain) on Nov 18, 2013 at 16:11 UTC
      Awesome, daxim. Thanks a bunch. There are several questions on that first link that would be answered by 'yes' at my current $work, that should be answered 'no'. ;) ie: Do you have code that "no one knows what it does"?

        There's plenty of code that may as well be. I've had a few projects dumped in my lap with "Here, make this work, we need it done in a week." Then you just start adding print statements and slowly build your map around the code. It's tedious, and sometimes (actually almost always) painful, but you will gain a lot of respect for being autonomous and you will have a much better grasp of how the code works.

        Three thousand years of beautiful tradition, from Moses to Sandy Koufax, you're god damn right I'm living in the fucking past

Re: Job Questions
by boftx (Deacon) on Nov 18, 2013 at 20:05 UTC

    I have just recently added the following questions to my list:

    • Do you have QA/Staging environments that accurately mirror the production environment?
    • Do you use code review, and if so, must new code be approved by review before going to QA?
    • Do you use dev and story branches or is it held that master must always be ready to push to production? If the latter, how do you avoid having un-reviewed code or code that has not gone thru a proper QA being pushed by accident?

    These questions might seem a bit forward given this stage in your career, but as time goes on you will understand why they could play a role in your deciding to take a given job.

    It helps to remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.
      Thanks, boftx. Thanks to all of you, actually. Great insights!
Re: Job Questions
by BillKSmith (Vicar) on Nov 18, 2013 at 16:48 UTC
    Given the previous comments, it may be hard to ask, but one thing you really should know is the 'quality' of the requirements you will receive.
Re: Job Questions
by taint (Chaplain) on Nov 18, 2013 at 16:06 UTC
    So, big corporation, is it your hope, or intention to make me the wealthiest person on the planet?

    Good question -- no?

    Seriously, I don't mean to diminish, you, or the serious nature of your question. But honestly, isn't that really the bottom line?

    A couple of thoughts come to mind;
    First impressions are everything, and they do judge a book by it's cover.

    I'd hesitate to elaborate much further than that, except to say, that be cautious in your questions, lest you appear to be interrogating them. Always ask your questions in such a way, as to appear that your primary interests concern their best interest -- even if they aren't :)

    Best wishes, and good luck!


    #!/usr/bin/perl -Tw
    use Perl::Always or die;
    my $perl_version = (5.12.5);
    print $perl_version;
      Haha, nice question taint.. and good recommendation on how to ask. I will definitely take that into consideration.
        Really, I wish you all the best -- good luck!


        #!/usr/bin/perl -Tw
        use Perl::Always or die;
        my $perl_version = (5.12.5);
        print $perl_version;
Re: Job Questions
by sundialsvc4 (Abbot) on Nov 18, 2013 at 19:59 UTC

    • Only the code that I write is Perfect, Pristine, and Timeless.   (There are only so many Perfect Coders allowed per planet, and I’m it.)   All the code you’re likely to encounter will be old-crap that’s barely hanging-on on life support.   ;-)
      • Seriously, most code is “already existing,” therefore “legacy.”   The new code that you write, as soon as you write it, becomes part of that “legacy.”
      • So, it is always an important skill to be able to assess the present-state of a piece of code, to fully understand the desired future-state, and then to be able to articulate and to estimate what it will take to move it forward ... and at what business-risk, and with what allowances for Sergeant SNAFU ... and how it will be testable and how it will be tested ... before you and/or your team starts to write it.
    • Most of the time, you will find these practices are followed, because people really do need to write stuff that is more-or-less stable and that more-or-less stays that way.   However, the code has been changed, many times and by many people over many years for many reasons.   This is inherently de-stabilizing to software.   The work practices are often most-important:   how do they handle problem-reports and change requests?   Do they use source-code control?   What is their deployment procedure, and how do they recover from / roll back a deploy?   How do they “mentor” new team members, such as you would be?   These are things that you should ask during that same interview.
    • Most programmer positions have little direct client contact.   But you will still need to develop the ability to converse effectively with a non-technical person about a highly technical subject.   You will need to be able to communicate effectively with members of your team, including those who know more and those who know less than you (about a particular subject area), and to work with them effectively as a team.   Computer software is not the work of one person.

Re: Job Questions
by stonecolddevin (Vicar) on Nov 18, 2013 at 16:49 UTC

    I've found that asking them what you can do to be successful (provided they haven't immediately just mentioned exactly that), and maybe cite some experience on what's helped you be more successful in the past. Get a grip on their expectations, and they tend to start spilling more and more candidly about the environment and things you'll be working on.

    Three thousand years of beautiful tradition, from Moses to Sandy Koufax, you're god damn right I'm living in the fucking past

Re: Job Questions
by Voronich (Hermit) on Nov 20, 2013 at 15:37 UTC

    The fact that you're thinking this way and have these specific questions already means you're in pretty good shape out of the gate.

    Other people have covered the sensible additional questions and issues pretty well I think.

    Someone's perceptions of how well they follow best practices, et al, are almost always going to be better than they are. What I think you really want to hear is "not as well as we'd like, but we're pulling in that direction." More likely you'll hear "Yes, We're leet!" in an attempt to impress. Which, meh, they're human, it's what to expect.

    You could cut through a lot of bullshit if you could get them to give you a specific real life example of a couple assignments. Reaction to that kind of a question will tell you volumes.

      Great response, Voronich. Good call on getting them to give me some real life examples, too. I'll see if I can do that

        People can be hesitant to do that, which can be telling of a couple things. They might not want to say because it reveals too much about their business in some way. Or perhaps because they're bashful about their code. You'll be able to tell by the interviewers behavior I'm sure.

        I was asked a really great, detailed, squirrely debugging/diagnosis question a few jobs ago. After a really entertaining 10-15 minutes or so of asking follow up questions to try and solve the problem, I diagnosed the problem and provided the sequence of steps required to solve the problem. Then it suddenly struck me what was going on. It was easily as much fun as I've had on an interview in a very long time.

Re: Job Questions
by Bloodnok (Vicar) on Nov 19, 2013 at 10:56 UTC
    I'm not sure if it isn't a tad off-topic but I've always found i.e. without exception, that the best jobs I've taken - whether perm or contract - have been those where the interviewer(s) spend as much time 'selling' the company as giving me the 3rd degree.

    The two instances where the interview was all about the 3rd degree were jobs I wished I'd never accepted and left both after less than 6 months - since when the above maxim has worked fine ... for me anyway:-)

    A user level that continues to overstate my experience :-))
      What do you mean by the 3rd degree?

        Gee, that would be really hard to Google.

          - - (for lack of effort).

        Update: Search Term: "the third degree"
        Google's response:

        Content brief of first hit:

        Third degree (interrogation) - Wikipedia, the free encyclopedia‎ The third degree is a euphemism for the "inflicting of pain, physical or mental, to extract confessions or statements". In 1931, the Wickersham Commission found ...

        Afterthought: mid-part of first para probably should have been "...would have been really..."

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1063118]
Approved by Arunbear
Front-paged by Arunbear
[marto]: Corion, I'll talk to you later, but that are is generally fine :)
[hippo]: Just not sure that the expense and hassle is worth the benefit.
[LanX]: expense? .... meeting ppl is inspiring ...
[LanX]: ... and it might be your last chance ... I heard Perl is dead! OO

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (11)
As of 2018-06-20 09:39 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (116 votes). Check out past polls.