|
|
|
SledgeHammer01 wrote: I had one large company disqualify me because they assumed I couldn't write
socket code because I didn't memorize the 7 layer OSI model
lol.
I had one interviewer who got visibly upset with me after I said I was capable of writing database code but I couldn't explain the 5 rules of normalization.
Might note that I still can't. But I do know that 2 of them are absolutely worthless for practical programming.
|
|
|
|
|
jschell wrote: I had one interviewer who got visibly upset with me after I said I was capable of writing database code but I couldn't explain the 5 rules of normalization.
SEVEN!
There are seven levels of normalization as defined, with 6NF being the top. None of the companies that I worked for went beyond BNF. Now, would that moron be able to explain why he'd need to normalize to the fifth level, or was it merely random?
Bastard Programmer from Hell 
|
|
|
|
|
You know, I couldn't name a single one of these rules, but I went and looked up the poster. OMG!!! Instead of having duplicate data break it out into a separate table and create a FK index into it!! OMG... you are so high brow!! (not directed at you lol, but the people who care about knowing the 'book term' I mean)  . Ok, I've been designing my tables like this for 16 yrs, but seriously had ZERO clue that this is what it was called. Ok... guess I suck at SQL now too .
Many years ago, I went to an interview at AutoByTel when I was first starting out in C# and the guy asked me if I knew what boxing & unboxing was. I had no clue. I went home and looked it up and was like OMG!!!! its passing around something as an object!!! OMG!!! I don't know C# at all. I have never done anything so complex!!! That guy must have 7 phd's in C#!!! He is brilliant!!
|
|
|
|
|
I once got ask why a variable would be scoped with friend (back in my VB days) I had no idea, 3 hours later I certainly did but the opportunity was long gone!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
SledgeHammer01 wrote: Pretty much Think most "real" companies ask these retarded doomsday questions now.
That's a good thing; it's not like there's only one job available, and I almost always walk away smiling
SledgeHammer01 wrote: I had one large company disqualify me because they assumed I couldn't write socket code because I didn't memorize the 7 layer OSI model
You need a thief to catch a thief, and a programmer to identify a software-developer. If they're looking for someone who can memorize well, they are obviously not in the position to pick a decent developer.
Sounds like a bureaucracy, and you can't put a worker between people who merely shove with paper and responsibilities.
Bastard Programmer from Hell
|
|
|
|
|
SledgeHammer01 wrote: so stuff like databases, etc. are irrelevant...Say you are working for the DMV
First thought - the requirements are broken, because of course a database is the solution.
Absolutely no one is going to just store the plate number. And of course no one would save the entire range.
So one is left with the silly task of creating a database from scratch.
Databases are based on indexes and pages. Presuming all they care about is the indexed plate number you just create a sparse b-tree index. First block in the file is the first letter followed by an page index (or zero for no use) to the next page and next letter. Each page in this structure has a fixed size with a pointer to the real record.
36 * 8 bytes
For optimization reasons you can increase node size to 2 characters, which is more likely to be reasonable with native storage device page size.
SledgeHammer01 wrote: ...because it didn't scale to handle the worst case or even beyond 200M ranges.
And *again* broken requirements. There are about 250 million vehicles in the United states. License plates are issued by state and other entities. So a valid bid for a system at the current time would never need to manage 200 million.
|
|
|
|
|
The point was to deal with a large amount of data, not license plates specifically  .
|
|
|
|
|
|
Collin Jasnoch wrote: I have noticed a pattern with him missing the point on many posts
You're just bitching b/c you got stuck in a troll thread in the Silverlight forum!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Collin Jasnoch wrote: I have noticed a pattern with him missing the point on many posts. Gets stuck on the hypothetical part.
When people decide to denigrate me I always appreciate it if they try to be a bit creative about it.
Just saying.
|
|
|
|
|
SledgeHammer01 wrote: T<layer>he point was to deal with a large amount of data, not license plates specifically
My point is that I build business systems, not hypothetical ones. That of course is generally the point of a 'job' interview.
And a business system would use a database, not expect one to build that same functionality from scratch.
|
|
|
|
|
jschell wrote: That of course is generally the point of a 'job' interview
False. The point of a job interview is to get the job  .
jschell wrote: My point is that I build business systems, not hypothetical ones
Not trying to be a douche or anything , but have you been on a job interview recently? Not at a mom & pop shop or a non-software company that happens to have a few software people, but a *REAL* mid-to-large sized *TRUE* software company (Google, Amazon, Microsoft, etc)? They *ALL* ask hypothetical / algorithm questions like that. I even posted the EXACT question I got at my Google interview as a response to someone who said this question was retarded (besides you, I mean ). Only a guy who didn't know the first thing about interviewing would ask questions like "what's the difference between delete and delete[]?", or "what's the difference between Finalize and Dispose? etc". Basically someone who went on Google and googled C# interview questions.
It sounds like (again no offense intended) you are a guy who prefers to write code without having to think about it much. Sorry, thats not coming out right ... but hopefully you know what I mean... you want to be handed a set of business requirements and want to fullfil those business requirements and call it a day vs the guy who wants to do something new.
I've written MFC, Winforms and WPF apps til I'm blue in the face. I consider them all to be the same on a fundamental level. One app is working on widgets and another app is working on shipping the widgets between warehouses. Yet another app that does a similar (yet different) thing on wizzers. Its all the same. Essentially you are slapping controls on a form and mapping them to event handlers and running a sql query or whatever.
If you want a job where you do new things and do stuff thats outside the box, you would have an interview where you are asked to think outside the box.
If you have no interest in that type of work, I could see how you would refuse to answer hypothetical questions.
Unfortunately, I think you will find that most companies THINK they are doing something new and exciting when they aren't. My boss here thinks we are doing something new and exciting... but in reality, its a rehash and there are 10 competitors out there who do it way better then we do.
|
|
|
|
|
SledgeHammer01 wrote: If you have no interest in that type of work, I could see how you would refuse to answer hypothetical questions.
New technologies have nothing to do with hypothetical questions.
Of the interviews I have been in and the ones that I have given my experience would suggest that developers in general make poor interviewers. They ask technically specific questions, hypothetical or not, without understanding what they can realistically expect as an answer. Sometimes they don't even understand the breadth of the question they are asking.
Some interviewers understand that the lack of merit in their technological questions (in the way they are given), many are ignorant of the nature of how it might be accomplished, and some just refuse to even consider the possibility that confusion in the interview process might originate from the interviewer and not the interviewee.
|
|
|
|
|
1) It wasn't my interview question, it was one that I got
2) You still don't seem to understand the POINT of the question. It is NOT for you to give the "best" or "right" answer. It is to judge how you THINK. Why do you have such difficulty understanding that?
If I was hiring a junior or mid-level software engineer / coder, I would ask him/her basic coding questions to judge their coding skills because I would only give them CODING assignments.
On the other hand, if I was hiring a Senior / Team Lead Software Engineer, I'd expect them to be able to SOLVE PROBLEMS. That was a question designed to see how you SOLVE PROBLEMS.
If you do not know the difference between a coder and a software engineer / architect, I can see how you would not understand the point of the question. Judging by the fact that you are still stuck on the facts that you "aren't allowed" to use a database or that there aren't 78B license plates in the world, it would imply to me (or any other interviewer) that you do not have good problem solving skills and/or are unwilling to think outside the box.
If I am hiring a senior guy, I would not waste my time asking him stupid C# programming questions out of the "C# interview questions" hand book because I would not expect a guy who can not code to have made it that far.
But just for arguments sake, since you aren't interested in jobs that require you to think, what WOULD you consider a good interview question?
modified 4-Feb-12 15:57pm.
|
|
|
|
|
SledgeHammer01 wrote: it was one that I got...It is to judge how you THINK. Why do you have such difficulty understanding that?
Perhaps because I have experienced it more than you?
The fact that either you presume that the interviewer is only interested in your thought processes or even if the interviewer actually told you that doesn't in fact mean that the interviewer is actually going to be comfortable accepting answers that meet that goal.
I have been an interviewer in group interview situations where developers specifically told the interviewee that they were asking open ended questions and yet it became almost immediately obvious that the interviewer was fishing for very specific responses. I have also been on the receiving end of that as well.
SledgeHammer01 wrote: If you do not know the difference between a coder and a software engineer /
architect
Hopefully I know that since I have been both and worked with both.
SledgeHammer01 wrote: ...what WOULD you consider a good interview question?
Thought that it was implicitly obvious that my problem with the initial question was the explicit requirements. If the question was open then letting the interviewee suggest a database and/or bring up limitations of the questions itself (about realistic volumes) would certainly suggest some level of expertise.
Conversely as an open ended question if the interviewee attempted to suggest an in memory memory model (again since I would leave it open ended) it would suggest that the developer doesn't have significant real world experience (presuming that their resume didn't already reveal that they were a junior level.)
|
|
|
|
|
jschell wrote: Perhaps because I have experienced it more than you?
Experienced what? Getting thrown out of interviews for being a tool? lol. No, I haven't. The only thing I have heard from you so far is that you refuse to answer the question because its "too conceptual" and "not a real world scenario" and you would only do it with a database and are not open to any other method. In fact, you are so offended by the stupidity and unrealism of the question & scenario that you would just walk out of the interview before being thrown out  .
Pretty much everybody else who responded to this thread was able to offer a non database based solution of some sort. You are the only person who has been downright throwing a tantrum at the mere thought of getting such a stupid question.
|
|
|
|
|
SledgeHammer01 wrote: is that you refuse to answer the question because
I don't believe I said that.
SledgeHammer01 wrote: scenario that you would just walk out of the interview before being thrown out
No I didn't say that.
SledgeHammer01 wrote: Pretty much everybody else who responded to this thread was able to offer a non
database based solution of some sort.
I suggest that you might want to read all of my responses. Or re-read them.
|
|
|
|
|
How about a ZDD of 36 * 7 variables? If there are any patterns (and there will be) it should do fine. As a bonus you can give it more interesting queries than just "is this one available?" or even "give me the lexicographically smallest available number" - such as, "give me all the available numbers that have 'R0FL' in them"
By the way, why is a packed bit array out again? 9GB isn't that much at all..
|
|
|
|
|
Never even heard of a ZDD haha. From googling it, it looks like a DAWG type thing?
|
|
|
|
|
Well, not exactly, but I can see how they could be called related.
|
|
|
|
|
Lol, well, I tried looking at a paper on it and it went way over my head, but it was a technical paper.
|
|
|
|
|
|
As has been said, a database is likely the best general solution. Otherwise, a word search tree (similar to the DAWG you mentioned) might work fairly well.
One of the problems with the situation described is that few real-world cases require each client to maintain its own copy of such a large collection of data. Usually there will be connectivity to a shared server of some sort. However, there are situations in which a client must continue working when the connection is disconnected. But in such situations, the client probably shouldn't be allowed to add data to the collection.
Anecdote time: I was once involved in such a situation. What had been done was to store four bits per item in a binary file (this was on DOS by the way), so for instance the first byte of the file held the status for item 0 in the low nybble and the status of item 1 in the high nybble, etc. Access to a particular item's status was a simple calculation, disk seek, and read one byte. I don't remember what the highest numbered item was at the time -- let's say a million -- so that would be about a half MB of disk to store the list. Once a day a whole new file was downloaded to each connected client and throughout the day updates would be sent. If a client was disconnected it would start getting updates when it reconnected and a whole file within a day -- this was fine for the purpose.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
