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 <http://perlmonks.org/>
> > >
> > > 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-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
