home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / c / 18559 < prev    next >
Encoding:
Text File  |  1992-12-17  |  2.2 KB  |  46 lines
  1. Newsgroups: comp.lang.c
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!news.iastate.edu!pv0321.vincent.iastate.edu!dschmitz
  3. From: dschmitz@iastate.edu (Daniel C Schmitz)
  4. Subject: Re: How to test a programmer
  5. Message-ID: <dschmitz.724622914@pv0321.vincent.iastate.edu>
  6. Sender: news@news.iastate.edu (USENET News System)
  7. Organization: Iowa State University, Ames IA
  8. Date: Thu, 17 Dec 1992 20:08:34 GMT
  9. Lines: 35
  10.  
  11. etljmme@etlxd30.ericsson.se (Jim) writes:
  12.  
  13.  
  14. >In article 724521723@pv0321.vincent.iastate.edu, dschmitz@iastate.edu (Daniel C Schmitz) writes:
  15. >> [stuff deleted]
  16. >>  This not only
  17. >>tested my programming skills, but my knowledge of graphics algorithms and
  18. >>my attention to details that the programmer must know but were not provided
  19. >>with the original problem description.  E.g. what is the format of the file,
  20. >>should the coins be centered top to bottom with relation to each other and/or
  21. >>to the screen.  Will the input contain errors and/or more coins than will fit
  22. >>on the screen.  What are the sizes of the coins.
  23.  
  24. >This is interesting, how did you solve uncertanties like the format of the file?
  25. >The format could be almost anything!  The other problems like the size of the
  26. >coins could, I suppose, be left to aesthetics provided the requirement is 
  27. >satisfied but I can't see how to code for handling the file without prior
  28. >knowledge of the file format.  Or is the point simply that the programmer
  29. >recognises these problems?
  30.  
  31. Yes, a programmer never (well almost never), gets a full
  32. description of a programming task.  A good programmer must not only be able
  33. to write programs to specifications but to recognize incomplete and ambiguous
  34. specifications.  A few questions can save the progammer a lot of time and
  35. the company a lot of money by avoiding mistakes rather than making the
  36. programmer go back and rewrite his/her code.
  37.  
  38. Anyway, I asked most of these questions before leaving the interview.
  39. A file format was provided, yes there might be errors, more coins than could
  40. fit on the screen is an error, the coins should have appropriate relative
  41. sizes but the absolute size did not matter.  The rest was left up to me.
  42.  
  43. Dan Schmitz
  44. dschmitz@iastate.edu
  45.  
  46.