Nice. I had been leaving open the question of whether you were knowingly trying to take advantage of people. With your choice to get nasty and ad hominem about this, now I guess we know.
What if the person you're interviewing doesn't happen to have too many brilliant insights for the particular problem you're having at work at the time? Don't hire him? Hire the guy who just happened to have recently worked on something very similar to this week's problem? What about next week's problem? A test can be devised that checks for some of the kinds of things that are common to many of the problems your work faces/has faced.
And unless you cut potential candidates a check for their interviewing time, imposing double-duty on it is inappropriate. Interviewing is for each party to size up the other in deciding whether to form a mutually-agreeable relationship. Why would you think of this as potentially a waste of your time, unless you don't really need to hire? (Ruling out poor candidates is a valuable service you're providing to your company.) The interview is not the time to also try to get free professional services out of people. Interviews are not for eliciting contributions to the company, nor are they there so that you can personally learn something technical you didn't know before.
And employment interviews are not for "keeping it real and interesting". That would involve a battery of off-topic questions like "so how about those Yankees?" and personal questions like "so how's your wife doing?". Employment interviews are for a specific, defined purpose. Legally, and in matters of common courtesy.
Overall, it's good that you've figured out that senior candidates don't want to be treated like children, or newbies, but you're also better off treating them with respect in other ways as well, such as respecting their value, and the respect you give in assuming that they're aware of it. And that they respect themselves.
My dad used to play Global War (a Risk clone), and he commented that to really have fun, you need to win something like 80% of the time.
It's different for different people. I played a Risk clone called Strategic Conquest in college, and after getting beyond the newbie stage I cranked it to the upper levels and then started backing it down until I was winning about half the time. That's just the threshold that I preferred. If I knew I won about 80% of the time, then in any given game I would go in thinking that, chances are, I know who'll win. That's no fun. And since I'd be assuming I'd win, if a given game was one of the two in ten, I'd be really disappointed. But at 50/50, I go in with no expectations, and I don't feel bad when I lose.
For example, if you get beat the first time you play on hard, the computer goes easy on you the second time you play --...
One small problem with all this dynamism people are entertaining is that it makes comparisons between individuals mostly meaningless. I can tell my friend that I beat game X at level No Mercy, but if it plays different with different people, or even with the same person on different days, it deflates somewhat your bragging rights. Not a huge deal, tho.
There's no sense of accomplishment if the game punishes you for doing well.
I think the idea is that the game would play at *just below* your measured level (versus punishing you by adjusting up to maintaining always being better than you). Then you could feel good about it letting you win!;-)
A background in Computer Science makes a CS major inherently better. Or at least to start out with. You're absolutely right about curiousity and discipline, and of course a liberal arts major or any other can eventually surpass a CS major in code quality. But I've seen people here on the dot say that they actually prefer to hire non-CS majors, because they believe that non-CS majors are inherently better at programming somehow than CS majors. I'm not knocking non-CS majors, I'm knocking what looks like a trend starting of knocking CS majors, in their own field!
Sure there are a lot of dummies in this field, but think about it, programming is not something just anyone can do, and few do it well. There's simply going to be a greater %-age of CS grads who are cut out for programming work than the %-age of non-CS grads who are. To be fair, I will concede that if you get a non-CS grad who's actually applying for a programming job, odds are prolly better than 50/50 that it's one of the ones cut out for programming, whereas to find such people amongst CS majors you have to do some testing.
Yes. That is, I think it's become blurred, and that's what I'm objecting to. I have no doubt a given person (of questionable ability to evaluate) considers some basket-weaving major the greatest programmer who ever lived. But when this gets repeated often enough it starts to be viewed as a pattern, and then it becomes a general principle, in the domain of fun-to-amaze-people-with folklore.
That's what people who don't know any particular languages in depth tend to think. You have contempt for testing because testing indicates an opposing philosophy, that depth matters. And that many places would rather have a specialist in one to three things than a generalist. For something like classic VB I wouldn't avoid hiring a generalist, but for something like C++, that has lots of gotchas and that the other specialists on the team are going to want to operate at an advanced level at, I would avoid a generalist like the plague.
And what if they're like me -- I don't work for free. I will freely offer several hours of my time and answer questions truthfully, in trade for serious consideration for a job. But I'm not going to work on some place's problem without yet even working there. How do I know the place is just not fishing for solutions and is not planning on or as a result will decide not to hire someone.
One of the best developers I know has a degree in history, and within 6 months of beginning development was producing better quality work than some guys who have been developing for years.
Doesn't anyone but me get tired of hearing this variety of fantastical story, repeated over and over? Ya know, "<insert non-CS major title of choice, preferrably something really lightweight to make the story even more "amazing"> graduate who's never programmed surpasses in mere minutes a whole roomful of CS grads each with 30 years experience!!!" "Art majors make the best programmers." "Musicians are better programmers than non-musicians." I guess forget the CS degree, kids, what you want is a liberal arts degree. And don't even touch a computer in college, because you'll surpass senior engineers quicker if you have absolutely no experience! Amazing but true!!!
Sequence points also come into play when the same variable is modified more than once. An often-cited example is the expression i=i++, which both assigns i to itself and increments i; what is the final value of i? Language definitions might specify one of the possible behaviors or simply say the behavior is undefined. In C and C++, evaluating such an expression yields undefined behavior.
But I don't know why it's not simply based on operator precedence, as: 1) i is assigned 0 (first statement) 2) i's current value of 0 is temporarily saved off 3) postfix increment is applied to i, setting it to 1 4) finally, the saved value is assigned to i, setting it back to 0
Jeffrey Dahlmer wouldn't understand our aversion to killing and eating people.
Re:easy way to fill a book
on
Head First C#
·
· Score: 1
There's an "Accelerated C# 2008" book.
Speaking of book padding, the Deitel boys crank out edition after edition and monstrous-sized (and priced) tomes of "<language> How To Program". I already know "how to program". What a great racket they have, repeating all those hundreds of pages of programming and OO basics in each book and edition, and probably mostly the same examples, just ports between the three similar languages (C++, Java, and C#). They are the masters at filling books.
Re:easy way to fill a book
on
Head First C#
·
· Score: 1
Learning C++ with just cout and cin is the best way to start -- it allows one to focus purely on understanding the language and its standard library. And if you continue with C++, you'll create numerous quickie CLI programs to try out language features (or your understanding of them!) in isolation that you're contemplating using in a project.
For GUI's in C++, you should probably look at Qt. This book, for example looks up-to-date and it and its previous edition is pretty well-reviewed on Amazon. I don't favor Qt (uses a bunch of macros for things to get around poor advanced language support in early compilers), but it's Windows and UNIX, and MS' GUI focus these days is on C#/.NET, so I can't in good conscience recommend the ancient API's that I know and learned long ago (Win32 and MFC).
easy way to fill a book
on
Head First C#
·
· Score: 4, Insightful
Yet, for any programmer new to object orientation...
How many can there be left these days?!? It's too easy to accumulate enough material for a good-sized book by starting from scratch and assuming the reader only knows how to read. Anyone could write a beginner's book on a computer language, without knowing the language too in depth, by just padding it with lots of remedial review material, that 99% of the readers don't need and don't want (to wade thru or pay for).
You're conflating two distinct things, finding life wanting, and worrying about your legacy. I've heard the "is this all there is to life" meme as being associated with a mid-life crisis. But the Bill Clinton thing is going to be exclusive to only the pathologically self-important. So I don't think that's a factor for everyone, and I don't think it being all about or mostly about one's job is a common factor either.
And I hope it's not the common experience to watch one's dreams slowly die. I've been steadily ticking mine off over the years. Start immediately. Work hard. Discard unrealistic dreams, or work unrealistically hard. For example, if you want your name in the history books, you've got to work a lot harder than I do. The job's not the problem, it's just a means to an end, to fulfilling that subset of your life-long dreams that require money. The problem's when you have nothing to look forward to when you come home from your job. That's how my dad's mid-life crisis manifested. He had the bland, safe life. But he didn't rebel. He stuck it out and retired early. And I wanna be just like him.
...the "midlife crisis", where you quit your lousy boring job, get a backpack, and go live on the Appalachian trail.
That might be what the hippie contigent does, but for most, they need to keep their relatively high-paying job to be able to afford the sports car and mistress and then the alimony. I thought a mid-life crisis was a rebellion against being tied down, i.e. wife and kids and familial responsibilities, and having to sacrifice for them, not boredom at work.
This is similar to what I was thinking -- the time at which an organization should be catching such errors is neither in the code review nor in running an analysis tool, it's during the interview.
If the information is what it sounds like, it's information about the customer's activity. There'd be a very difficult argument that you own that data instead of the customer owning it.
Who's collecting it? The customer could certainly track their own activity if a company's terms were not satisfactory.
Think of it this way: if you believe you should have control of and access to your medical files, credit reports, and bank records; then this customer should have the same with their data.
It's not about saying what a customer can do with their data, it's about saying what a customer can do with your particular copy of their data. I can get my credit report, and look at it 1000 times in a day if I want, but I can't get my credit report 1000 times a day.
If it's one thing people love it's a good romantic myth. "Good programmers are typically also artists or musicians." "Wow, that's really neat. It makes me feel good to believe that. And it's an interesting idea to keep as something to tell and amaze and delight others with." And so it gets passed around and around.
I would say there's not enough time in the day to be a virtuoso at both programming and something else. There's always more books to read and techniques to learn in software development. And competency is not just in knowledge of course, but is increased also by experience. And that means time. The best programmers don't serve two masters. The best programmers don't view programming as their day job, that allows them to go home and play the flute or sculpt or whatever. Programming is our life, it's what we are best at, what seemingly we were born to do.
It sounds like you may be basing "competency" on mostly having a good attitude. Your actual correlation may instead be "most of the programmers I enjoy working with are artists or skilled artisans of some sort." That is, you may not be very hard-core yourself, and therefore prefer those who are more "well-rounded".
Exactly. In fact, the asker is presenting a good lesson I think to be learned by all: Don't let what you do for fun turn into work. Don't allow yourself to actually stress over a project if you're not getting paid for it. If your side software project has become "a fairly serious problem" for you, you've gotten way off track with the spirit of creating software as a labor of love.
For a minute there I didn't see the person behind the desk in this picture, and thought Google greeted visitors in their lobby with just a PC, with a browser opened to their home page, maybe as a portal to a special internal "Google campus" search database that could tell you things like where Joe Blow sits or when the gift shop closes. Receptionists soon to be obsolete.
To be able to create a function that could only be called from a certian other function.
Pascal had nested functions, which IIRC made them private to all accept their outer function. It would be nice if its successors (in popularity, not lineage) had that. If classes can be nested in C++ and Java, why not functions? It has utility even without closure support.
Because sometimes a variable gets into a point where you don't want to be using it after a certain part of the function.
Just create another scope inside the function. In C++ just add an inner set of braces and declare your variable in there. In Java, well, that won't work for objects.
Slashdot Mirror
Nice. I had been leaving open the question of whether you were knowingly trying to take advantage of people. With your choice to get nasty and ad hominem about this, now I guess we know.
What if the person you're interviewing doesn't happen to have too many brilliant insights for the particular problem you're having at work at the time? Don't hire him? Hire the guy who just happened to have recently worked on something very similar to this week's problem? What about next week's problem? A test can be devised that checks for some of the kinds of things that are common to many of the problems your work faces/has faced.
And unless you cut potential candidates a check for their interviewing time, imposing double-duty on it is inappropriate. Interviewing is for each party to size up the other in deciding whether to form a mutually-agreeable relationship. Why would you think of this as potentially a waste of your time, unless you don't really need to hire? (Ruling out poor candidates is a valuable service you're providing to your company.) The interview is not the time to also try to get free professional services out of people. Interviews are not for eliciting contributions to the company, nor are they there so that you can personally learn something technical you didn't know before.
And employment interviews are not for "keeping it real and interesting". That would involve a battery of off-topic questions like "so how about those Yankees?" and personal questions like "so how's your wife doing?". Employment interviews are for a specific, defined purpose. Legally, and in matters of common courtesy.
Overall, it's good that you've figured out that senior candidates don't want to be treated like children, or newbies, but you're also better off treating them with respect in other ways as well, such as respecting their value, and the respect you give in assuming that they're aware of it. And that they respect themselves.
My dad used to play Global War (a Risk clone), and he commented that to really have fun, you need to win something like 80% of the time.
It's different for different people. I played a Risk clone called Strategic Conquest in college, and after getting beyond the newbie stage I cranked it to the upper levels and then started backing it down until I was winning about half the time. That's just the threshold that I preferred. If I knew I won about 80% of the time, then in any given game I would go in thinking that, chances are, I know who'll win. That's no fun. And since I'd be assuming I'd win, if a given game was one of the two in ten, I'd be really disappointed. But at 50/50, I go in with no expectations, and I don't feel bad when I lose.
For example, if you get beat the first time you play on hard, the computer goes easy on you the second time you play --...
One small problem with all this dynamism people are entertaining is that it makes comparisons between individuals mostly meaningless. I can tell my friend that I beat game X at level No Mercy, but if it plays different with different people, or even with the same person on different days, it deflates somewhat your bragging rights. Not a huge deal, tho.
There's no sense of accomplishment if the game punishes you for doing well.
I think the idea is that the game would play at *just below* your measured level (versus punishing you by adjusting up to maintaining always being better than you). Then you could feel good about it letting you win! ;-)
A background in Computer Science makes a CS major inherently better. Or at least to start out with. You're absolutely right about curiousity and discipline, and of course a liberal arts major or any other can eventually surpass a CS major in code quality. But I've seen people here on the dot say that they actually prefer to hire non-CS majors, because they believe that non-CS majors are inherently better at programming somehow than CS majors. I'm not knocking non-CS majors, I'm knocking what looks like a trend starting of knocking CS majors, in their own field!
Sure there are a lot of dummies in this field, but think about it, programming is not something just anyone can do, and few do it well. There's simply going to be a greater %-age of CS grads who are cut out for programming work than the %-age of non-CS grads who are. To be fair, I will concede that if you get a non-CS grad who's actually applying for a programming job, odds are prolly better than 50/50 that it's one of the ones cut out for programming, whereas to find such people amongst CS majors you have to do some testing.
Yes. That is, I think it's become blurred, and that's what I'm objecting to. I have no doubt a given person (of questionable ability to evaluate) considers some basket-weaving major the greatest programmer who ever lived. But when this gets repeated often enough it starts to be viewed as a pattern, and then it becomes a general principle, in the domain of fun-to-amaze-people-with folklore.
That's what people who don't know any particular languages in depth tend to think. You have contempt for testing because testing indicates an opposing philosophy, that depth matters. And that many places would rather have a specialist in one to three things than a generalist. For something like classic VB I wouldn't avoid hiring a generalist, but for something like C++, that has lots of gotchas and that the other specialists on the team are going to want to operate at an advanced level at, I would avoid a generalist like the plague.
And what if they're like me -- I don't work for free. I will freely offer several hours of my time and answer questions truthfully, in trade for serious consideration for a job. But I'm not going to work on some place's problem without yet even working there. How do I know the place is just not fishing for solutions and is not planning on or as a result will decide not to hire someone.
One of the best developers I know has a degree in history, and within 6 months of beginning development was producing better quality work than some guys who have been developing for years.
Doesn't anyone but me get tired of hearing this variety of fantastical story, repeated over and over? Ya know, "<insert non-CS major title of choice, preferrably something really lightweight to make the story even more "amazing"> graduate who's never programmed surpasses in mere minutes a whole roomful of CS grads each with 30 years experience!!!" "Art majors make the best programmers." "Musicians are better programmers than non-musicians." I guess forget the CS degree, kids, what you want is a liberal arts degree. And don't even touch a computer in college, because you'll surpass senior engineers quicker if you have absolutely no experience! Amazing but true!!!
I see that:
But I don't know why it's not simply based on operator precedence, as:
1) i is assigned 0 (first statement)
2) i's current value of 0 is temporarily saved off
3) postfix increment is applied to i, setting it to 1
4) finally, the saved value is assigned to i, setting it back to 0
Jeffrey Dahlmer wouldn't understand our aversion to killing and eating people.
There's an "Accelerated C# 2008" book.
Speaking of book padding, the Deitel boys crank out edition after edition and monstrous-sized (and priced) tomes of "<language> How To Program". I already know "how to program". What a great racket they have, repeating all those hundreds of pages of programming and OO basics in each book and edition, and probably mostly the same examples, just ports between the three similar languages (C++, Java, and C#). They are the masters at filling books.
Learning C++ with just cout and cin is the best way to start -- it allows one to focus purely on understanding the language and its standard library. And if you continue with C++, you'll create numerous quickie CLI programs to try out language features (or your understanding of them!) in isolation that you're contemplating using in a project.
For GUI's in C++, you should probably look at Qt. This book, for example looks up-to-date and it and its previous edition is pretty well-reviewed on Amazon. I don't favor Qt (uses a bunch of macros for things to get around poor advanced language support in early compilers), but it's Windows and UNIX, and MS' GUI focus these days is on C#/.NET, so I can't in good conscience recommend the ancient API's that I know and learned long ago (Win32 and MFC).
Yet, for any programmer new to object orientation...
How many can there be left these days?!? It's too easy to accumulate enough material for a good-sized book by starting from scratch and assuming the reader only knows how to read. Anyone could write a beginner's book on a computer language, without knowing the language too in depth, by just padding it with lots of remedial review material, that 99% of the readers don't need and don't want (to wade thru or pay for).
Best analogy evar.
You're conflating two distinct things, finding life wanting, and worrying about your legacy. I've heard the "is this all there is to life" meme as being associated with a mid-life crisis. But the Bill Clinton thing is going to be exclusive to only the pathologically self-important. So I don't think that's a factor for everyone, and I don't think it being all about or mostly about one's job is a common factor either.
And I hope it's not the common experience to watch one's dreams slowly die. I've been steadily ticking mine off over the years. Start immediately. Work hard. Discard unrealistic dreams, or work unrealistically hard. For example, if you want your name in the history books, you've got to work a lot harder than I do. The job's not the problem, it's just a means to an end, to fulfilling that subset of your life-long dreams that require money. The problem's when you have nothing to look forward to when you come home from your job. That's how my dad's mid-life crisis manifested. He had the bland, safe life. But he didn't rebel. He stuck it out and retired early. And I wanna be just like him.
...the "midlife crisis", where you quit your lousy boring job, get a backpack, and go live on the Appalachian trail.
That might be what the hippie contigent does, but for most, they need to keep their relatively high-paying job to be able to afford the sports car and mistress and then the alimony. I thought a mid-life crisis was a rebellion against being tied down, i.e. wife and kids and familial responsibilities, and having to sacrifice for them, not boredom at work.
but my wife says she wishes we could do just once a month.
Sounds like she wishes it could be never. I thought women were supposed to get more interested in it as they got middle-aged?
Cycle the colors to your particular pattern, and you're in.
And then of course you'll need one of these to generate a really hairy, secure pattern for yourself.
This is similar to what I was thinking -- the time at which an organization should be catching such errors is neither in the code review nor in running an analysis tool, it's during the interview.
If the information is what it sounds like, it's information about the customer's activity. There'd be a very difficult argument that you own that data instead of the customer owning it.
Who's collecting it? The customer could certainly track their own activity if a company's terms were not satisfactory.
Think of it this way: if you believe you should have control of and access to your medical files, credit reports, and bank records; then this customer should have the same with their data.
It's not about saying what a customer can do with their data, it's about saying what a customer can do with your particular copy of their data. I can get my credit report, and look at it 1000 times in a day if I want, but I can't get my credit report 1000 times a day.
If it's one thing people love it's a good romantic myth. "Good programmers are typically also artists or musicians." "Wow, that's really neat. It makes me feel good to believe that. And it's an interesting idea to keep as something to tell and amaze and delight others with." And so it gets passed around and around.
I would say there's not enough time in the day to be a virtuoso at both programming and something else. There's always more books to read and techniques to learn in software development. And competency is not just in knowledge of course, but is increased also by experience. And that means time. The best programmers don't serve two masters. The best programmers don't view programming as their day job, that allows them to go home and play the flute or sculpt or whatever. Programming is our life, it's what we are best at, what seemingly we were born to do.
It sounds like you may be basing "competency" on mostly having a good attitude. Your actual correlation may instead be "most of the programmers I enjoy working with are artists or skilled artisans of some sort." That is, you may not be very hard-core yourself, and therefore prefer those who are more "well-rounded".
Exactly. In fact, the asker is presenting a good lesson I think to be learned by all: Don't let what you do for fun turn into work. Don't allow yourself to actually stress over a project if you're not getting paid for it. If your side software project has become "a fairly serious problem" for you, you've gotten way off track with the spirit of creating software as a labor of love.
For a minute there I didn't see the person behind the desk in this picture, and thought Google greeted visitors in their lobby with just a PC, with a browser opened to their home page, maybe as a portal to a special internal "Google campus" search database that could tell you things like where Joe Blow sits or when the gift shop closes. Receptionists soon to be obsolete.