None of the MVC designs I've seen check in all three places.
I've mostly worked with rails though, and the entire system has a DRY philosophy. Maintaining a check in all three places seems to defeat the purpose of the MVC system.
Question 2 would be the hardest for me. I don't ever write sorts manually. I mostly use STL or boost algorithm functions to do sorting.
I know I covered all kinds of sorts (including heap) in classes, and even did alot of analysis in Algorithms but I couldn't remember how it works for the life of me. About a minute on Wikipedia (not including sample source of course) and I could cook up some quick code though.
The MVC questions seems a bit unfair too (unless it's something to be expected in your business). None of my classes have ever covered it to that extent (I think it may have been briefly mentioned in my UML class).
Question about programming tests...
The MVC question is somewhat similar to the heap sort question: I don't care what answer you give. I want to know why you chose that answer. If you manage to convince me with sound arguments that you don't need to perform a check anywhere at all, that's good.
My personal take on the subject is that you need a model-level check (both in terms of a database constraint and an integrity check that's able to give a clean diagnosis that you can use to notify the user), and can then choose whether you build a system that outputs model integrity failures back to the user upon submitting the registration form (this can be more or less easy, so sometimes the fastest thing to do is simply to special-case the 'mail is unique' feature instead of going for a complex generic solution: DRY versus KISS), or to actually provide feedback to the user before the form is submitted by checking the mail individually from your view/controler as AJAX while the user is editing.
I would be wary of candidates that equate models with databases, though. [smile]
My personal take on the subject is that you need a model-level check (both in terms of a database constraint and an integrity check that's able to give a clean diagnosis that you can use to notify the user), and can then choose whether you build a system that outputs model integrity failures back to the user upon submitting the registration form (this can be more or less easy, so sometimes the fastest thing to do is simply to special-case the 'mail is unique' feature instead of going for a complex generic solution: DRY versus KISS), or to actually provide feedback to the user before the form is submitted by checking the mail individually from your view/controler as AJAX while the user is editing.
I would be wary of candidates that equate models with databases, though. [smile]
Do you ever get candidates that say "Model equals databases" ??
I can't blame you, I guess I'd be wary of them too.
I can't blame you, I guess I'd be wary of them too.
You would only hire people who know MVC? Seems kind of narrow, unless it's clear on the job ad.
Quote: Original post by d000hgGiven the choice between someone who knows MVC and someone who doesn't for a given job, I would prefer the one who knows MVC. Mostly because all of our web-side work uses MVC frameworks (such as the Zend Framework) and I'd rather work with someone who knows what that means.
You would only hire people who know MVC? Seems kind of narrow, unless it's clear on the job ad.
Now, if the candidate does not know MVC, but does show an ability for learning quickly and has some experience in design patterns, I'll be happy to provide a few hours of teaching on the subject. But given the amount of things one has to learn when coming in on an existing project, I'd rather not spend too much time teaching things that could have been learned before joining.
On a job that doesn't involve MVC, I wouldn't really bother (although knowledge of MVC would be a bonus point anyway).
Quote: Original post by BeanDog
I don't like those kinds of tests that are far removed from the actual work you're actually going to do (I'm assuming you're not writing TopCoder solutions at this job).
I had to hire a programmer several months back, and the most difficult part of the job technically was going to be writing very complex SQL queries. So I made up a schema that was dumbed down from our actual production schema, then wrote up a test of ten queries to write against it, in increasing order of complexity.
It was obvious when someone was BSing a claim of "8 years" of SQL experience on their resume, when it took them four hours to (poorly/incorrectly) complete eight of the ten problems. Instead, I ended up hiring a fresh graduate who finished most of them in a couple minutes, then asked if he could use Google/Wikipedia.
That gave me a much better idea of the person I'm going to hire than a Scrabble puzzle or a "you're a frog in a blender that's going to turn on in 30 seconds" mind game.
Just for curiosity's sake, what kinds of questions did you ask?
Quote: Original post by MrCoolsman
Just for curiosity's sake, what kinds of questions did you ask?
Here's a simple schema. Tell me why it's not in the third normal form (Wikipedia allowed). Now tell me why I might decide to structure my database that way anyway.
Here's a person table and a company table, where person has a CompanyId. Get me a list of all the companies with the number of people they have. (Check to make sure they used an outer join so they get all the empty companies). What indexes should the database have to perform your query quickly?
Here's a ledger table, where each row has a positive or negative Amount and a PersonId. Get me the balances (total Amounts) for all the people in Company #3. (Again, check to make sure they get $0 balances for people with no ledger entries). What indexes should the database have to perform your query quickly?
Now get me a list of all the companies with the grand total of all their peoples' balances. Give me one using only joins, and one that uses subqueries. What indexes should the database have to perform your queries quickly? What are the differences in performance characteristics between the subquery version vs. the join version? (Check to make sure they mention that when paging the results, subqueries may be faster since they're only calculated for the rows actually returned rather than for all rows as in the case of the pure join query; the pure join query will generally be faster in MySQL, though).
And so on, making sure they can use UNION, LEFT JOIN and RIGHT JOIN, subqueries, GROUP BY, etc.
I saw all kinds of evil on the results from this test. People GROUPing by the company table's friggin name column instead of its ID, and then not even saying they should have an index on that field. I mean, stuff that keeps me up at night.
Quote: Original post by ToohrVykPractical question: implement heap sort.
I'd also ask what exactly is heap sort. I'm sure I did learn the algorithm but I cannot quite remember how heap works (always used std::priority_queue for it).
I'm going to see how long it takes for me to implement heap.
I implemented a thing conceptually very similar to quicksort as recently as a month ago, for building kd-tree for my game. Knowledge of sorting algorithms really does pay off, even if you never need to implement sorting itself.
After I submitted my resume to my soon-to-be-employer, they sent me back a skill assessment test that included 1 question that had to be answered and another 7 questions from which I must select and answer 2. I spent 2 days writing and refining my answers, and my final response consisted of 8 pages total, which included the questions (approx 1 page total), my responses in english to each (about 1.5 pages each, total 4.5 pages), and C++ code for one of the questiosn that mentioned code might help explain the response (2 pages). The english text was spaced at 110% with a blank line between paragraphs, and the code was spaced at 110% with a blank line between logical lines of code (to make word-wrapped lines easier to read).
I could have had a much shorter, less detailed response, but the questions were interesting and answering them allowed me to explore my own knowledge. I took 2 days partly because that is approximately how long it took them to respond to me after receiving my resume. I suppose I should clarify that by 2 days, I mean around ~12 hours of my spare time was spent intentionally thinking about and working on my answers, but I also had it in the back of my mind while working, which I think also improves the result.
In the instructions to the questions, they specifically mentioned that the point was to figure out your thought process and that explaining your thoughts was just as valid as providing an actual answer. I answered all the questions I selected, but did so in a way that revealed my though process to some degree. I didn't just write a stream of consciousness as it would be very difficult to read, but I did include a few tangents and explained the weaknesses of my solution (and in one case, why those weaknesses where inherent in the assumptions made by the question).
[Edited by - Extrarius on March 4, 2009 12:03:38 PM]
I could have had a much shorter, less detailed response, but the questions were interesting and answering them allowed me to explore my own knowledge. I took 2 days partly because that is approximately how long it took them to respond to me after receiving my resume. I suppose I should clarify that by 2 days, I mean around ~12 hours of my spare time was spent intentionally thinking about and working on my answers, but I also had it in the back of my mind while working, which I think also improves the result.
In the instructions to the questions, they specifically mentioned that the point was to figure out your thought process and that explaining your thoughts was just as valid as providing an actual answer. I answered all the questions I selected, but did so in a way that revealed my though process to some degree. I didn't just write a stream of consciousness as it would be very difficult to read, but I did include a few tangents and explained the weaknesses of my solution (and in one case, why those weaknesses where inherent in the assumptions made by the question).
[Edited by - Extrarius on March 4, 2009 12:03:38 PM]
"Walk not the trodden path, for it has borne it's burden." -John, Flying Monk
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement