python interview quuestions
in [Python]
|
From: Roy Smith on 8 Aug 2010 21:01 In article <388041a0-4bc5-4f65-bae3-d516fb90f57f(a)l25g2000prn.googlegroups.com>, Peter <peter.milliken(a)gmail.com> wrote: > Realistically, if the application is anything other than trivial then > it will most likely have somebody poking around in it at some stage > who isn't the brightest spark in the firmament. Anybody who produces > nice, readable and straight forward code in my books gets the tick of > approval. What he said. The first test of good code is that you can understand what you wrote six months after you wrote it. The second test is that you can explain it to some junior programmer a couple of cubes away from you, two or three years after you wrote it. The ultimate test is that some poor schmuck, long after you've moved on to another project (or company), can figure out what the heck you wrote, ten years later. And, oh, yeah, the junior programmer who you explained it to in the previous paragraph, may be 9 or 12 time zones away from the team who is currently maintaining your code, if he's around at all.
From: Peter on 8 Aug 2010 22:16 On Aug 9, 10:39 am, Steven D'Aprano <st...(a)REMOVE-THIS- cybersource.com.au> wrote: > On Sun, 08 Aug 2010 17:28:59 -0700, Peter wrote: > > On Aug 9, 6:49 am, Terry Reedy <tjre...(a)udel.edu> wrote: > >> On 8/7/2010 7:53 AM, Peter Otten wrote: > > >> > You mean you'd go for the candidate who took the conservative > >> > approach and got it right: > > >> > print 1 > >> > print 2 > >> > print 'Fizz' > >> > print 4 > >> > print 'Buzz' > >> > print 'Fizz' > >> > print 7 > >> > print 8 > >> > print 'Fizz' > >> > print 'Buzz' > > >> Way too verbose. How about > >> print("1\n2\nFizz\n4\nBuzz\nFizz\n7\n8\nFizz\nBuzz\n etc. > > >> -- > >> Terry Jan Reedy > > > And to hell with the code being maintainable afterwards? :-) > > I'm pretty sure both Peter Otten and Terry Reedy were being sarcastic and/ > or ironic. > > -- > Steven I'm sure you're right - and I repeat that I meant no offense. My comments were intended in the spirit of what to do or do not do in an interview for (any) programming job. Peter and Terry just offered some good examples of what you don't want to do (IMO) :-) So, I apologise if anybody has taken my comments as a slur on Peter and/or Terry's posts - they were not intended as such. Peter
From: Terry Reedy on 9 Aug 2010 01:11 On 8/8/2010 10:16 PM, Peter wrote: >> I'm pretty sure both Peter Otten and Terry Reedy were being sarcastic and/ >> or ironic. About the most I ever am ;=)! > I'm sure you're right - and I repeat that I meant no offense. > > My comments were intended in the spirit of what to do or do not do in > an interview for (any) programming job. Peter and Terry just offered > some good examples of what you don't want to do (IMO) :-) > > So, I apologise if anybody has taken my comments as a slur on Peter > and/or Terry's posts - they were not intended as such. I was not sure if you were taking me seriously or not, but rather than be insulted, I am delighted that I gave you an opportunity to both get something off your chest and say something worthwhile. When I was hired in part to maintain and extend someone else's work, it was in pretty good shape and the outgoing person, with more experience than me, gave me a quick head's about about it. But I realize that many others have been less fortunate, but of course cannot throw a fit in their new place of employment, as appropriate as it might seem. -- Terry Jan Reedy
From: J Kenneth King on 10 Aug 2010 16:44 James Mills <prologic(a)shortcircuit.net.au> writes: > On Sat, Aug 7, 2010 at 4:32 AM, Tim Chase <python.list(a)tim.thechases.com> wrote: >>> I would like to aquint myself with Python Interview questions >> >> This came up a while ago: >> >> http://www.mail-archive.com/python-list(a)python.org/msg168961.html >> >> Most of that thread is still relevant (perhaps throw in some py3l questions >> too) > > A common thing you can do in interviews is ask > your interviewee to write (in Python) a solution > to the "FizzBuzz" problem. Any good competent > Python programmer should be able to do this > in 5-10mins (5 if you're good). > > cheers > james Fizzbuzz is annoying in interviews. I've never worked at a job where I was under a timer while a group of people sat across from me and scrutinized everything I was doing. I don't see how it can honestly tell you anything useful about the person you're interviewing either. Do you really think that what you assume about the interviewee based on characteristics you can infer from their solution to be really, honestly true? They might even completely bomb the solution and still be a brilliant programmer, but you'll never know that if you trust this simple "fizzbuzz" test. I've been in those interviews on both sides of the table. Neither side was a good experience. If a test is necessary, make it a take-home or demand source code if they have it. Read their code and judge for yourself the quality of their work. Any questions in an interview should be the usual "get to know you" type stuff. "What was the most difficult challenge you've faced on the job? How did you respond?" That sort of thing.
From: Benjamin Kaplan on 10 Aug 2010 17:11
On Tue, Aug 10, 2010 at 1:44 PM, J Kenneth King <james(a)agentultra.com> wrote: > James Mills <prologic(a)shortcircuit.net.au> writes: > >> On Sat, Aug 7, 2010 at 4:32 AM, Tim Chase <python.list(a)tim.thechases.com> wrote: >>>> I would like to aquint myself with Python Interview questions >>> >>> This came up a while ago: >>> >>> http://www.mail-archive.com/python-list(a)python.org/msg168961.html >>> >>> Most of that thread is still relevant (perhaps throw in some py3l questions >>> too) >> >> A common thing you can do in interviews is ask >> your interviewee to write (in Python) a solution >> to the "FizzBuzz" problem. Any good competent >> Python programmer should be able to do this >> in 5-10mins (5 if you're good). >> >> cheers >> james > > Fizzbuzz is annoying in interviews. > > I've never worked at a job where I was under a timer while a group of > people sat across from me and scrutinized everything I was doing. > > I don't see how it can honestly tell you anything useful about the > person you're interviewing either. Do you really think that what you > assume about the interviewee based on characteristics you can infer from > their solution to be really, honestly true? They might even completely > bomb the solution and still be a brilliant programmer, but you'll never > know that if you trust this simple "fizzbuzz" test. > The interviews where I've been asked to write code, the interviewers had almost no interest in the code I actually wrote. They wanted me to think out loud, to see how I approached the problem. To make sure I did actually know how to program and not just copy/paste from a text book. > I've been in those interviews on both sides of the table. Neither side > was a good experience. > > If a test is necessary, make it a take-home or demand source code if > they have it. Read their code and judge for yourself the quality of > their work. > > Any questions in an interview should be the usual "get to know you" type > stuff. "What was the most difficult challenge you've faced on the job? > How did you respond?" That sort of thing. > -- Now those questions are completely useless for those of us still in school. Because almost nothing we've done so far really says anything about how we'll do on the job. When I get an interview like that, I usually end up with the same 2-3 responses to every single question, because those are the only experieces I've had outside of "well I had this tough homework assignment". |