On Fri, 21 Sep 2007 18:29:25 +0200, Frans Bouma <[EMAIL PROTECTED]> wrote:
>> On Fri, 21 Sep 2007 16:31:04 +0200, Frans Bouma <[EMAIL PROTECTED]> wrote: >> >> On Fri, 21 Sep 2007 15:28:58 +0200, Frans Bouma <[EMAIL PROTECTED]> >> wrote: >> > Often no experience and likely not really that much education >really. >> >Say you have a guy who's 18. Does that person have a lot of education in >class >> >design, knowledge about what makes software maintainable etc. ? no. But >that >> >person can likely be able to write for you a killer quaternion based 3D >object >> >rotator. The right person for the job? He'll likely pass all your low- >level >> >> If he can learn to write "quaternion based 3D object rotator"...then he >> can probably learn how to do lots of stuff useful to me.... > > But he lacks serious knowledge of software engineering, computer >science. Being able to write code doesn't mean you know much about the >fundamental elements of computer science. Like a thing called a parser. Not a >lot of people know how a parser, lexical analyzer, grammars etc. work. What >LR(n) means, what the difference with LL(n) is and why it's a fundamental part >of computer science. it may (or may not) be a fundamental part of computer science but I'm not employing academics for the sake of it. > > You don't need to know how it works to write a loop and a sorter. >Though the knowledge is key for a succesful software engineer. Let me refer to >Yegge for a brilliant piece why this is so: >http://steve-yegge.blogspot.com/2007/06/rich-programmer-food.html seems like ivory tower nonsense to me. > > Look, if you're looking for a guy who can hammer in code, you're >probably not looking for a person who knows fundamental stuff. But then this >person won't evolve further towards a software engineer he could be, only the >lucky ones will. seems a rather elitist view. > >> > And even then: would you want to hire a C# developer who doesn't >use >> >framework classes for this? Or one who DOES use framework classes for this? >> >> don't care...I'm interested in how it's done. > > You don't care? So you don't mind hiring a NIH (Not Invented >Here)-syndrom person? > >> >> would it matter if it were a string or a set of delegates in a generic >> >> collection used for event handlers?...does that somehow make it more >> >> relevant? >> > >> > If someone is faced with these problems, they'll likely look up the >> >algorithm and implement that. You say it's a junior position. So the person >> >hired has little knowledge about all the algorithms out there, only a few >of >> >them are known by the person. So it's likely the person will run into >problems >> >which ask for an algo which isn't known. >> >> you seem to have the notion that all algorithms come from web sites....do >> you google every time you wanted to write a loop?....surely not. > > algo != loop. ? algorithms without mathematical recursion (i.e. in CS iteration), are pretty weak. > > I also don't think algorithms just come from websites. I do know that >if you don't look for the algorithm, you'll likely re-invent it... poorly. to do the fizz buzz program, I need to loop through the numbers 1 to 100...do I really need to look this up. > > Unless it's a deadbeat loop of course. > >> >> > Remember: interviewing for a job is often totally difficult >compared >> >> >to the real job. >> >> >> >> difficult? or different? >> > >> > different, my bad. >> >> yes....so? > > so conclusions drawn from the PERFORMANCE of the person on the >interview are actually pretty flaky, IF the tests aren't that great, because >the pressure to do it right the first time and not to make a single mistake is >extremely high for the interviewee. Thats why you interview them after the test.....you go through it and guage why they did it the way they did it. > >> >> > For example, most algorithms to use on a daily basis are already >> >> >discovered and documented in full on the internet and in books. Like >'sort >> >> >this DAG in the right order so all jobs represented by nodes are >enlisted >> >> in the right order for execution'. Sounds tough? No, it doesn't. >> >> ? >> >> I'm not asking them to invent an algorithm....just apply it. >> > >> > Topology sort of a DAG is simple graph math, every CS student gets >it. >> >So if someone can't do a depth first search through a graph, s/he has no >> >knowledge of graphs. It's not inventing an algo, it's a well known algo. >> That is, if you have had that education. >> >> I would not expect a junior or senior programmer to understand what you >> are talking about....I have a masters in maths......and I don't understand >> what you're talking about......it's the demonstration of knowledge....I >> want a demonstration of ability. > > You have a degree in math and you don't know what a Directed Acyclic >Graph is? I do know what an acyclic directed graph is.....not a topological sort. > Topology sort is a simple algo based on depth based first graph >traversal, a typical math-applied-to-data structures Computer science example. well done, so? > > > It's not really important, what I wanted to illustrate is that IF a >person knows a given algorithm, the person can answer the questions in the >field of the algo, but that doesn't say anything, only that the person >understands the algo. > > I.o.w.: it doesn't test wisdom, just knowledge. ? it's the intelligent application of knowledge. If I pick a random question which is the simple *application* of a loop and an if....unless someone happens to have studdied by complete chance my version of FizzBuzz then they will have to engage their brain....that application is what I am testing. > >> > I mentioned it to illustrate that the algo YOU pick to test, might >be >> >well known or easy, but might be for others hard to do and vice versa. >> ? >> >> all algorithms are not created equally... >> I would expect all programmers to understand simple iteration...i.e. a >> loop. > > duh. I expect them also to understand what control flow means, but >that doesn't mean anything w.r.t. algorithms. programs are instances of algoritms...they are almost synonymous! > >> I would expect less than 10% to know anything about acyclic graphs....or >> at least in those terms. > > You do? Graphs are a fundamental part of computer science. I bet >almost all programs have one or more graph-like datastructure internally, e.g. >a tree. So if a person had a good CS education, s/he would know about them and >a test based on them is easy for these people. > > A person who did something else, has a hard time. If that person then >has to do the same test, s/he'll likely fail. That's illustrating the lameness >of these tests. the lameness of your test about acyclic graphs......a test that happened to be about programming acyclic graphs would be more interesting.....a question about them (at least in those terms), just proves you probably read too many books. > >> > If you tell the junior to navigate through the graph and find all >> the >> >paths, it's the same as string reversal: the algorithm sounds OK, it tests >> >basic simple first grade programming 101 skills no-one bothers about, and >it >> >tells you nothing about the true knowledge of the person. >> >> what if they fail! > > then nothing, they might got too nervous to write something solid, or >didn't have enough time or got lost because they don't have any docs at hand. yes they might....but that is as true for someone who can do it, as someone who can't...the other difference is that people who can't do it...*can't*, by definition...so you would expect more of them to fail....whichs means probably have a better statistical correlation than just picking people called John....you will never find someone who can't program, write a sensible program...unless you gots lots of monkeys and lots of typewriters, and lots of time....they'll have about an hour to do something that would take you five minutes, and a monkey about 10,000 years. > >> > Did I pick the right person? Undefined: based on that algo test, >you >> >can't tell anything about the true skill of the person. >> >> no? > > It's your interview, but I'd say: no. nothing?...absolutely nothing?...so you ask them to write a simple program...they write it, it works perfectly, and explain to you in intelligent detail why they did it that way....conversations about patterns, OO, design by contract, extensibility. but you cannot guage anything about this person compared to someone who writes a program that doesn't compile, who can't tell you why it doesn't compile, has never heard of a loop...let alone a class or UML. wierd....I'll employ the 1st one and you can have the 2nd. > >> > EVERY programmer can write a simple loop. That's why these tests >are >> >so stupid! >> >> what if they fail! > > the same thing as what if they succeed? no it's not....you need to look up hypothesis testing (which is effectively what we are doing)..... P(good programmer/success) != P(good programmer/failure) you can use a monkey and a CS graduate as two test cases if you like....you would seem to claim they are as likely to pass as each other.....and give me reasons why in an interview afterwards. > >> the deduction that the information gleaned from a test that everyone (by >> premise) succeeds at is none, is trivial. >> >> YOU failed the test.....you didn't do it 'in place'. > > hehehe, so you have made a conclusion, based on that? Yeah, I'm a >lousy programmer who can barely code his way out of a wet paper bag ;) > > Of course I failed. You would too. Because it's impossible due to >technical limitations. well done you passed the interview! I would have failed. my mother would have failed. do you think the probability of you failing the test and passing the interview is the same as for my mother? > >> > What's the point of testing procedural stuff in an OO environment? >Do >> >you want them to code procedural script-like OO code? Or do you want them >to >> >write OO code? Do you want them to write deep class hierarchies no-one will >> >understand? Or do you want them to do the right thing? >> >> OO is a generisation of procedural programming (at least in the context of >> imperative languages)....if they can't write procedural code....they can't >> write OO code.....I don't view (good) OOP as a basic skill.....I do view >> procedural programming as one. > > fundamentally wrong, IMHO. A procedural oriented developer might be >able to write classes, and it looks 'ok', but the code inside the classes is >procedural, not OO. Code will likely ask data from objects to do stuff in a >method instead of telling an object to do things. Fundamentally different and >a procedural oriented person won't grasp that. IMHO this is not a good definition of OO, but the difference between event driven and flow driven programming. Yes OO is generally 'better' at implementing such solutions, but procedural types will argue that callback functions server the same purpose. > >> > You can't determine that from isolated tests which test basic stuff >> >learned on page 1 of every language book. >> >> YOU failed the test. >> I assume you failed it, not because you can't do it, but because you >> didn't clarify the question....I would then make a note 'does not clarify >> requirements?'. > > As a matter of fact I looked for the String.Reverse method, then I >remembered there was an array reverse method, so I went that route and mailed >it. Later on I realized the question itself was bogus because strings are >immutable. > > One could argue that missing a requirement is bad. The in-place >requirement could have consequences for very large strings in-memory: not >doing it in-place isnt possible or very slow. (let's assume the strings are >mutable). (complete aside)...why would it be slow? > > So yes, I've failed your test, in that light. Though my code was just >to illustrate that it's trivial which was your question. ! which is why I asked the question originally..... there are tests for C programmers....I asked the question to glean sensible C#/VB.net questions..... > >> > So I failed your test and you would not hire me. See how silly this >> >is? :) >> >> I didn't because I researched the questions on the internet before asking >> any real candidates!.... >> >> and if you had done the question you would have done nicely in the >> interview by pointing out it was impossible. > > though that would illustrate nothing, just that I know strings are >immutable. which demonstrates a knowledge of the dotnet framework......I'd rather have had a demonstration of programming competence, but the question, as you have demonstrated, doesn't do that...at least for the more knowledgable candidates. > The thing is: do you want a person who knows things about computer >science or do you want to hire a person who can hammer code? I want someone who can write code....if they know what a graph is then, probably thats even better. > because those >aren't the same things. As it's a junior job, you likely want the latter, but, >it's very very hard without proper uni education to get from junior to the >spot where you do know about fundamental computer science elements WITHOUT >selfstudy. I don't believe you need to get to the 'fundamental computer science elements' to be productive and successful. >That'll cost a lot of selfdicipline, which his often ignored, >because why would you want to learn about those dry crap if you know how to >write a loop? ;) :) > >> But thankyou.....reversing strings in place is not a sensble c#, question >> thats what the OP was about. >> >> Any thoughts about any other questions? :-) > > Ask a complex algorithm, in line with the job, and not to let them >write it in code, but to let them explain how they will handle this. they get that, as well.... > > But I think it's best to let them do an assignment in line with the >job. > > FB > >=================================== >This list is hosted by DevelopMentor® http://www.develop.com > >View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
