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'

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

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.


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 .

Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 16 of 16 | next ›
Discussion Overview
groupbeginners @
postedApr 21, '11 at 4:49a
activeApr 25, '11 at 5:15p



site design / logo © 2021 Grokbase