perl interview questions

perl interview questions

am 21.04.2011 06:49:00 von jyoti

--0016364268b5be0b4d04a166759d
Content-Type: text/plain; charset=ISO-8859-1

Hello All,

Please give me any link or any tutorial which will be helpful for
preparation of PERL interview.

Thanks in advance.


----
Jyoti

--0016364268b5be0b4d04a166759d--

Re: perl interview questions

am 21.04.2011 06:52:42 von Doug

2011/4/21 Jyoti :
> Hello All,
>
> Please give me any link or any tutorial which will be helpful for
> preparation of PERL interview.
>

There are lots. But, doesn't google give you any info you want?

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Re: perl interview questions

am 21.04.2011 07:18:08 von Alan Haggai Alavi

Hello Jyoti,

> Please give me any link or any tutorial which will be helpful for
> preparation of PERL interview.

Please read `perldoc perlfaq` (http://perldoc.perl.org/perlfaq.html). It
is a collection of frequently asked questions which will certainly help
you at an interview.

Regards,
Alan Haggai Alavi.
--
The difference makes the difference

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Re: perl interview questions

am 21.04.2011 08:23:36 von Shlomi Fish

Hi Jyoti,

On Thursday 21 Apr 2011 07:49:00 Jyoti wrote:
> Hello All,
>
> Please give me any link or any tutorial which will be helpful for
> preparation of PERL interview.
>

First of all, see:

* http://perl-begin.org/learn/Perl-perl-but-not-PERL/

(It's either "Perl" or "perl", but never "PERL". It is a ).

Then see the other resources at http://perl-begin.org/ . There are some
tutorials at http://perl-begin.org/tutorials/ and some books (some of them
online) here: http://perl-begin.org/books/ . The most recommended book, if you
already know a different programming language is probably "Modern Perl" (
http://perl-begin.org/books/#modern-perl ) - otherwise, you should look at
Beginning Perl ( http://perl-begin.org/books/#beginning-perl ) first. Both are
available online for free download.

Regards,

Shlomi Fish

--
------------------------------------------------------------ -----
Shlomi Fish http://www.shlomifish.org/
List of Portability Libraries - http://shlom.in/port-libs

Chuck Norris does not code; when he sits at a computer, it just does whatever
he wants. (By: Kattana.)

Please reply to list if it's a mailing list post - http://shlom.in/reply .

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Re: perl interview questions

am 21.04.2011 15:07:31 von Luis Roca

On Apr 21, 12:49=A0am, jyoti.bans...@gmail.com (Jyoti) wrote:
> Hello All,
>
> Please give me any link or any tutorial which will be helpful for
> preparation of PERL interview.

Do you have a job description of the position you're interviewing for?
Is this a web development position? Is this a systems administrative
job? It's difficult to give you prep questions for an interview
without even knowing what the job title is you are interviewing for or
what kind of work this company/companies do. ;-)

However for some general topics chromatic wrote a list of expertise
managers -should- be asking candidates to have. It's worth a look:

http://www.modernperlbooks.com/mt/2011/01/how-to-identify-a- good-perl-progr=
ammer.html

Again, if you provided some more information about the position (the
company's job description) I'm sure people can give you more specific
help =96 good luck!

Luis


--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Re: perl interview questions

am 22.04.2011 02:45:21 von Brandon McCaig

On Thu, Apr 21, 2011 at 9:07 AM, Luis Roca
wrote:
> Again, if you provided some more information about the position
> (the company's job description) I'm sure people can give you
> more specific help â€=93 good luck!

Wouldn't it be nice though if the people conducting interviews
already knew enough about what they should ask and how to
interpret it...? :-X

Pass the responsibility on to the people that will have to live
with the hire. :P


--=20
Brandon McCaig
V zrna gur orfg jvgu jung V fnl. Vg qbrfa'g nyjnlf fbhaq gung jnl.
Castopulence Software ..org>

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Re: perl interview questions

am 22.04.2011 03:34:49 von Owen

> On Thu, Apr 21, 2011 at 9:07 AM, Luis Roca
> wrote:
>> Again, if you provided some more information about the position
>> (the company's job description) I'm sure people can give you
>> more specific help â€=93 good luck!
>
> Wouldn't it be nice though if the people conducting interviews
> already knew enough about what they should ask and how to
> interpret it...? :-X
>
> Pass the responsibility on to the people that will have to live
> with the hire. :P




Did not this thread start with a problem about 20 cows?

It seemed to be a general "IQ" type of question and any answer would
do as long as you could explain it.

In my mind the simplest answer would have been to randomly split the
herd in two. The probability of each group of ten meeting the criteria
would be almost the same?


Owen





--=20
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Re: perl interview questions

am 24.04.2011 15:48:10 von Akhthar Parvez K

Hi Jyoti,

On Thursday 21 Apr 2011, Jyoti wrote:
> Please give me any link or any tutorial which will be helpful for
> preparation of PERL interview.
>

I don't honestly think someone would write an article or tutorial about "preparing for a Perl interview". That should actually split into two: Learning Perl and Preparing for an interview.

And here's some free advice and feel free to take it if you like :-D

#1 - Never learn for an interview; but learn for the job.
#2 - Apply for an interview only if you're fit enough. - If you don't think your skill set don't match with the requirements of the company, just don't apply. You're thus doing a favor to yourself and everyone else.
#3 - Once you apply, just be ready to face an interview any time.
#4 - Trust your abilities and be confident - This is the most important part and would let you handle the interview in the best possible way.
#5 - Never give a wrong answer - If at all you receive a question that you don't know, do not panic, just be smart and divert the question so you can answer what you know.
#6 - Please your interviewer with well explained responses.

Hope that helps!

--
Regards,
Akhthar Parvez K
http://www.sysadminguide.com/
UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity - Dennis Ritchie

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Re: perl interview questions

am 24.04.2011 16:13:18 von Shawn H Corey

On 11-04-24 09:48 AM, Akhthar Parvez K wrote:
> #5 - Never give a wrong answer - If at all you receive a question that you don't know, do not panic, just be smart and divert the question so you can answer what you know.

If you don't know the answer, say so. Then state how you would go about
finding the answer. Do not reply on clever tricks in an attempt to fool
your interviewer.


--
Just my 0.00000002 million dollars worth,
Shawn

Confusion is the first step of understanding.

Programming is as much about organization and communication
as it is about coding.

The secret to great software: Fail early & often.

Eliminate software piracy: use only FLOSS.

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Re: perl interview questions

am 24.04.2011 16:36:46 von Akhthar Parvez K

On Sunday 24 Apr 2011, Shawn H Corey wrote:
> On 11-04-24 09:48 AM, Akhthar Parvez K wrote:
> > #5 - Never give a wrong answer - If at all you receive a question that you don't know, do not panic, just be smart and divert the question so you can answer what you know.
>
> If you don't know the answer, say so. Then state how you would go about
> finding the answer. Do not reply on clever tricks in an attempt to fool
> your interviewer.
>

I'm sure that I wouldn't have received such a response had I explained it a bit more, but then that's my fault as I made tips so short that it didn't convey the message clearly.

Well, what I actually meant was not diverting it baselessly. One could actually start with "I don't think I actually know what you asked, but if ". It's just to let the interviewer know that you know about something related eventhough you don't know the answer for the exact question. It's anything but an attempt to fool. :-) After all, what the interviewer wants to know is if the interviewee is knowledgable enough and it's not always necessary to have that happened by an answer he expected.

--
Regards,
Akhthar Parvez K
http://www.sysadminguide.com/
UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity - Dennis Ritchie

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Re: perl interview questions

am 24.04.2011 16:50:23 von Shlomi Fish

On Sunday 24 Apr 2011 17:13:18 Shawn H Corey wrote:
> On 11-04-24 09:48 AM, Akhthar Parvez K wrote:
> > #5 - Never give a wrong answer - If at all you receive a question that
> > you don't know, do not panic, just be smart and divert the question so
> > you can answer what you know.
>
> If you don't know the answer, say so. Then state how you would go about
> finding the answer. Do not reply on clever tricks in an attempt to fool
> your interviewer.

Very good advice!

I recall an interview I did for the IBM Haifa R&D lab, where I was asked a
question, which I didn't immediately know the answer to, but instead of saying
"let me think about it" I "brainstormed" a little with the interviewers until
I reached the right answer. Maybe they sensed it, and I didn't get the job
even though I did well on the other tests. (Though who knows - back then there
was still a lot of recession and they had many candidates.).

I'll reply directly to what Akhthar said with more advice from my experience.

Regards,

Shlomi Fish

--
------------------------------------------------------------ -----
Shlomi Fish http://www.shlomifish.org/
Escape from GNU Autohell - http://www.shlomifish.org/open-
source/anti/autohell/

sub id { my $self = shift; $json_parser_for{ $self }
->decode($json_for{ $self })->{id} } # Inside-out JSON-notated objects

Please reply to list if it's a mailing list post - http://shlom.in/reply .

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Re: perl interview questions

am 24.04.2011 17:26:48 von Shlomi Fish

On Sunday 24 Apr 2011 16:48:10 Akhthar Parvez K wrote:
> Hi Jyoti,
>=20
> On Thursday 21 Apr 2011, Jyoti wrote:
> > Please give me any link or any tutorial which will be helpful for
> > preparation of PERL interview.
>=20
> I don't honestly think someone would write an article or tutorial about
> "preparing for a Perl interview". That should actually split into two:
> Learning Perl and Preparing for an interview.
>=20
> And here's some free advice and feel free to take it if you like :-D
>=20
> #1 - Never learn for an interview; but learn for the job.
> #2 - Apply for an interview only if you're fit enough. - If you don't thi=
nk
> your skill set don't match with the requirements of the company, just
> don't apply. You're thus doing a favor to yourself and everyone else. #3 -
> Once you apply, just be ready to face an interview any time.
> #4 - Trust your abilities and be confident - This is the most important
> part and would let you handle the interview in the best possible way. #5 -
> Never give a wrong answer - If at all you receive a question that you
> don't know, do not panic, just be smart and divert the question so you can
> answer what you know. #6 - Please your interviewer with well explained
> responses.
>=20

Some more advice from my experience:

1. Be yourself. Be honest. If you don't like=20
Java/Perl/Python/COBOL/Lisp/C/C++/whatever, say so. Google hires many Pytho=
n=20
programmers to write Java, and even many Perl programmers to write Python o=
r=20
Java or whatever (yes, some people code even Python against their=20
preferences). If you lie, you will eventually get caught, possibly after be=
ing=20
hired and then fired immediately.

2. Seek good workplaces. A lot of workplaces there are crap. It's hard to k=
now=20
how many, but see http://blog.red-bean.com/sussman/?p=3D79 (=3D Version Con=
trol=20
and "the 80%"). To paraphrase on what Tolstoy said "All good workplaces are=
=20
the same. Every bad workplace is bad in its own way.". Often times, I reali=
sed=20
I knew things much better in most respects than my superiors based on what =
I=20
read in various software management and software development in general on =
the=20
Web. It's hard the way a workplace is managed as an underling (at least if=
=20
you're not being very assertive.) and it is a good idea to make sure that y=
our=20
boss (your CTO/etc.) have heard of http://www.joelonsoftware.com/ , knows w=
hat=20
Extreme Programming is about mostly, understands test-driven development, h=
as=20
read "The Cathedral and the Bazaar", does not require more than 40 hours/we=
ek=20
weekday (otherwise you *will* be burned out), etc. He does not have to agre=
e=20
to everything every software management "guru" out there says (which is oft=
en=20
contradictory), but he has to be able to explain why he deviates from it.

Whether he prefers to use Perl or Python or Java or C or whatever (some of=
=20
which are only useful in completely different contexts) is less critical.

3. Don't give up. Finding a job is hard now in the post-bubble world.=20
Employers are very picky and careful, and=20
http://www.joelonsoftware.com/articles/GuerrillaInterviewing 3.html says tha=
t=20
if you have a little doubt, it means no hire, which some employers may=20
practise deliberately or subconsciously.

It can sometimes take a lot of time to find a good job after you left the=20
original one (for whatever reason), but you should be able to find one,=20
because it seems that in IT centres, all fields nowadays are desperately=20
looking for clueful programmers. If you're good, you will likely find a job=
=20
soon enough.

4. Whether working or not, always try to improve your existing skills (whic=
h=20
you consider important enough and not passé), become experienced in mo=
re=20
technologies (what I call "horizontal learning" because it's impossible to=
=20
100% master a complete fields such as RoR/CPAN/Python/etc. and you should n=
ot=20
wait to know everything to know about it to learn more stuff), and also=20
improve your spoken and written English (and your native languages), becaus=
e=20
it is one of the most important skills that any person can possess, and=20
naturally, every programmer.

=2D----------

OK, these are the things off the top of my head.=20

Regards,

Shlomi Fish

=2D-=20
=2D--------------------------------------------------------- -------
Shlomi Fish http://www.shlomifish.org/
Stop Using MSIE - http://www.shlomifish.org/no-ie/

Ran Eilam To Shlomi Fish: so what are you working on? Working on a new wiki
about unit testing fortunes in freecell?

Please reply to list if it's a mailing list post - http://shlom.in/reply .

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Re: perl interview questions

am 24.04.2011 20:01:57 von Shawn H Corey

On 11-04-24 10:36 AM, Akhthar Parvez K wrote:
> Well, what I actually meant was not diverting it baselessly. One could actually start with "I don't think I actually know what you asked, but if". It's just to let the interviewer know that you know about something related eventhough you don't know the answer for the exact question. It's anything but an attempt to fool.:-) After all, what the interviewer wants to know is if the interviewee is knowledgable enough and it's not always necessary to have that happened by an answer he expected.

I still think I have to disagree. Sometimes interviewers ask purposely
obscure questions not to see if you know the answer but to see what
you'd do if you came across a problem you couldn't immediately solve
when on the job. The best response is to state you don't know and then
tell what you'd do:

1. Inform your immediate supervisor about the problem.

2. Start searching the company's code base and asking the old hands
about it.

3. Search the web.

4. Ask the perlmonks

5. (Anything you can think of.)


--
Just my 0.00000002 million dollars worth,
Shawn

Confusion is the first step of understanding.

Programming is as much about organization and communication
as it is about coding.

The secret to great software: Fail early & often.

Eliminate software piracy: use only FLOSS.

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Re: perl interview questions

am 24.04.2011 21:44:28 von Shlomi Fish

On Sunday 24 Apr 2011 21:01:57 Shawn H Corey wrote:
> On 11-04-24 10:36 AM, Akhthar Parvez K wrote:
> > Well, what I actually meant was not diverting it baselessly. One could
> > actually start with "I don't think I actually know what you asked, but
> > if". It's just to let the
> > interviewer know that you know about something related eventhough you
> > don't know the answer for the exact question. It's anything but an
> > attempt to fool.:-) After all, what the interviewer wants to know is if
> > the interviewee is knowledgable enough and it's not always necessary to
> > have that happened by an answer he expected.
>
> I still think I have to disagree. Sometimes interviewers ask purposely
> obscure questions not to see if you know the answer but to see what
> you'd do if you came across a problem you couldn't immediately solve
> when on the job. The best response is to state you don't know and then
> tell what you'd do:
>
> 1. Inform your immediate supervisor about the problem.
>
> 2. Start searching the company's code base and asking the old hands
> about it.
>
> 3. Search the web.
>
> 4. Ask the perlmonks
>
> 5. (Anything you can think of.)

I recall a job for a security company that developed an Intrusion detection
system (IDS) or Intrusion Prevention System (IPS) - don't remember which one -
as a small embedded box running vxWorks [vxWorks] and they asked me "How would
you design an IDS?" I told them that I didn't know and they told me "We'll
help you. Do you have any ideas?" I had some leads, but I ended up saying I
don't know, and couldn't really get anywhere. Maybe they were looking for
brighter or more experienced people then me, but I naturally didn't get the
job, nor was I very impressed of their hiring and interviewing philosophy.

Most good workplaces I've been to asked me to write a piece of code (a bit
tricky, but not very time consuming) in their language of choice or less often
"my favourite language", and I do better there because I'm a capable coder,
and I think it's a good idea to actually instruct the candidate to write some
code.

------

On a different note, another good idea is to not be too prepared. One of my
online friends was offered to interview for Google, and he got prepared with
studying a lot of deep and formal data structures and algortihms theory ("you
need to know how to implement a QuickSort off-hand.") and when he came there,
his technical questions were much less sophisticated than he thought they
would. Some employers may view such a thing as a red flag, because a person is
trying to seem to be more than he is by "cramming" for an interview. They
usually don't expect you to be a software development
superstar/virtuoso/rocket-scientist , and you should know better to assume
they do (and if they do, you probably won't get the job by cramming.).

Regards,

-- Shlomi Fish

[vxWorks] - http://en.wikipedia.org/wiki/VxWorks - an embedded operating
system by a company that was often referred to as "The Microsoft of the
Embedded market", mostly POSIX compatible, but very different from most
mainstream UNIX, a bit quirky, using a very old version of the GNU tools for
development. Lost some popularity and hype in the embedded space due to
competition from Linux, Embedded MS-Windows, the BSDs and similar solutions,
but is still popular. I was told it's not really comparable to Linux, and they
both have different use-cases.

--
------------------------------------------------------------ -----
Shlomi Fish http://www.shlomifish.org/
http://www.shlomifish.org/humour/ways_to_do_it.html

Chuck Norris doesn't make mistakes. (Su-Shee) He corrects God. (Shlomi Fish)

Please reply to list if it's a mailing list post - http://shlom.in/reply .

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Re: perl interview questions

am 25.04.2011 17:07:51 von Akhthar Parvez K

On Monday 25 Apr 2011, Shlomi Fish wrote:
> On Sunday 24 Apr 2011 21:01:57 Shawn H Corey wrote:
> > On 11-04-24 10:36 AM, Akhthar Parvez K wrote:
[ snip ]
> > I still think I have to disagree. Sometimes interviewers ask purposely
> > obscure questions not to see if you know the answer but to see what
> > you'd do if you came across a problem you couldn't immediately solve
> > when on the job. The best response is to state you don't know and then
> > tell what you'd do:
> >
> > 1. Inform your immediate supervisor about the problem.
> >
> > 2. Start searching the company's code base and asking the old hands
> > about it.
> >
> > 3. Search the web.
> >
> > 4. Ask the perlmonks
> >
> > 5. (Anything you can think of.)
>
> I recall a job for a security company that developed an Intrusion detection
> system (IDS) or Intrusion Prevention System (IPS) - don't remember which one -
> as a small embedded box running vxWorks [vxWorks] and they asked me "How would
> you design an IDS?" I told them that I didn't know and they told me "We'll
> help you. Do you have any ideas?" I had some leads, but I ended up saying I
> don't know, and couldn't really get anywhere. Maybe they were looking for
> brighter or more experienced people then me, but I naturally didn't get the
> job, nor was I very impressed of their hiring and interviewing philosophy.

Actually I was talking about a situation like this, not the context Shawn mentioned. What Shawn mentioned was more of a "what would you do if you're faced with an issue that you couldn't fix on time" case. Let me demonstrate the one I mentioned with the following conversation:

Interviewer: How would you design an IDS?

Interviewee: I have never worked on IDS so far, hence don't have a clear idea about the designing of the same. However, I was part of a team that developed an Exploit Scanner/Detection tool for Linux machines. It was written in Perl and we used a couple of mechanisms such as signatures, regular expressions etc. to detect the exploits and setup a Hash design to store the scan results in the most appropriate manner.

Interviewer: Ok, that's good. So as you said you don't have much idea about designing IDS, how would you proceed if you're assigned for that job?

Interviewee: First and foremost, I would talk to the experienced members in my team to get some valuable inputs and then read some books as well as search through the web for more details. In fact, I'll try wherever I think would help me to learn more about the same. I'm pretty sure I would be able to get it done as that has been case whenever I worked on something interesting.

Here, the interviewee is not fooling the interviewer and the latter would be generally happy to know the former has got some experience in something related. For the interviewee, he can still use the opportunity to impress the interviewer even if he doesn't know the particular answer.

> Most good workplaces I've been to asked me to write a piece of code (a bit
> tricky, but not very time consuming) in their language of choice or less often
> "my favourite language", and I do better there because I'm a capable coder,
> and I think it's a good idea to actually instruct the candidate to write some
> code.

Yes, this is good if you're being interviewed for the post of a developer. But in some cases, it's not really necessary. Suppose if they understood your coding credibility already, they wouldn't really want to dig deep into programming. They would rather want to know something else, mostly related to planning, managerial or other non-technical aspects etc.

--
Regards,
Akhthar Parvez K
http://www.sysadminguide.com/
UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity - Dennis Ritchie

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Re: perl interview questions

am 25.04.2011 19:15:05 von Shlomi Fish

On Monday 25 Apr 2011 18:07:51 Akhthar Parvez K wrote:
> On Monday 25 Apr 2011, Shlomi Fish wrote:
> > On Sunday 24 Apr 2011 21:01:57 Shawn H Corey wrote:
> > > On 11-04-24 10:36 AM, Akhthar Parvez K wrote:
> [ snip ]
>
> > > I still think I have to disagree. Sometimes interviewers ask purposely
> > > obscure questions not to see if you know the answer but to see what
> > > you'd do if you came across a problem you couldn't immediately solve
> > > when on the job. The best response is to state you don't know and then
> > > tell what you'd do:
> > >
> > > 1. Inform your immediate supervisor about the problem.
> > >
> > > 2. Start searching the company's code base and asking the old hands
> > > about it.
> > >
> > > 3. Search the web.
> > >
> > > 4. Ask the perlmonks
> > >
> > > 5. (Anything you can think of.)
> >
> > I recall a job for a security company that developed an Intrusion
> > detection system (IDS) or Intrusion Prevention System (IPS) - don't
> > remember which one - as a small embedded box running vxWorks [vxWorks]
> > and they asked me "How would you design an IDS?" I told them that I
> > didn't know and they told me "We'll help you. Do you have any ideas?" I
> > had some leads, but I ended up saying I don't know, and couldn't really
> > get anywhere. Maybe they were looking for brighter or more experienced
> > people then me, but I naturally didn't get the job, nor was I very
> > impressed of their hiring and interviewing philosophy.
>
> Actually I was talking about a situation like this, not the context Shawn
> mentioned. What Shawn mentioned was more of a "what would you do if you're
> faced with an issue that you couldn't fix on time" case. Let me
> demonstrate the one I mentioned with the following conversation:
>
> Interviewer: How would you design an IDS?
>
> Interviewee: I have never worked on IDS so far, hence don't have a clear
> idea about the designing of the same. However, I was part of a team that
> developed an Exploit Scanner/Detection tool for Linux machines. It was
> written in Perl and we used a couple of mechanisms such as signatures,
> regular expressions etc. to detect the exploits and setup a Hash design to
> store the scan results in the most appropriate manner.
>
> Interviewer: Ok, that's good. So as you said you don't have much idea about
> designing IDS, how would you proceed if you're assigned for that job?
>
> Interviewee: First and foremost, I would talk to the experienced members in
> my team to get some valuable inputs and then read some books as well as
> search through the web for more details. In fact, I'll try wherever I
> think would help me to learn more about the same. I'm pretty sure I would
> be able to get it done as that has been case whenever I worked on
> something interesting.
>
> Here, the interviewee is not fooling the interviewer and the latter would
> be generally happy to know the former has got some experience in something
> related. For the interviewee, he can still use the opportunity to impress
> the interviewer even if he doesn't know the particular answer.
>

Good advice. I'll keep that in mind for next time, instead of saying "I don't
know". Applied psychology at its best. (Though I think they were still not a
good place to work for me.).

> > Most good workplaces I've been to asked me to write a piece of code (a
> > bit tricky, but not very time consuming) in their language of choice or
> > less often "my favourite language", and I do better there because I'm a
> > capable coder, and I think it's a good idea to actually instruct the
> > candidate to write some code.
>
> Yes, this is good if you're being interviewed for the post of a developer.
> But in some cases, it's not really necessary. Suppose if they understood
> your coding credibility already, they wouldn't really want to dig deep
> into programming. They would rather want to know something else, mostly
> related to planning, managerial or other non-technical aspects etc.

Well, I think you should always ask a person to write some code, even if
you're sure based on their open-source code (CPAN/etc.), their posts to
technical mailing lists (such as beginners@perl.org, etc.) that they are very
good programmers. This is because you can still see how he handles a task. I
recall an interview for a company where the CTO there, who was and still is a
very good friend, told me "In your favourite language, write a function that
replaces the string '%FOO%' in a given string with the second argument." I
asked if I could use Perl for that, and he said "Only if it's your favourite
programming language!" and so I went to write that. He then said that the
Python routine was a bit shorter and that many C and Java programmers he
interviewed had natural problems with this due to their languages'
limitations.

Naturally, he knew I knew Perl, but it still was a good mention of trust. And
naturally, even if you're a Perl shop (or Ruby or Python or whatever - same
thing as far as this is concerned), you can learn a lot if the programmer
writes code that is too smart, or too ancient Perlish, or too non-idiomatic or
just non-modular based on what he writes on the fly. But it's important to
test his ability to write some not-too-hard-but-not-100%-trivial code on a
blackboard (or as I once had in another interesting interview, an MS Notepad
buffer).

In my last workplace (where the company ended up disbanding the entire
Perl/Catalyst team - we were a Web 2.0 startup), they hired many people based
on their CPAN pages and a short interview without actual coding (which I think
was a somewhat bad idea now), and they said they'll give me a chance as a
Catalyst developer (which I think I did very well), and when they hired a
different CPAN developer to give us a hand, my boss told me that after looking
at his code, it was elegant code but too smart one, and one that gives you too
many "WTF?" then "OK, it's brilliant, but why???" moments when reading it.

Regards,

Shlomi Fish

--
------------------------------------------------------------ -----
Shlomi Fish http://www.shlomifish.org/
"Humanity" - Parody of Modern Life - http://shlom.in/humanity

Knuth is not God! It took him two days to build the Roman Empire.

Please reply to list if it's a mailing list post - http://shlom.in/reply .

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/