Alright a new position came available at my current job in which they are getting rid of the contractor and wanting a full time Junior Unix Admin.
This is the position I've been wanting at anyplace and will go for but if you look at the requirements and responsibilities below, all of them I am fully qualified and can do except really the Perl scripting. I mean I know some of the basics but they want you to know it as I heard they shot down peeps already who knew everything but Perl.

So my question is this, since I've already been wanting to learn more in depth with perl anyways, what do you think it will take to prove I can do it? Hit up the books and study mad perl for the next month or two months, hope the job is still available (might be since they still looking for a Senior Unix Admin for past 3 months) or give myself a few weeks.. learn some more basics.. write a few scripts on my own to familiarize, then go for it?
As you can see, I'm taking a break from reading my Perl book.. :P


JUNIOR UNIX ADMINISTRATOR

Responsibilities:

Monitor applications, processes and connectivity on all production and non-production systems and respond as needed - I can do this as I'm already familiar with most of our servers, layouts, etc.
Install and Troubleshoot production and non-production servers and applications as needed - Piece of cake, I can do this in my sleep..
Deploy and maintain software and packages - Another simple task...
Write systems maintainance scripts to assist with monitoring and automation of tasks - Give me a command prompt and I'm there, except when they want it in perl of course..
System and network security and monitoring I'm there, maybe even block the spam everyone been getting at work too since our current admin is lazy.... And if there is some security I get stumped on.. hell, I can always ask unSpawn
Network architecture and design - I can do this, done it before..


Requirements:

2+ years relevant technical experience - Got it..
RedHat Linux installation and management - Easy as pie.. I'll just have to get use to RPM instead of installing by source.
Solaris installation and management - One step away from being certified...
Kickstart - Kicked it before..
Apache - Easy enough, configured and host my own domains myself..
Open Source software package building - Even easier than RPM's...
RPM package management and building from source - Give me a challenge..
Solaris and RedHat Linux administration experience required - Hmm.. hopefully they don't want just commercial experience.. hehe..
Must be familiar with the following protocols: TCP/IP, HTTP, HTTPS, SMTP, POP3, IMAP4, FTP, DNS, NFS, NTP, DHCP, IPSEC, SQL, SSH, SMB/NETBIOS - All pretty easy.. got most of those running on my own home network w/servers..
Perl and shell programming experience - Arrghh.. just need to learn Perl inside and out..

Trickykid,

My advice, bottom line, is: Go for it and apply for the job now. If you wait, most likely the position will be filled by the end of the summer/fall. Right now, in this economy, most companies can afford to be pretty picky about who they choose to hire, and consequently the overwhelming majority of hiring managers these days are posting wish lists rather than actual job postings. If you've got *all* the bases covered except for one, dude, seriously, just *APPLY*. For the past couple of months I have been struggling to find qualified people to hire, and believe me, the 2 types of highest quality candidates are current employees, or referrals from current employees. Based on the quality of your many posts just here at LQ, I have no doubt that you would be able to run circles around any other candidate. There's no doubt in my mind that your experience is *far* above the Junior level - you might consider applying for a Senior position. If anyone questions your credentials, you might simply point them to this board.

Anyway, not to get all philosophical, but 2 comments that seem relevant here are: "If you don't ask, the answer automatically is No", and "Don't tell me how hard you work, show me how much you get done." On the first point, there is no downside or penalty for submitting your resume. If things don't work out, the worst outcome is that they say "Sorry, we've decided to go with someone else." BFD. It would be a disappointment, but then again, you'd be no better or worse off than you were before. As the cliche goes, nothing ventured nothing gained. On the other hand, if they say Yes, then you're in the Bonus Zone. Congratulations. On the second point, there are an unbelievable number of BS artists who can talk a good talk, but can't walk the walk. In the business world, what matters is A.) execution and B.) the flexibility and right attitude to learn new things. In other words, things in the tech world change overnight, and if you can demonstrate that you can not only adapt to the constantly changing landscape, but actually thrive in it, well, assuming that the hiring manager isn't an idiot and can recognize that, then you're in. As far as I'm concerned, I'd be far more interested in hiring someone who might not have the exact expertise that I might wish for, but does have a solid background and can demonstrate a real interest in learning something new, over someone who thinks they already know it all.

I guess the real question to ask yourself might be: Would the person who might get hired for this position really know anything that you didn't? Granted, you're still studying Perl, but 3 months down the road, would there be any difference between you (who already knows the company's infrastructure and systems) and some newcomer (who might know a little Perl, but might need 6 months to learn the company's insfrastructure and systems?) I suspect the answer would be No. Therefore, I'd encourage you to submit your resume. Whatever you might not know about Perl today will be irrelevant a couple of months down the road, after you've had some time to study. Good luck with whatever decision you make -- J.W.

Well thanks for the encouragement.. I might check into it further now that you mention it and brought up some valid points. Though I think they have the contractor there for another 2 months, I do know the company is never in a rush for anything though, they've hired or promoted within and actually let them wait 2 months before they've taken on their new roles.. so I have no doubt in my mind they might be looking for a month or longer..

But my roomate knows the admins better than I do, I'll have to get him to get a word in for me, etc.

Thanks again..

Apply. As stated above, it won't hurt you to apply, and it can certainly help. I would recommend applying for both positions and hoping for the best.

As for Perl, it's a piece of cake if you've already got shell scripting and C programming down, and is still pretty easy if you don't. Just pick up the O'Reilly box set on Perl (with the CDs so you can install the docs on your system) and start programming. Once you start, you'll see that Perl solves so many of the issues related to getting quick shell scripts done right (you can get them done with c-shell or bourne shell, but they're not always quick and they're not always right).

The real key is to use the right tool for the right job. Once you know which tool to use, you've already solved half of the problem.

When you go in for your interview, be honest. Don't say you know more than you do, and don't say you know less than you do. Be able to explain how you solve problems and why you chose the tool you've chosen. The biggest problems with interviewees we've had are; 1) lies -- the employer will ALWAYS figure it out, and 2) Not really knowing what they're talking about (not necessarily the same as a lie), and trying to explain something they didn't really understand. If you don't know, say so, but be able to say how you would find out.

I would just make sure you have a grip on the basics of input, output and manipulation (I would say they are the same for all languages):
Read from STDIN
Read CLI args
Read and write to files
Communicate with other programs/scripts
Manipulate and extract from strings

Using more specialised libraries for connecting to services like pop or imap I would argue are not required. If I was writing a program to do a job like that I would read up on the protocol and libary before hand. There is no way you can know everything (well - I know my brain ain't big enough). I try to sell my self on flexability and abilities to learn, anything I don't know, quickly (google is my best friend ).

Anyway - Good luck!

by all means, apply for the job; these guys are right. you have nothing to lose and the least you will gain will be to identify yourself as an employee who is willing and wanting to get ahead. then i would get several instances of perl in use on your system(simple to complex) and integrate them into your intensified perl tutorial, so that you may be able to demonstrate an understanding that is relevant to your organization(which may represent a subset rather than the whole of perl and which may be picked up in less time).

Just yout of interest - what do you mean by "several instances of perl"?

perhaps i should have said 'instances of perl usage" already on the system, i.e., perl programs which have been written to do things on the system. i would think at least some of these would be available and scrutiny of them would possibly narrow the direction in which to focus trickykid's effort to be helpful as a perl programmer for his company. of course, the requirements of the job may be such as to demand a broad and maybe almost complete grasp of the language, but knowing what you can do now, what you can do soon and what you are willing to learn to do to be useful to a particular organization can't hurt.

go for it! hit the books.

Drew, go for it man, I know everybody's situation is different from case to case but in my case if I didn't put my foor in the door I'd still be an intern, well I didn't as much put my foot in the door but one of the days I was asked by my manager (Software Developement and Support side) if I could come on Saturday to help Engineering and LAN/WAN groups to install new switches, and I said sure why not, the following week the LAN/WAN Department Vice-President came up to me with an offer to join their team as a Network Specialist, and she said she understood that I have a lot to learn but she was confident enough to give me these responsibilities, and now I am a Network Specialist with partial UNIX administration responsibilities (these came out from our UNIX administrator - a very cool guy - he knew I was *NIX addicted, and I always put my nose around UNIX administration side). So go get it, and Good Luck.
Boris.

I don't know much about your situation, but I do 100's of interviews a month.
1. It is not always what you know, but knowing how to find the answer.
2. 9/10 people get shot down, because of the way they present themselves. For instance, if you are open to telling them you don't know perl very well, but you are willing to take a couple of courses on your own time at XYZ School, you show initiative.
3. Be confident about your abilities, and let them know you are familar with their system, don't take it for granted that because you work there that they know your abilities.
4. Since they are looking for a Senior Programmer, the odds are that the person doing the interviewing has no clue as to what the junior programmers position really is, so you need to define it for them, such as telling them that you can rid them of most of the spam, and about the servers you run.

Never take for granted that the decision makers know anything about you, in most cases, they only have second hand knowledge. It is usually a good idea to talk with your present supervisor, get their blessing(per say), and get them involved in talking good things about you. And remember, from the moment you put in for the position, you are being watched, be sure your performance is well above their norms.