• Franz Kafka (unregistered) in reply to SomeCoder
    SomeCoder:
    BradC:
    SomeCoder:
    So is the position for an architect or a developer? The story says ".NET developer". Therefore, this question is absolutely the real WTF.

    If you want to test SQL skills, put a schema in front of the candidate and have them write some SQL that pulls out some specific information you require. Make it so they have to join tables together, etc. Maybe even make them write some queries that create the schema using only code if you want.

    Asking a .NET developer to design a system is not a test of SQL skills.

    Mary's answer was still a WTF but the question was pretty bad.

    Unless the position explicitly calls for "average-to-strong SQL experience", which it sounds like it did. Sounds reasonable to me.

    I wouldn't assume that "average to strong SQL experience" for a .NET developer means that you'll be designing schemas, stored procedures, etc. If that's what they truly want, then they want a DBA. Or a VERY highly paid .NET who happens to also have DBA skills.

    You're kidding, right? This is a softball for me, and I'm a mid-level developer. Schemas aren't hard, although I usually avoid PLSQL (company policy). Generally, I'd do this as an interaction between the DB, some hosted app (for email notifications and approve/deny) and LDAP (where the org chart would probably already be). Not very hard, and not too much work.

  • Edward Royce (unregistered) in reply to Tammy
    Tammy:
    So exactly how would any of you have answered this question?

    I would have used the Chewbacca Defense.

    It just don't make sense!

  • Franz Kafka (unregistered) in reply to BitTwiddler
    BitTwiddler:
    DOA:
    I'm not exactly a DBA so out of curiosity, how would the following compare with the above?

    TBL1: Index,Question - All fields req. TBL2: Index,Answer,AssociatedQ(IndexfromTBL1), RightWrongFlag All fields req.

    The problem is that there's no standard DB-centric way to prevent two or more flags from being set to "right" at the same time.

    Yes, you could do it with triggers or stored procedures, but those are hardly standard (the concept is, but not the implementation) and they aren't really part of the data model per se anyway.

    Meh. After the quiz has been entered, require a validation step before allowing the quiz to be used - count(*) and group will give you the number of correct answers for every question.

  • KattMan (cs) in reply to Franz Kafka
    Franz Kafka:
    Meh. After the quiz has been entered, require a validation step before allowing the quiz to be used - count(*) and group will give you the number of correct answers for every question.

    No cookie for you. Why allow bad data in when you can know it is bad as it is entered? This is part of the point of the question I believe. It recognizes that there may be other ways, and asks about the problems in each of them.

  • Phleabo (unregistered) in reply to SomeCoder
    SomeCoder:
    BradC:
    SomeCoder:
    So is the position for an architect or a developer? The story says ".NET developer". Therefore, this question is absolutely the real WTF.

    If you want to test SQL skills, put a schema in front of the candidate and have them write some SQL that pulls out some specific information you require. Make it so they have to join tables together, etc. Maybe even make them write some queries that create the schema using only code if you want.

    Asking a .NET developer to design a system is not a test of SQL skills.

    Mary's answer was still a WTF but the question was pretty bad.

    Unless the position explicitly calls for "average-to-strong SQL experience", which it sounds like it did. Sounds reasonable to me.

    I wouldn't assume that "average to strong SQL experience" for a .NET developer means that you'll be designing schemas, stored procedures, etc. If that's what they truly want, then they want a DBA. Or a VERY highly paid .NET who happens to also have DBA skills.

    That's not DBA level questioning. If you can't even rough out a schema, even in a single table, to handle a scenario like that, you don't know crap about SQL or databases.

    She could have gotten away with saying "I'd have a table with a field for the request user's name, and a field for every level of required approval." Just show that she knows there's such a thing as a table and that it has fields in it to store data. She couldn't even stumble through that.

  • Maciej (cs) in reply to FredSaw
    FredSaw:
    DOA:
    TBL1: Index,Question - All fields req. TBL2: Index,Answer,AssociatedQ(IndexfromTBL1), RightWrongFlag All fields req.
    Allows for more than one right answer.

    Put a unique index on TBL2.AssociatedQ WHERE rightWrongFlag = true

  • zoips (unregistered) in reply to vt_mruhlin
    vt_mruhlin:
    Alex:
    Don't forget to submit your own interview story, from either side of the table.

    If Microsoft ever bothers to respond to all the resumes I've sent them, I might get a few stories to submit. I don't get it... the job I'm applied for is practiacally the exact same thing as my last job, so my resume should at least merit a phone screening.

    I think I pissed off one of their recruiters when I was in college. They're not the vengeful sort of company that blacklists people for trivial stuff from years ago, are they?

    I couldn't get them to notice me even if I'd showed up on campus with a bomb. I finally get in as a contractor, I'm here a month and they want me as an FTE. Go figure.

  • Franz Kafka (unregistered) in reply to KattMan
    KattMan:
    Franz Kafka:
    Meh. After the quiz has been entered, require a validation step before allowing the quiz to be used - count(*) and group will give you the number of correct answers for every question.

    No cookie for you. Why allow bad data in when you can know it is bad as it is entered? This is part of the point of the question I believe. It recognizes that there may be other ways, and asks about the problems in each of them.

    Because you can't enforce those rules and also allow people to move things around while building a quiz. Better to allow for this by introducing the concept of a quiz being PENDING, then VALIDATED and only exposing the VALIDATED quizes to students.

  • Gilhad (unregistered) in reply to FredSaw
    FredSaw:
    What kind of code are you writing, that doesn't access a database? Games, or something?
    Maybe a packet sniffing for VOIP, or rezident calculators, or compilers, interpreters, text manipulating programs, device drivers, defrags, music players, keyloggers just to name some of what I personally did.

    There is ofcourse much more such programs ... movie players, web browsers, firewalls ... too much to name it all.

    But for someone, who knows only database the whole world looks like one big table ;-)

  • Gilhad (unregistered) in reply to FredSaw
    FredSaw:
    What kind of code are you writing, that doesn't access a database? Games, or something?
    Maybe a packet sniffing for VOIP, or rezident calculators, or compilers, interpreters, text manipulating programs, device drivers, defrags, music players, keyloggers just to name some of what I personally did.

    There is ofcourse much more such programs ... movie players, web browsers, firewalls ... too much to name it all.

    But for someone, who knows only database the whole world looks like one big table ;-)

  • Franz Kafka (unregistered) in reply to zoips
    zoips:
    I couldn't get them to notice me even if I'd showed up on campus with a bomb. I finally get in as a contractor, I'm here a month and they want me as an FTE. Go figure.

    Did you actually show up on campus with a bomb? If you walk around with it, they'll just think you already work there.

  • Adrian (unregistered) in reply to Gedoon
    Gedoon:
    Five years from now she'll be the consultant who writes ten lines of crappy VB code and charges one gazillion $$$ for making your companys old system "enterprisy" and your boss will thank her for that.

    Makes you wonder whether we're not in the wrong line of work,

  • FredSaw (cs) in reply to Gilhad
    Gilhad:
    But for someone, who knows only database the whole world looks like one big table ;-)
    All the world's a table, And all the men and women merely columns: They have their deletes and their inserts; And one man in his time selects many out-parameters.
  • Jason Martin (unregistered) in reply to DOA

    It doesn't require that there is only 1 right answer and multiple wrong answers, nor does it require (excepting some deferred two-way constraints) that a given question have any answer at all, right or wrong.

  • Kyar (unregistered) in reply to snoofle
    snoofle:
    Aside: on interviews, sometimes a nervous (but competant) person might blank out on an otherwise reasonably simple question, if it catches them off guard. Honestly, when was the last time someone came up to you at work and said "design xxx and give me a working model in the next 2 minutes"?

    Twenty minutes ago.

  • BradC (cs) in reply to BitTwiddler
    BitTwiddler:
    Imagine that a professor needs to store a set of multiple-choice test questions, with a suite of answers for each question, exactly one of which is right.
    Good question, and some good discussion here already. My initial idea was:

    T1: QuestionID, Question, CorrectAnswerID T2: AnswerID, Order, Answer, QuestionID

    A more traditional one-to-many table relationship, with the correct answerID stored in the question table. I actually like the structure because it lets you put "order" in there easily (you do want "None of the above" to appear LAST in the answer list, don't you?).

    Problems include: I can't put a foreign key constraint on CorrectAnswerID, because the question record will most likely be created before the answer records. Also, how do we ensure the CorrectAnswerID doesn't point to an answer that actually belongs to a different question?

    Instead of an AnswerID in the Question table, you could put an "OrderOfCorrectAnswerID", defaulted to 1, so that the first answer entered is defaulted as the correct one, until the creator of the test changes it.

    Probably still not ideal, but at least as good as storing the correct and incorrect answers in different tables, which would then require trickier application logic to retrieve all answers, and randomize the display order.

  • Buffled (cs) in reply to Chris Kessel
    BitTwiddler:
    Mary:
    TBL1: Index,Question,CorrectAnswer - All fields req. TBL2: Index,IncorrectAnswer,AssociatedQ(IndexfromTBL1) All fields req.

    Professor ensures correct answer is correct, any incorrect answers associated to question are incorrect (only a human could do this). App logic only allows test to be created from questions that have at least 3 incorrect answers available to choose from.

    Hm. option two I think will work, and is a little bit less painful:

    Table1: Questions, PK id Table2: CorrectAnswers, PK qid(questions.id), answerid(answers.questionid,answers.id) Table3: Answers, PK questionid(questions.qid), answerid, seq

    Or maybe that's a little bit MORE painful...

  • Earl Purple (cs) in reply to elias
    elias:
    Does that actually get you out? bApprove is a constant, set to false...

    The only way to break out of that loop is to for RequestTimeOff to throw an exception (assuming it is not a macro with a break or even worse a goto in it. Note that a macro with a const_cast in it might seg-fault as you can't const_cast away for a variable that was declared as const, only one with a const modifier).

    Note also that we don't know the type of supervisor but it might be a class with operator[] overloaded, and which can take any value.

  • ChiefCrazyTalk (unregistered) in reply to zoips
    zoips:
    vt_mruhlin:
    Alex:
    Don't forget to submit your own interview story, from either side of the table.

    If Microsoft ever bothers to respond to all the resumes I've sent them, I might get a few stories to submit. I don't get it... the job I'm applied for is practiacally the exact same thing as my last job, so my resume should at least merit a phone screening.

    I think I pissed off one of their recruiters when I was in college. They're not the vengeful sort of company that blacklists people for trivial stuff from years ago, are they?

    I couldn't get them to notice me even if I'd showed up on campus with a bomb. I finally get in as a contractor, I'm here a month and they want me as an FTE. Go figure.

    That's not a bad way to go. I'm a Micosoft PM, coming in as a vendor. ("V-Trash")

  • SomeGuy (unregistered) in reply to BitTwiddler
    BitTwiddler:
    DOA:
    I'm not exactly a DBA so out of curiosity, how would the following compare with the above?

    TBL1: Index,Question - All fields req. TBL2: Index,Answer,AssociatedQ(IndexfromTBL1), RightWrongFlag All fields req.

    The problem is that there's no standard DB-centric way to prevent two or more flags from being set to "right" at the same time.

    Yes, you could do it with triggers or stored procedures, but those are hardly standard (the concept is, but not the implementation) and they aren't really part of the data model per se anyway.

    The thing is, most of the time you aren't designing a database that will work on every RDBMS. You are designing a database for whatever the standard is at the company you happen to work for.

    Where I work now it is MSSQL 2005, and you can use the two table layout above, create a Scalar UDF that takes the keys as parameters and checks the constraint criteria (Not more than one Y for this question, at least one Y before an N, etc) and returns a 1 or a 0. Then you can use that UDF in your check constraint on the flag field. It works fine.

    So you work with the tools that are at your disposal. That answer may not work at your place of business given the software that you use, but that doesn't make it the wrong answer.

  • Jay H (unregistered)

    My initial thoughts to define the database schema:

    Table USER Columns User ID: Employee unique sequence ID (primary key) Manager User ID: Employee's manager user ID, recursive reference to USER table. Other user meta data columns

    Table REQUEST Columns Request ID: 'Request' unique sequence ID (primary key) User ID: User ID of the originator of the request. Problem statement suggests time-off, but this is applicable to any form that requires authorization. Other request meta data columns

    Table (Join) REQUEST2USER Columns Request ID: foreign key to REQUEST table User ID: foreign key to USER table (where the Request ID and User ID make up the primary key). Approved Flag: true/false

  • Quinnum (cs) in reply to FredSaw
    FredSaw:
    nobody:
    Ugh! I studied CS because I find things like games, 3d graphics, artificial intelligence, compilers, and operating systems interesting. It totally sucks that, after I graduated, I am just now finding out that 99% of software development jobs is just an enterprisy - "collect data, filter it, organize it, display it" business. I should have just stayed at uni.
    LOL! You make it sound like you were interested in hotrods, so you became an auto mechanic, only to discover that you would always have grime under your fingernails.
    No, I think he's meaning more like he's interested in hotrods and became a mechanic, only to find that 99% of the work is on bog-standard family cars.

    I totally understand where he is coming from. Seriously, I am sick of writing "just another database frontend" after 10 years "professional". At least the 10 years before that I was having fun cracking games, mucking about with OS designs and writing hardware level stuff in assembler at home.

    Time for a change, but something like that is a major mental gear-shift now. I really need to start dabbling again in the fun stuff, but after a hard day's work, I'm more inclined to just crash on the couch when I get home rather than do even more programming.

    Note to kids: Don't make your hobby your job, unless you at least have another hobby to fall back on ;)

  • FredSaw (cs) in reply to Quinnum
    Quinnum:
    Time for a change, but something like that is a major mental gear-shift now. I really need to start dabbling again in the fun stuff, but after a hard day's work, I'm more inclined to just crash on the couch when I get home rather than do even more programming.

    Note to kids: Don't make your hobby your job, unless you at least have another hobby to fall back on ;)

    Dude, take your own advice! There's plenty of fun stuff to do AFK. I do woodworking as a hobby. I also play drums, and I've recently started taking lessons for Native American flute. If my only choices were computer or TV, I'd be on Prozac.

  • haha (unregistered)

    based on the title i thought it was talking about the democrats

  • ChZEROHag (cs) in reply to Chemisor

    The preview messed up my quoting. Will it stay like that? Probably. This forum software sucks.

    [quote user="Chemisor"]You mean "existing, godawfully bloated, poorly designed, and hard to use with C++" implementations? I agree that MySQL certainly has a place, but not for everything.[/quote]

    Wikipedia, that fantastically accurate arbiter of knowledge, lists no less than 116 databases which aren't MySQL. Of these you can be pretty sure some are lean, some are clean and some have good C++ implementations, should you actually want that.

    [quote user="Chemisor"]A typical desktop application does not need all those fancy features a database provides, making them little more than bloat and inconvenience. For example, a typical desktop application will have the following differences:

    1. Single user access. Nobody messes with your data but you, and nobody connects to it while you are working on it. This makes concurrency control unnecessary,[/quote]

    Never will more than one piece of software be used be somebody to access the same data at the same time. Why would anybody want to do that?

    [quote user="Chemisor"]scalability pointless,[/quote]

    My music database, small by many standards, consists of 6000 entries. My girlfriend's is just 200. A magnitude of 30 times is just irrelevant.

    [quote user="Chemisor"]and transaction control useless.[/quote]

    Bang! Goes the electricity. Goodbye! goes your crappy media player's un-transactioned internal database.

    [quote user="Chemisor"]2. Small data set. Regular people are not Fortune 500 companies and don't have terabytes of data. Most data sets are a few megabytes in size, if that. This means that all those painstaking query optimizations will not help much.[/query]

    Using find to locate a file on the filesystem takes an extraordinary amount of time I do not wish to calculate. Using the optimized locate command all of 0.4 seconds.

    (OK an index isn't strictly a query optimisation. Sue me.)

    [quote user="Chemisor"]3. Offline. Most people don't have broadband at home. If your database server is inaccessible, the app is unusable, which is very very bad. A git-like full clone solution is a far better choice for distributed data sets in this scenario.[/quote]

    I'm having to guess what this means, and I am assuming you are suggesting that a user cannot use his database-driven application when he is offline.

    Of the 117 databases mentioned earlier, some don't even provide communicate over some kind of socket.

    [quote user="Chemisor"]4. Run their own backups. When I want to back up a file, I want to back up a file, not a goddamn directory in some cryptically named location. I might even want to attach it to an email. Remember, small data sets![/quote]

    To pick a random example:

    [quote]An SQLite database is a single ordinary disk file that can be located anywhere in the directory hierarchy. ... Database files can easily be copied onto a USB memory stick or emailed for sharing.[/quote]

    [quote user="Chemisor"]5.Don't have a DBA degree. And consequently not willing to spend time on weird administration tasks that require connecting to a shell-like SQL interface.[/quote]

    To quote from the same source again, because it conveys exactly what I want to say and I can't be arsed to find anything else:

    [quote]There is no need for an administrator to create a new database instance or assign access permissions to users. ... No actions are required to recover after a system crash or power failure. There is nothing to troubleshoot.[/quote]

    [quote user="Chemisor"](Or at least that's what all the tutorials I've read do. What's with the goddamn text, people? This isn't 1976; we have GUIs these days! Or are you too cheap to make one?)[/quote]

    I can't even respond to this for the sheer amount of bile present at the thought of a GUI without a terminal emulator. I'll leave it to calmer folk.

    [quote user="Chemisor"]6. Goddamned text. Text-mode operations require parsers to convert to and from text data. Parsers are hard to write correctly.[/quote]

    Well I communicate in English, frequently using the written word, not Egyptian hieroglyphs.

    In fact I'm having a hard time seeing what the problem is here. Do you really suppose that in every case you have to write your own parser from scratch?

    [quote user="Chemisor"]IMHO, MySQL is simply not a good idea in this situation. It's the wrong tool for this job.[/quote]

    I would submit that MySQL is simply not a good idea.

    [quote user="Chemisor"]True, but they don't provide any benefits over the simple dump-my-data-and-index solution. They are actually worse, since they have C interfaces, which will defile your pure C++ design. There is NO excuse for using plain C interfaces these days. Good design requires structure, and C can't provide any.[/quote]

    C provides as much structure for your code a brick does for a house - that is to say: none.

    I wouldn't like to live in a house without any bricks though.

    [quote user="Chemisor"][quote user="AdT"] Bogus reason #2: When using embedded Firebird, for example, you can put the entire database in one file. [/quote] It's not a bogus reason if I haven't heard of some obscure package that allows one-file operation. Most other programmers will not have heard of it either.[/quote]

    I have, and I don't use it, I don't want to use it, and I don't write code for a living.

    Also we have this wonderful intarweb tool to help us research issues and acquire new knowledge.

    [quote user="Chemisor"]In a single user scenario you don't need a filesystem. You just write your data as you have it in memory, in an vector or something, into a file. Writing serialization routines is not that hard. If you care about memory usage, you might implement a sliding window backend, which isn't very hard either, but in most cases you don't need one.[/quote]

    You keep your filesystem-less Altair, but for the rest of us I think filesystems are a pretty nifty feature of a modern personal single-user desktop computer.

    [quote user="Chemisor"]Once again, I am not disputing the need for MySQL in a huge company with terabytes of data. There you have concurrency issues, scalability issues, security problems, query performance, and all that. However, for an end-user application this is all unnecessary.[/quote]

    I find it interesting that you say MySQL is unnecessary to counter AdT's suggestion that Firebird is a sane choice.

  • vt_mruhlin (cs) in reply to zoips
    zoips:
    vt_mruhlin:
    Alex:
    Don't forget to submit your own interview story, from either side of the table.

    If Microsoft ever bothers to respond to all the resumes I've sent them, I might get a few stories to submit. I don't get it... the job I'm applied for is practiacally the exact same thing as my last job, so my resume should at least merit a phone screening.

    I think I pissed off one of their recruiters when I was in college. They're not the vengeful sort of company that blacklists people for trivial stuff from years ago, are they?

    I couldn't get them to notice me even if I'd showed up on campus with a bomb. I finally get in as a contractor, I'm here a month and they want me as an FTE. Go figure.

    Maybe if my name was Hoop...

    I'm not going to quit my (admittedly crappy) well paying full time job and move across the country for a contract position.

  • kidpollo (unregistered)

    I prefer making short trick questions because If aI make an elaborate one I am sometimes biased on the way applicant should answer

  • Kuba (unregistered) in reply to Chemisor
    Chemisor:
    AdT:
    Let me guess... the reason that they never get finished is that people are trying to reinvent a DBMS so they don't have to use any of the existing, well-tested implementations?

    You mean "existing, godawfully bloated, poorly designed, and hard to use with C++" implementations? I agree that MySQL certainly has a place, but not for everything. A typical desktop application does not need all those fancy features a database provides, making them little more than bloat and inconvenience. For example, a typical desktop application will have the following differences:

    1. Single user access. Nobody messes with your data but you, and nobody connects to it while you are working on it. This makes concurrency control unnecessary, scalability pointless, and transaction control useless.

    Concurrency can exist within an application, even if just one user is present. In fact, if the application can or should do background tasks, you will depend on concurrency all the time. Databases will give you guarantees as to data coherency etc. If you don't use them, it's roll-your-own.

    2. Small data set. Regular people are not Fortune 500 companies and don't have terabytes of data. Most data sets are a few megabytes in size, if that. This means that all those painstaking query optimizations will not help much.

    A single digital picture these days is about a megabyte in size. I've got thousands of them - my wife's doing, actually. With our home video collection, that's few tens of gigs of data easy. I know. It doesn't fit on two DL DVDs anymore. My email folders (raw text) are about 2 gigs now. I wish they were stored as a database (or a few) - as it is, if the indices "go bad", it takes ages to regenerate, and most email apps are pretty unresponsive when indices are being generated, or when large operations on email are being done.

    3. Offline. Most people don't have broadband at home. If your database server is inaccessible, the app is unusable, which is very very bad. A git-like full clone solution is a far better choice for distributed data sets in this scenario.

    Using a database doesn't imply a remote server.

    4. Run their own backups. When I want to back up a file, I want to back up a file, not a goddamn directory in some cryptically named location. I might even want to attach it to an email. Remember, small data sets!

    There are tens of thousands of foobarbaz.sqlite.bz2 files transferred everyday by every single Fedora Core 8 system (and possibly others). They are a few hundred kilobytes in size, and contain a big heap of data about software repository contents.

    5.Don't have a DBA degree. And consequently not willing to spend time on weird administration tasks that require connecting to a shell-like SQL interface. (Or at least that's what all the tutorials I've read do. What's with the goddamn text, people? This isn't 1976; we have GUIs these days! Or are you too cheap to make one?)

    If you're deploying an application for an end-user, it's your job to make sure it doesn't require a DBA degree. If you do your homework, it won't.

    6. Goddamned text. Text-mode operations require parsers to convert to and from text data. Parsers are hard to write correctly.

    Text where? I don't know what databases have to do with text. You can store text in them, but not necessarily. SQL is machine-generable, at runtime, and the parser is in the database, so that you don't have to write one.

    Chemisor:
    I want to make software for regular people, to use on their personal computers, and regular people don't have a database server running.
    Bogus reason #1: Embeddable DBMSes like Berkely or Firebird do not require a database server.

    True, but they don't provide any benefits over the simple dump-my-data-and-index solution. They are actually worse, since they have C interfaces, which will defile your pure C++ design. There is NO excuse for using plain C interfaces these days. Good design requires structure, and C can't provide any.

    The "C" interface to SQLite is very reasonable, and it's trivial to add C++ glue on top of it if you are so intent on doing it. Maybe if you were to reuse that code across projects it'd make sense.

    Chemisor:
    and would have trouble understanding why data has to be stored in some central location and in a whole directory instead of a single file. Frankly, I have trouble understanding that myself.

    Using a database doesn't imply all the bogus things you think it implies. The "central locaiton" and "a whole directory" are completely bogus. Even "server-style" databases can be configured to store data in a single, given directory.

    Bogus reason #2: When using embedded Firebird, for example, you can put the entire database in one file.
    It's not a bogus reason if I haven't heard of some obscure package that allows one-file operation. Most other programmers will not have heard of it either.

    I'm sorry to say that, but you seem pretty clueless in that department... I feel sorry for "other programmers" who haven't heard of embedded databases, but their application might otherwise call for one...

    Chemisor:
    In a single user scenario you don't need a filesystem. You just write your data as you have it in memory, in an vector or something, into a file. Writing serialization routines is not that hard. If you care about memory usage, you might implement a sliding window backend, which isn't very hard either, but in most cases you don't need one.

    The problem is that you are gonna be implementing all that: vector or something, serialization, parallel access (multiple threads, etc) who knows what else. Is indexing stuff yourself really all that much fun? Is having an exportable, mostly self-documenting file format really all that bad? If you have say an SQLite database, all you have to document is your data scheme. If it's simple, you may even skip that. If it's roll-your-own, you have to document it at the bit level. I also wish you luck with your application crashing or computer loosing power/rebooting at the wrong moment. Even a low-key database like SQLite will be robust enough in such circumstances. When you roll-your-own, I can almost guarantee you're not gonna be conservative with your data loss.

    You seem like rambling with wrong preconceptios and lack of will to understand the technology you're rambling about.

    Even Prevayler, which is probably what you'd like, is way more than some homegrown "serialize this or that" system. It implements database functionality (transactions, replicas, crash-worthiness) but lets you use your favourite data structures. Porting Prevayler to C++ would require some source code pre-processing like done in Qt's MOC system.

    Cheers, Kuba

  • nobody (unregistered) in reply to Quinnum
    Quinnum:
    No, I think he's meaning more like he's interested in hotrods and became a mechanic, only to find that 99% of the work is on bog-standard family cars.

    I totally understand where he is coming from. Seriously, I am sick of writing "just another database frontend" after 10 years "professional". At least the 10 years before that I was having fun cracking games, mucking about with OS designs and writing hardware level stuff in assembler at home.

    Time for a change, but something like that is a major mental gear-shift now. I really need to start dabbling again in the fun stuff, but after a hard day's work, I'm more inclined to just crash on the couch when I get home rather than do even more programming.

    Note to kids: Don't make your hobby your job, unless you at least have another hobby to fall back on ;)

    You hit the nail on the head! I did make the mistake of turning my hobby into a career - and didn't realize it because the stuff I did in university was fun (well, until the work piled on and I had to pull all-nighters to get it finished), and I used my summer vacations to explore what I learned making some really cool apps. Now, I use less than half of what I learned, and only the boring bits at that.

    Time for a new hobby, and perhaps a visit to the career counselor. ;)

  • Kuba (unregistered) in reply to Chemisor
    Chemisor:
    Kuba:
    Yeah, because computers never crash, and you never ever have to Undo anything.

    Most user applications don't support undo over a restart.

    Because implementing it without something more functional than "serialize and dump" may be a bit harder than necessary.

    I don't see that as a limitation. And as for handling crashes, the most common way is to write out a temp file and then move it over the original. Regular people don't have terabytes of data and this temporary waste of space is not an issue.

    Ok, let's say it's a simple medical application: a few screen forms with patient data, and some test results which are collected and saved. This is for a small medical practice, and data is not shared. Say a few tens of megabytes worth of data, usually. What you're proposing is that on each screen if the data is changed, the whole file has to be rewritten. That's fairly ridiculous. Unless you strive to code it well, it will always give noticeable slowdown when you go between screens.

    Kuba:
    1. Don't reinvent the wheel. 2. Don't reinvent the wheel. 3. Um, don't reinvent the wheel?

    Somebody has spent tons of time debugging the database. At the time I abandoned the plain-text file, the parser still had known bugs which had no easy workarounds (luckily they didn't affect any users).

    1. Don't use goddamn text formats. 2. Don't use goddamn text formats.

    I don't know why you insist on rambling about text formats. What the heck do the have to do with our discussion?! Databases are pretty binary-oriented and if you look at say sqlite file, there will be about as much text as you put there yourself as data. If there won't be any text data stored there, you won't see any text, nor will you have to deal with any.

    3. Sometimes you need to reinvent the wheel because you are making a bicycle instead of a race car.

    I'm not saying databases are a cure-all. I'm merely saying that many applications where stubborn developers try to abstain from using databases, would benefit, if used properly. You seem to be such an example.

    Kuba:
    How's that different from managing an address book, a list of software packages, or a list of files in software packages?

    The data set is small, so you don't need fancy features. Yes, of course you can use SQLite, but you can also use a sledgehammer to drive in nails.

    The whole "small datasets" stance applies to what real-life application, again? Because most people I know have unmanageably-sized email stores, picture stores, etc. Even some people's contact lists take a few megabytes on their own. And for those who always attach pictures to their contact lists, the latter soon become pretty unmanageable. An embedded database would allow to nicely store images as BLOBs (raw data) together with everything else, without having to worry much.

    Kuba:
    "Consumers" routinely use software like photo editing and media managment/editing in general, even computation (students!). Just two examples in non-business setting. Go to local computer store (that's not BestBuy to you) and see what software is on the shelves. Games are <50%.

    Yes, do go. And then count the ones that are actually new.

    What has new got to do with our discussion?!

    And where is my Norton Utilities?

    With fading away of dos-based systems, I found that I never really had a use for it. I used it daily in DOS era for sure. The need for it died away soon thereafter.

    Or a decent defragmenter that can compact that FAT32 partition I have to keep to share files with Linux?

    Just use NTFS.

    Or a word processor where I can permanently get rid of that stupid WYSIWYG lets-show-the-user-a-page-like-paper look?

    Um, even Word has outline view. But seriously: your Google skills are lacking. Ever heard of LyX? You should have.

    Or a music player that doesn't try to look like a physical stereo, faking perfectly good system controls with pseudo-knobs and buttons?

    I don't think xmms or MS media player looks like a physical stereo.

    Cheers, Kuba

  • phaedrus (cs) in reply to Chemisor
    Chemisor:
    Kuba:
    1. Don't reinvent the wheel. 2. Don't reinvent the wheel. 3. Um, don't reinvent the wheel?

    Somebody has spent tons of time debugging the database. At the time I abandoned the plain-text file, the parser still had known bugs which had no easy workarounds (luckily they didn't affect any users).

    1. Don't use goddamn text formats. 2. Don't use goddamn text formats. 3. Sometimes you need to reinvent the wheel because you are making a bicycle instead of a race car.
    1. Use text formats.
    2. Use text formats.
    3. If you are dealing with enough data to need more than a text format can handle, use a DB, embedded or server depending on the app.

    Really. lex and yacc (try flex and bison on Linux) have been around and stable for over 30 years. It's blindingly easy to write parsers for a custom text format. Writing one by hand is stupid and bug prone. They even have C++ interfaces.

    Using a custom binary format will make your fellow Linux users hate you--since you've just made it a pain to attack your file with my command line tools.

    Yes, that's right, I said command line tools. Tons of people still use them. Particularly on Linux, since it has an amazing set called 'GNU'--you might have heard about it. Look into them, you might learn something about using a Real Computer.

    If the text format is too cumbersome (too much data, performance), then the right thing to do is go with a database, for the aforementioned bug count and concurrency advantages.

  • knightofni (unregistered) in reply to scruffy
    scruffy:
    We will need a factory?

    No, I think you'll find that we demand a shrubbery!

    Now _that_ made me laugh out loud
  • mark (unregistered) in reply to Tammy
    Tammy:
    So exactly how would any of you have answered this question?

    I would sketch out a paper form with signature lines for each of the layers of authority.

    It would be more usable and flexible than a computer solution.

  • ludus (unregistered) in reply to mark
    mark:
    Tammy:
    So exactly how would any of you have answered this question?

    I would sketch out a paper form with signature lines for each of the layers of authority.

    It would be more usable and flexible than a computer solution.

    Unless the layers of authority are divided by geography as well. Say, US vs India vs Great Britain? Shuffling said paper around feels a bit hazardous not to mention time consuming. AND prone to disappearing.

  • Hans (unregistered) in reply to rd
    rd:
    const bool bFlag = false; const bool bApprove = bFlag; int index = 0;

    while(!bApprove){ RequestTimeOff(supervisor[index++]); }

    That's a lot like the algorithm my boss uses:

    bool MayHaveDayOff (Employee &emp) { return false; }

    I still think it is broken in some ways...

  • Grovesy (cs) in reply to ChiefCrazyTalk
    ChiefCrazyTalk:
    zoips:
    vt_mruhlin:
    Alex:
    Don't forget to submit your own interview story, from either side of the table.

    If Microsoft ever bothers to respond to all the resumes I've sent them, I might get a few stories to submit. I don't get it... the job I'm applied for is practiacally the exact same thing as my last job, so my resume should at least merit a phone screening.

    I think I pissed off one of their recruiters when I was in college. They're not the vengeful sort of company that blacklists people for trivial stuff from years ago, are they?

    I couldn't get them to notice me even if I'd showed up on campus with a bomb. I finally get in as a contractor, I'm here a month and they want me as an FTE. Go figure.

    That's not a bad way to go. I'm a Micosoft PM, coming in as a vendor. ("V-Trash")

    Managed all three, vtash, itrash, FTE-wait-the-shares-are-worthles-sucker, and finaly back to itrash (but happy)

  • MT (unregistered) in reply to BitTwiddler

    The real world solution would be to give the "incredibly bad programmers" an application level interface for accessing the database. This should make implementing the requirements and any future changes pretty trivial. Don't give them direct access to anything.

  • jmroth (cs)

    I'd just use up my phone joker and call Paula ^^

  • The Knight Of "Ni!" (unregistered) in reply to knightofni
    knightofni:
    scruffy:
    We will need a factory?

    No, I think you'll find that we demand a shrubbery!

    Now _that_ made me laugh out loud
    Then, when you have found the shrubbery, you must cut down the mightiest tree in the forest... Wiiiiiithh.... A HERRING!
  • AnonymousFan (unregistered) in reply to Dion
    Dion:
    Wow, I applaud the interviewers tolerance for such stupidity. I have to say that I would have totally ripped her for giving such a dumb answer. She probably would have switched professions.

    Well, there's no harm in being polite.

    Especially not even when there's fun to be had at another person's expense.

    Why? -Because it's exactly the sort of fun that a certain type of person enjoys the most..

    Are you one of those.. ?

  • Riho (unregistered)

    I don't know which one would be worse person to hire - Clueless Candidate or Chemisor. Somebody who has never learned anything or somebody who has learned only one thing...

    I wrote my own textfile databases last time in DOS times. They managed their job, but changing the dataformat was total pain in.... With databases (I use embedded Firebird) you just run couple of update queries and that's it. And they are much faster and easier to handle. If using Delphi then there are wrapper components for database connectivity. You can have small application up and running in 30 min. And end-users don't have clue what you are using - there is absolutely no database administration.

  • John (unregistered)

    I interviewed someone who had J2EE Expert on their resume, so when I got the the techinical questions I asked: Me: Can you tell be what type of EJBs there are? J2EE Expert: Err... Hmm... Um... Session! At last I thought... Me: Any others? J2EE Expert: Hmm... Erm... A couple of minutes pass! Me: I'll give you a clue. Entity! J2EE Expert: Yeah that's right.

    I mean really, if you put J2EE expert on your resume, then you should be able to rattle on about stateful session beans, stateless ones, entity beans, message beans, message driven beans, container managed persistence, bean managed persistence, deployment descriptors, and entity relational mapping for hours right?

    Maybe I should apply for a high paying job like Aerospace Engineer and just bluff my way through the interview. If I get the job and some of the rockets blow up, no one will notice as that sort of thing happens all the time (although they might catch on after five critical mission failures in a row).

  • Biff (unregistered) in reply to John
    John:
    I mean really, if you put J2EE expert on your resume, then you should be able to rattle on about stateful session beans, stateless ones, entity beans, message beans, message driven beans, container managed persistence, bean managed persistence, deployment descriptors, and entity relational mapping for hours right?

    Well, yes up to a point. But are you confusing Java EE with EJB? Currently I'm writing an application that uses (Acronym flood alert) JMS, JTA, JAAS, JSP, JDBC and RMI amongst other things, but not EJB.

    All these are J2EE aspects so my CV says 6 years of experience with J2EE. Do you think I'm misrepresenting myself?

  • billswift (unregistered) in reply to ludus

    mark: Tammy: So exactly how would any of you have answered this question?

    I would sketch out a paper form with signature lines for each of the layers of authority.

    It would be more usable and flexible than a computer solution.

    Unless the layers of authority are divided by geography as well. Say, US vs India vs Great Britain? Shuffling said paper around feels a bit hazardous not to mention time consuming. AND prone to disappearing.

    In the company I work for it also forces promptness; supposedly the manager cannot finalize the new schedule until he has dealt with (approved or disapproved) a pending request.

  • fbjon (cs) in reply to rd
    rd:
    So you're saying that an effective chain of command employee time off approval system couldn't be designed with a variable, a constant and a flag? The HR department where I work implemented something in C++ very similar to what Mary suggested.

    const bool bFlag = false; const bool bApprove = bFlag; int index = 0;

    while(!bApprove){ RequestTimeOff(supervisor[index++]); }

    My thoughts exactly. She could very well have had a design in mind, but simply communicated badly.

  • tadghostal (cs) in reply to Cheatah
    Cheatah:
    "You mean that you wouldn't use a variable, a constant or a flag? Then what would you use?"

    Well, maybe a MaryBean.

    Best comment ever!

  • tadghostal (cs) in reply to Spell Checker
    Spell Checker:
    brazzy:
    Can you say "beaurocractic monstrosity"?
    No, I can't. Only "bureaucratic monstrosity".

    I can say BuMo. Does that count? Did I ween?

  • tadghostal (cs)

    This is why we need technical interviews. Sure, that's an obvious statement for most of you, but where I work, our IT Department head is someone whose IT career consists of a single VB6 application (actually, only a partial one).

    Having an ego the size of [insert large item here], he's insisted on doing all the hiring of IT staff himself, and as the sole interviewer.

  • JB (unregistered) in reply to BradC
    T1: QuestionID, Question, CorrectAnswerID T2: AnswerID, Order, Answer, QuestionID

    Your solution is the best one, IMHO.

    For your first problem (can't put a foreign key constraint on CorrectAnswerID), just use a constraint that is enforced at commit time rather than insert time, and insert the question and right answer in the same transaction.

  • Incen (unregistered) in reply to BitTwiddler
    BitTwiddler:
    Imagine that a professor needs to store a set of multiple-choice test questions, with a suite of answers for each question, exactly one of which is right. However, the programmers building this app are incredibly bad, so you want to protect the database as much as possible from bad data (two 'right' answers, no 'right' answers, answers without questions, etc), by using indices, RI, etc. Note that students' answers need not be stored; only the questions and set of potential answers.

    Propose a set of tables/indices/RI to store this data. Are there any 'holes' in your solution?

    Initial answer: table "question": id(auto, pk), text(uniq, req), rightanswer(fk answer.id, uniq) table "answer": id(auto, pk), question(fk question.id, req), text(uniq, req)

    The id columns are, of course, not strictly required, but convenient. The two-way referential integrity requires an ALTER TABLE to establish. I'm assuming a (unique foreign) key column can be null, because I seem to recall it can. The hole is that this design allows for questions with no right answers (or alternatively answers with no questions). To require them, you would need a capability to verify RI only at the end of a transaction, and I don't really know how well that's supported.

    Fixed answer: table "question": id(auto, pk), text(uniq, req), rightanswertext(req) table "wronganswer": question(fk question.id, req), text(req) constr uniq(wronganswer.question, wronganswer.text)

    This solution conveniently avoids the two assumptions in the previous design. The hole here is that this design allows for identical wrong and right answers for the same question. This would be simple enough to fix with a constraint query, but then, that's a bit of a cop-out considering the RI spirit of the question. I might look into the RDBMS manual for any possible mention of shared indices.

Leave a comment on “The Case of the Clueless Candidate”

Log In or post as a guest

Replying to comment #:

« Return to Article