Comment On The Case of the Clueless Candidate

Today's Tale from the Interview comes from Scott McNair. Don't forget to submit your own interview story, from either side of the table.  [expand full text]
« PrevPage 1 | Page 2 | Page 3 | Page 4Next »

Re: The Case of the Clueless Candidate

2008-01-08 10:25 • by Incen (unregistered)
169738 in reply to 169737
Incen:

constr uniq(wronganswer.question, wronganswer.text)

That would be wronganswer.pk(question, text)

Re: SQL skills

2008-01-08 10:37 • by bob (unregistered)
169744 in reply to 169618
<snip/>

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.
<snip/>

My maths is a touch rusty, but isn't the difference between 6000 and 200 just 1 order of magnitude?

Re: The Case of the Clueless Candidate

2008-01-08 11:10 • by JB (unregistered)
169772 in reply to 169737
What I don't like at all with the "Fixed Answer" is that if you need additional attributes on the questions (ex: order, background color, font, whatever), you need to have all these columns on both tables. This is ugly, and must certainly be against the rules of one of the normal forms (don't ask me which one, this is much too old for my brain to remember).

Re: The Case of the Clueless Candidate

2008-01-08 12:07 • by ChiefCrazyTalk (unregistered)
169797 in reply to 169656
Grovesy:
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)


Huh? You went from Vendor, to intern, to FTE, to back to being an intern? Not the usual career progression...

Re: SQL skills

2008-01-08 15:10 • by Congo (unregistered)
169847 in reply to 169744
1.477 to be exact

Re: The Case of the Clueless Candidate

2008-01-08 15:34 • by Andrew (unregistered)
I worked with a girl that once basically told an internal customer to kiss her axe. This of course broke up the meeting and led to about half a day of "OMG, did she say that" gossip. Early in the second half of the day, the customer said all will be forgiven if the offender would just appologize. Of course she didn't. They ended up terminating her that afternoon.

Why did she not care about her job? She was about to be rich. You see, she had just opened an bank account and put a minimum balance of $1,000 in there. She had this contact over seas who need an US bank account so they could export their money before the evil foregin government seized it. As a result, the cussing co-worker would be given a 10% cut of $10,000,000. So why should she care?

Re: The Case of the Clueless Candidate

2008-01-08 16:19 • by baboo
169865 in reply to 169436
The question wasn't "How would you implement a system to track employee leave requests through the approval process?" It was, "What underlying data structure would you use?"

Assuming that the poster's statement that they were looking for someone with "SQL experience" really meant that they were looking for someone with the ability to reason intelligibly, Mary could have answered something like this:

"OK, so the data you can depend on a leave request having that will completely define an individual leave request for one employee, are:

1) a unique employee identifier
2) the start of the leave period
3) the duration of leave period.

The other major part of a leave request is the approval chain. Here's a good way to frame this part of the problem - Every leave request has an ultimate "approval authority," which is defined by your company's internal organization and policies.

Assuming a uniform, hierarchical organization, a really simple way to represent this would be to define a numerical value to the different levels of approval - section manager approval == 10, store manager == 20, regional manager == 30, etc.

Based on the duration and start time of the leave period, you could algorithmically define a numerical required approval level for each leave request, which would be stored in a member variable (or column, or whatever) of the proposed data structure.

A member variable would store the next approval level required. Another would be used to store the status of the request transaction (essentially, "It's being sent up," or "It's being kicked back") And another would be used to store a text message to go along with the request - for lower-level requesters, this would be populated with maybe something like, "Sally needs leave for toenail therapy," and then maybe at the next higher level, "Employee SLLY1443 needs this weird therapy, and I can cover for her absence by realigning people from one of my other sections - recommend approval." If it gets kicked back down, this might be populated with something like, "No, I need more info on the impact of the absence of this employee before I approve." etc.

So, the data structure might look something like this:

1) INT Employee ID
2) DATETIME Leave start datetime
3) DATETIME Leave duration
4) INT Required approval level
5) INT Current approval level
6) INT Next level/Employee ID
7) INT Array Previous levels/Employee IDs
8) BOOLEAN Sent-up/Kicked-back Status
9) TEXT Message

... I mean, I just pulled this out of my ass, based on a few assumptions, without being able to ask any questions.

Mary/Paula's answer of "Uh... I think maybe a variable, a constant, and a flag?" was just retarded.

Re: SQL skills

2008-01-08 17:27 • by Iago
169880 in reply to 169575
Chemisor:
Andy:
Chemisor:
(snip)

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

(snip)


There is a very good solution for that: http://www.fs-driver.org/


According to the FAQ, that driver does not support access rights, which means that any application will be able to write anywhere in my Linux fs tree. That is unacceptable. I don't trust Windows applications and mostly just boot there to play games, fill in pdfs (as in tax forms), run uTorrent, and perform other sundry tasks that Linux doesn't do yet. Anything shared between the two must be isolated and totally non-critical.
You don't want your problems solved, do you? You're complaining that FAT32 is not a good solution to your problem, but you reject every better solution out of hand.

ntfs-3g is not complicated; you install it with your package manager and then it just works. You don't have to mess with FUSE yourself, all that happens behind the scenes. All you would do is click a few times and your life would become simpler.

And it's hardly difficult to stop Windows applications being able to write anywhere in your Linux fs tree with the Ext2 IFS. All you have to do is, um, only mount a partition you want them to be able to write to. They can't mysteriously access partitions you haven't mounted, you know. So you would replace your current unsatisfactory FAT32 shared partition with a vastly more flexible Ext3 shared partition, and your life would become simpler.

You're welcome to hang onto your FAT32 partition -- that's your choice, even if it is a stupid choice and the worst possible way to achieve your goal. But please don't tell lies about "having" to keep it. There are alternatives, you've been told about them, and you have rejected them for entirely arbitrary reasons. You don't "have" to keep a FAT32 partition -- you have chosen to keep a FAT32 partition.

Re: SQL skills

2008-01-08 17:28 • by ChZEROHag
169881 in reply to 169744
bob:
<snip/>

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.
<snip/>

My maths is a touch rusty, but isn't the difference between 6000 and 200 just 1 order of magnitude?


Magnitude is probably the wrong word. My collection is 30 times the size of hers.

Re: SQL skills

2008-01-08 17:33 • by AdT (unregistered)
169882 in reply to 169544
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. A typical desktop application does not need all those fancy features a database provides, making them little more than bloat and inconvenience.


No, I don't. Where did you get the idea that all DBMSes are bloated and poorly designed? Embedded Firebird is a 3MB download (Windows version), SQLite is 1/10th the size and its feature set is probably still sufficient for your purposes.

And I didn't even mention MySQL, nor would I recommend it. PostgreSQL and Firebird have similar feature sets but are far less quirky than MySQL and have more generous licenses.

Chemisor:

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.


Apple just released the new Mac Pro. The standard configuration comes with eight processor cores. And you are still writing single-threaded apps? Ok, this is an extreme example, but even most portables have at least two processor cores these days. The times where people have tolerated GUIs that totally lock up whiile an operation is in progress are coming to an end. Which means you have to deal with concurrency even when there is only one user. DBMSes don't solve all of your concurrrency problems, but they can help a lot.

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.


All the painstaking work has already been done for you. If simple queries are fast enough, you don't need to optimize them. But it is a lot easier to optimize them later on if you are already using an RDBMS.

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.


Bogus for the reason I already mentioned: Embeddable DBMSes are available for easy local use.

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!


Please don't repost points that have already been refuted. If you know how to use copy & paste, you know how to back up a .fdb (Firebird Database) file. Of course the database should not be open when you do this, but closing it is simple to do in application code. Oh, and lest you might misunderstand: You can also use any other file extension.

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.


This is absolutely ridiculous. You could just as well argue that people need an MCSE in order to use Windows. If your application uses a database, you can hide the databasey details just as well as you would hide the bit fiddling details of your own C++ implementation.

Chemisor:

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


Sorry, but WTF does that have to do with relational databases?

Chemisor:

True, but they don't provide any benefits over the simple dump-my-data-and-index solution.


Yes, there is at least one crucial benefit: If you use them, you don't have to waste time on problems that have been solved before (dozens of times).

Chemisor:

They are actually worse, since they have C interfaces, which will defile your pure C++ design.


Actually, a little googling provided me with links to numerous C++ APIs for the above-mentioned DBMSes.

Chemisor:

There is NO excuse for using plain C interfaces these days. Good design requires structure, and C can't provide any.


If the C interface was the only interface, that would be convincing. Only it isn't. If you don't like the C interface, use another.

Chemisor:

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.


Actually, it's a bogus reason by definition. And Firebird is not an "obscure package" but one of the best known and popular open-sourec RDBMSes.

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.


Sorry, I meant to say "file format". Anyway, why would I write code to create in-memory data structures and then code to serialize them if I can just pump the data into a database in the first place? That seems to be doubly redundant to me. If you already have the data structures for some other reasons then this might make more sense. And writing even complex SQL queries is ridiculously simple compared to writing C++ code that extracts the same information from a custom file format.

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.


If an RDBMS provides you with features you don't need, how about... not... using.. them...? In any case, this is no reason for not using the features that you do have a use for. Unless you are indeed suffering from NIH syndrome as I suspect.

Re: The Case of the Clueless Candidate

2008-01-08 18:53 • by TopicSlayer (unregistered)
What I love most about the "don't reinvent the wheel" crowd is their ability to espouse the wide wheel variety from which you should chose rather than reinvent your own and all the while fail to realize that said variety would not exist if everyone advocated this principle.

Re: The Case of the Clueless Candidate

2008-01-09 00:42 • by vt_mruhlin
169912 in reply to 169890
TopicSlayer:
What I love most about the "don't reinvent the wheel" crowd is their ability to espouse the wide wheel variety from which you should chose rather than reinvent your own and all the while fail to realize that said variety would not exist if everyone advocated this principle.


But there's different kinds of wheels for different uses!

My workplace is more of the "pretend you invented the wheel in the first place" type. My boss wants me to talk about how one of the apps handles database connection pooling tomorrow. Like I need to give some freaking presentation to say "if it needs to make a database connection, it gets one out of the pool. If the pool's empty it waits."

Re: The Case of the Clueless Candidate

2008-01-09 04:50 • by Andrew (unregistered)
169926 in reply to 169432
brazzy:
...
Can you say "beaurocractic monstrosity"?



Can you spell "bureaucratic"?

Re: The Case of the Clueless Candidate

2008-01-09 08:53 • by AdT (unregistered)
169946 in reply to 169890
TopicSlayer:
What I love most about the "don't reinvent the wheel" crowd is their ability to espouse the wide wheel variety from which you should chose rather than reinvent your own and all the while fail to realize that said variety would not exist if everyone advocated this principle.


Do you know what a straw man argument is? I did not say it's always bad to "reinvent the wheel". Chemisor did not even try to reinvent the wheel, he invented a cube on an axis and said it would roll well enough for his purposes. But when you choose not to use on of the existing wheels I feel you should have a good reason while the reasons Chemisor brought forward consisted of:

a) unsubstantiated prejudice
b) invalid generalizations
and, in my eyes also
c) reasons made up post hoc to support his preconceived world view

Actually, I don't care whether Chemisor wants to use databases or not. But since he publicly argued that databases cannot be used for certain purposes, stating reasons that make no sense, he was asking for contradiction. :-)

For example, in one of his first posts in this thread, he wrote: "It did not use a database because it was intended as a consumer product" which makes no sense whatsoever - there are lots of consumer products that make successful use of databases, etc.

It is necessary to contradict such claims lest some lurkers might think they actually have any substance.

Re: The Case of the Clueless Candidate

2008-01-09 11:06 • by Richard (unregistered)
I'd ask for more information, like what existing systems there were to integrate with. After all, I assume you've got some kind of employee database somewhere.... have you?

Re: The Case of the Clueless Candidate

2008-01-09 11:10 • by MemeDude (unregistered)
169996 in reply to 169469
Me:
TRWTF is that someone would go and fetch a fan when a hot woman in front of you says "Oh, it's hot in here!". She was obviously trying to take the interview in another direction.

My thoughts exactly!

Re: The Case of the Clueless Candidate

2008-01-09 13:27 • by Bob (unregistered)
170065 in reply to 169468
FredSaw:
Don't forget, SQL skills are unimportant and lots of skilled developers don't have them. Also, testing doesn't prove anything. The important thing is, does she have a degree? If so, then they screwed up in letting her go.



Mary? Is that you?

Re: SQL skills

2008-01-09 14:10 • by Chemisor
170082 in reply to 169882
All right, so we are having a flamewar now! :)

I really did not intend things to do down the toilet like this, but let's try to be amicable. I'll try again to explain how databases look from my point of view.

First of all, I was not referring to embedded databases. I think I knew about them before I read your posts, but I certainly did not think of them when I wrote mine. In my mind, "using a database" and "using a database format" are two entirely different things. When you say your app uses a database, I see something that communicates to a central server, which handles numerous simultaneous connections. Call it a terminology problem, but that's how I, a total database ignoramus (as I have admitted several times) interpret what you say. When you use an embedded database, to me that's just like using a custom data format with a packaged library, which is pretty much what I do anyway except that I write the library.

You counter that an embedded database is already fully written and debugged, but this is not particularly relevant to me since writing serialization code for a class is a trivial exercise completed in a few minutes. And then there's the size of it. You say embedded Firebird is "only" 3M in size and I gasp, because most of my applications weigh in at less than a 300k (without system libs of course). Would you have me increase my app footprint by a factor of 10 just to have database features that I am probably not going to use? My serialization code is insignificantly tiny by comparison.

You say that concurrency and data integrity are important, but you are still thinking of some database frontend, are you? Something that runs a query and displays a result in a form. So lets talk about that.

How do you get your data to the UI? When I design data structures, I think of how they look in memory, not how they look on the disk, which I consider to be a separate problem. When I write a UI screen I'll be accessing objects in memory, not rows in a query, and I would need some way to convert one into the other. From what I can see in Firefox's API, you either copy the data field by field, or you use macros which probably do the same thing, but autogenerate the code for you. Note how this process is identical to writing a serialization routine, and the generative macros are your only work savings. I could, I suppose, write such macros to automatically make serialization routines, but I just don't see the point, considering that now I more or less just cut-n-paste the copy constructor to make them.

This brings me to the subject of "goddamn text". I'll repeat once again that I haven't written any database-using code, so all I know about SQL I've read in books. Those books, such as "SQL Unleashed", show examples exclusively in text form. In pretty much every example you use a shell-like interface to write your queries and get back text results. Now, I don't know how the database really handles these things, and maybe there is no text involved in the middle. And yet, when you get fields from a query, you look them up by name, so there's got to be some in there. In my mind, this generates instant revulsion, because text means parsers. Using text and parsers is inherently inefficient in both speed and code size, so until I can verify that the query results come back in some machine-readable form, I'd be very uncomfortable using them. Feel free to enlighten me, if you know how this works.

Let's talk about concurrency. When I said you did not need it, I was thinking of a central server database with multiple connections. Naturally, in a single user application with an embedded database, any concurrent connections will come from the same user. The thing is, in anything I design, there will be a single data path. Yes, I might, very rarely, make multiple views of the same data, in which case the views will access the data in memory in a document object, not the database directly. Data manipulation is separate from serialization in my mind.

Part of this is because most of this manipulation does not affect the database. A business inventory is always changing, orders are always coming in, and the database is churning all the time. A home user will not be changing his data sets frequently. Your 6000 CD music index will not change. You probably add new records now and then and delete old ones, but you never modify them. Most tasks you perform are read-only; searching and statistical analysis are what most people do with data. New data does not come in very often.

In view of this, concurrency is almost a non-issue. You hardly ever write anything, much less write anything multiple times. Same with data integrity. Data is added so rarely that the odds of you losing power during the exact microsecond that you are writing your data to the disk are astronomically small. I get maybe three or four power failures per year, all of them during extreme weather conditions. A partial write that corrupts your whole file is even less likely. I'm tempted to say that you should just restore from backup if that happens; after all, I would bet good money that it won't happen in your lifetime.

Most applications would just write a new file on save and move it over the old copy, solving this problem. You said that this would cause an unacceptable slowdown, but you forget that the data set is small. My disk can write ~50M/sec, and with your 6M CD index you would not even notice.

> The standard configuration comes with eight
> processor cores. And you are still writing
> single-threaded apps? The times where people have
> tolerated GUIs that totally lock up whiile an
> operation is in progress are coming to an end.

Just because an application is single threaded, doesn't mean it locks up while an operation is in progress. That's what asynchronous IO is for, which I use extensively. IMO, it is far easier and simpler to get working than ensuring thread safety. It all also integrates beautifully into the event-driven architecture which every modern UI framework uses. No, I wouldn't get to use multiple cores, but since I don't have any tasks that are CPU bound, why would I care?

> Yes, there is at least one crucial benefit: If you
> use them, you don't have to waste time on problems
> that have been solved before (dozens of times).

If I use them I'd have to waste time on figuring out how to use a foreign API. An API that won't integrate well with my existing code and will require constant hacks to my data model to "fit it in". Code reuse is not always appropriate. Sometimes reinventing the wheel really is the easier way to go. You may disagree, but you already know your databases and think in ways that complement their APIs. I don't.

> Actually, a little googling provided me with links
> to numerous C++ APIs for the above-mentioned DBMSes.

Which are all nothing but wrappers for the C API. This is usually worse than using the C API in the first place, since most people don't know how to design a proper OO API anyway. Then there's a very real chance of introducing extra bugs in the wrapper itself. But no, I'm not really bashing them, so don't take this negatively; it's just a personal bias.

> Anyway, why would I write code to create in-memory
> data structures and then code to serialize them if
> I can just pump the data into a database in the
> first place? That seems to be doubly redundant to me.

I would reverse this argument and say that the in-memory data structures come first, and so the whole discussion of how to store them in a file is a separate issue. As you can see, I am not thinking in a database-oriented fashion. It might be because I am not thinking of applications that view and modify the data, but rather of applications that analyze it. By analysis I don't mean viewing the data in different ways; I mean actually making sense of it, displaying statistics on it, deriving some useful knowledge from it, or just plain making pretty graphs with it. None of those things can be done with an SQL query; you really do need to load stuff into memory and work on it.

Re: The Case of the Clueless Candidate

2008-01-09 14:16 • by Dr. Furter (unregistered)
Interviews put people in strange places mentally. Unfortunately everybody has to interview so for those that it completely freaks out, it is not a pretty scene. I feel bad for then I really do, but I still can’t hire them. “Mary” was probably one of those people and coupled with what was likely only meager design skills, you get this.

WTF indeed.

Re: The Case of the Clueless Candidate

2008-01-09 16:29 • by Kelly (unregistered)
I showed my friend this, expressing annoyance at how all the stupid-people stories on Daily WTF seem to be about females. As a 20-something female myself, I was saddened by this. His response:

friend: well, i certainly wouldn't expect there to be fewer misogynists in the male-with-no-social-skills echo chamber that is technical blogs

sigh

Re: The Case of the Clueless Candidate

2008-01-09 16:34 • by Kelly (unregistered)
170132 in reply to 170065
Bob:
FredSaw:
Don't forget, SQL skills are unimportant and lots of skilled developers don't have them. Also, testing doesn't prove anything. The important thing is, does she have a degree? If so, then they screwed up in letting her go.



Mary? Is that you?


Actually, I had absolutely no SQL skills when I entered my first development job right out of college. I majored in applied math and only minored in computer science, so I never took a database course. Within a few weeks I understood relational database design pretty well. A year and a half later, I consider myself as much of a SQL and relational database design pro as any non-DBA developer (who happens to be using SQL) would generally be expected to be.

Re: The Case of the Clueless Candidate

2008-01-09 17:55 • by Harrow (unregistered)
170143 in reply to 169545
snoofle:
...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"?

This happens to me about three or four times a year, although I admit that usually I get fifteen or twenty minutes.

I generally use the Borland Database Engine for such shortsighted requests because I like to give my clients what they deserve...

-Harrow.

Re: The Case of the Clueless Candidate

2008-01-09 21:17 • by dml
170173 in reply to 170130
Kelly:
all the stupid-people stories on Daily WTF seem to be about females
I kind of see what you mean (probably articles that specifically mention a female stand out more) but aren't essentially all the articles on this website about "stupid people" or at the very least the code they produce? Many of them are about males, whether it says so or not. Stupid people are exactly what the site is founded on.

In fact, looking at the backlog of interview articles, I can find at least one about a dolt who was referred to with masculine pronouns. And one that was about a chauvinist male getting his comeuppance.

I'm sympathetic to your concern, but I really don't think there's any gender bias here.

Re: The Case of the Clueless Candidate

2008-01-11 15:34 • by Vootie (unregistered)
170614 in reply to 169476
Heh. Yeah, there's a lot of people out there who think that just because some people are clueless about computers that means that everyone has to be, so they can fake it until they learn it on-the-job.

Within some limits you can certainly pick stuff up, if you're bright and have decent work experience, but not the whole job experience from scratch. Not in computers.

Re: The Case of the Clueless Candidate

2008-01-11 15:41 • by Vootie (unregistered)
170615 in reply to 170130
> I showed my friend this, expressing annoyance at how all the stupid-people stories on Daily WTF seem to be about females. As a 20-something female myself, I was saddened by this.

You know, there are a lot more female chauvinist pigs out there these days than male chauvinist pigs.

Rhetorical Question one:
========================
I suppose you've considered the possibility that God might be a female.

How often have you considered the equal possibility that the **Devil** is one?

Rhetorical Question two:
========================
I'm sure you're familiar with the term "misogynist" -- a man who hates women.

What's the term for "a woman who hates men"?

=========

Maybe you're the rare exception but not many women ever grasp the idea that there are just as many bad & stupid women just as there are bad and stupid men.
:-/ (is there an emoticon for rolling eyes?)

Re: The Case of the Clueless Candidate

2008-01-13 14:06 • by Smash (unregistered)
170923 in reply to 170615
Vootie:

:-/ (is there an emoticon for rolling eyes?)


I don't know elsewhere, but we brazilians became quite fond of the japanese emoticon for rolling eyes => ¬¬

also available with a sweat drop => ¬¬'
or in a angry, throbbing vein mood => ¬¬*

Re: The Case of the Clueless Candidate

2008-01-14 12:16 • by Grovesy
171031 in reply to 169797
ChiefCrazyTalk:
Grovesy:
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)


Huh? You went from Vendor, to intern, to FTE, to back to being an intern? Not the usual career progression...


For some reason in the UK, (V-) was vendor, (I-) was independant contractor

never made sense to me.

Re: The Case of the Clueless Candidate

2008-01-14 12:58 • by Random832
171044 in reply to 170130
Kelly:
I showed my friend this, expressing annoyance at how all the stupid-people stories on Daily WTF seem to be about females.


As a long-time reader, I can assure you that at least 95% of the "stupid-people stories" are about males. In fact, when I really think about, I can only recall two (Not two percent - two stories. There was Paula, and then one other that had a similar explosion of "ZOMG sexism" accusations) where the subject was specifically female.

Re: The Case of the Clueless Candidate

2008-01-18 06:50 • by JoeBloggs (unregistered)
I've had it from the other side. A few years ago I was being interviewed for a job as a Windows app developer. After talking to the guy for about 20 minutes about various Windows apps I'd written he then said he had some specific requirements and then asked "Do you have any 'G' 'U' 'I' development experience?" (he spelled GUI out very carefully"). I finally realized that I was just talking to a HR monkey and I'd probably have to talk to someone else later. What got to me, though, was that this guy would probably determine if I got to the 'real' interview. After another ten minutes of me explaining the difference between 'embedded development' and 'embedded SQL'(he was just picking things at random from my CV) I just mentally scratched the company from my list. When they called back I just made an excuse as to why I couldn't come back to see them.

Re: The Case of the Clueless Candidate

2008-02-04 08:50 • by Jesse McNelis (unregistered)
I've given a response sort of like that in a job interview.
Obviously I didn't get the job.
I could easily answer the question at any other time, just on under pressure in a job interview.

Coding is done at a computer, you are generally fairly alone and their isn't someone staring at you waiting for an answer straight away.
To test someone's coding ability by asking a question in an interview is silly.

Re: The Case of the Clueless Candidate

2008-02-23 00:17 • by snow (unregistered)
178718 in reply to 169454
i agree. the question was misleading unless you're working in the industry primarily as a database administrator or programmer. IMO there's a gap between the industry and academics. Many veterans who may not have gotten a general education in Computer Science are a little narrow. when i think of a database it's more like a well-managed file structure (outside of the code domain) and data structures are records, trees, hash tables, classes, objects, lists etc. why the superior attitude, anyway? what was her level of experience? SQL knowledge and work from an entry-level perspective is interpreted by veterans as equal knowledge. There's ambiguity within the whole field of Computer Science or all software will run perfectly without any errors. In other words, I don't think that was a good question to make a hiring decision on an entry-level basis. B/c data structures and databases aren't considered in the same category.

Re: The Case of the Clueless Candidate

2008-02-23 00:34 • by snow (unregistered)
178719 in reply to 178718
why use the term stupid? it seems like a degree doesn't mean anything. why have it as a choice in college? a college degree is general knowledge and projects related to the basic foundations, which is supposed to get us ready for the industry. It's called talent not how much do we know compared to veterans. New comers with a general education may get confused by the jargon b/c the jargon of Computer Science is so vague and can be misleading at times. Plus, many students come from so many different backgrounds. Ever heard of the expression "a diamond in the ruff". Talent does not equal knowledge. the concept of object models are easily learned not the effective use of them. A person with a beautiful voice and great vocal control may not even know what a 'b' not looks like, but they can easily learn it. Does it mean someone who can recognize a 'b' note will break down the house over someone who doesn't.

Re: The Case of the Clueless Candidate

2008-02-23 00:48 • by snow (unregistered)
are all veteran developers this rude? is it learned on the job?

Re: The Case of the Clueless Candidate

2010-06-17 17:26 • by MaryBean (unregistered)
312170 in reply to 169439
That is exactly what I meant! LOL

Re: The Case of the Clueless Candidate

2011-03-02 09:16 • by cindy (unregistered)

Re: The Case of the Clueless Candidate

2011-07-20 04:32 • by tero (unregistered)
Excellent interview question BTW!

Re: The Case of the Clueless Candidate

2012-10-26 11:00 • by Daniel (unregistered)
393453 in reply to 169439
Seems you're gonna get stuck in that loop ;)

Re: SQL skills

2014-08-29 08:14 • by boner boy (unregistered)
438256 in reply to 169881
ChZEROHag:
bob:


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.


My maths is a touch rusty, but isn't the difference between 6000 and 200 just 1 order of magnitude?


Magnitude is probably the wrong word. My erection is 30 times the size of hers.


FTFY
« PrevPage 1 | Page 2 | Page 3 | Page 4Next »

Add Comment