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/