Coffeehouse Thread

84 posts

"Microsoft Out of Favor With Young, Hip Developers"

Back to Forum: Coffeehouse
  • Ian2

    Larry Osterman said:
    Dr Herbie said:
    *snip*

    Interesting. I was interviewing a lot of those graduates 15 years ago and I don't remember ever having that problem.  Most of the people I interviewed were bright, enthusiastic and knew the kinds of things I expected them to know. 

     

    That might be the result of really good pre-screening on the part of HR though.

     

    What worries me is the number of new developers I see that don't seem to have a grasp of fundimentals.  Developers who would write:

    void MyFunction(string input)
    {
        string dest;
        int dotIndex;
        while ((dotIndex = input.find(".")) != string::npos)
        {
            dest.push_back(input.substr(0, dotIndex-1);
            dest.push_back("\.");
            input.erase(0, dotIndex);
        }
    }

    instead of:

    void MyFunction(string input)
    {
    string dest;
    const char *inputString = input.c_str();
    int dotIndex;
    while (*inputString)
    {
    if (*inputString == '.')
    {
    dest.push_back('\');
    }
    dest.push_back(*inputString);
    inputString += 1;
    }
    }

    Note: Forgive the typos above - this is a real example of code someone wrote during an interview (resurrected from memory, so the code is likely to not work).  Even if the code isn't used in a performance critical area, IMHO the original example isn't nearly as clear as the second one (the first one also isn't correct since it doesn't copy the string if there aren't any '.' characters, but we won't go there).

     

    OK, how do we know you are real?  Show us a bit of that pre-emptive multitasking code then maybe we'll see ..

     

    rd3d2 (Bill G)

  • Dr Herbie

    Larry Osterman said:
    Dr Herbie said:
    *snip*

    Interesting. I was interviewing a lot of those graduates 15 years ago and I don't remember ever having that problem.  Most of the people I interviewed were bright, enthusiastic and knew the kinds of things I expected them to know. 

     

    That might be the result of really good pre-screening on the part of HR though.

     

    What worries me is the number of new developers I see that don't seem to have a grasp of fundimentals.  Developers who would write:

    void MyFunction(string input)
    {
        string dest;
        int dotIndex;
        while ((dotIndex = input.find(".")) != string::npos)
        {
            dest.push_back(input.substr(0, dotIndex-1);
            dest.push_back("\.");
            input.erase(0, dotIndex);
        }
    }

    instead of:

    void MyFunction(string input)
    {
    string dest;
    const char *inputString = input.c_str();
    int dotIndex;
    while (*inputString)
    {
    if (*inputString == '.')
    {
    dest.push_back('\');
    }
    dest.push_back(*inputString);
    inputString += 1;
    }
    }

    Note: Forgive the typos above - this is a real example of code someone wrote during an interview (resurrected from memory, so the code is likely to not work).  Even if the code isn't used in a performance critical area, IMHO the original example isn't nearly as clear as the second one (the first one also isn't correct since it doesn't copy the string if there aren't any '.' characters, but we won't go there).

     

    Possibly a cultural thing -- perhaps UK Universities were too academic while US Universities were a bit more practical.  I read a whole spate of magazine articles while I was doing my PhD including one by a (I think) a leading member of the CBI who categorically stated that he avoided employing CS graduates as programmers. Unfortunately this was a good, old-fashioned hardcopy magazine made of dead trees, so I can't provide a link (or find out exactly who the article was by) Sad

     

    Herbie

     

    EDIT: self-doubt creeping in -- may not have been the CBI, but some other organisation.  Stupid interwebs; why can't you reference magazines from the 1990's? Tongue Out

  • ScottWelker

    ManipUni said:

    I cannot speak to this article but I know a lot of college graduates and people in masters programs, I would say C#, VB.Net, and Java are all very popular. The reason why is very simple - all three are free to learn and have great resources for students. Universities seem to be adopting C# from Java however.

     

    I'm not sure what a "young, hip developer" is. I think "hip developer" is an oxymoron within its own right.

     

    It is worrying how unpopular ASM, C/C++, and other lower level languages are outside of the elite technology schools - some of which barely give a good programming education as is.

     

    edit: Seems the NY piece is a bunch of lies that misquoted Tim O' Reilly. What he actually said was that young startup companies are very interested in mobile platforms - iOS 4.0 and Android. Which sounds like it could be true, mobile platforms are cheap relatively speaking to create revenue generating software for. I would say that Microsoft might be falling behind in that area as they lack any real competition in the mobile area (despite what you read on the C9 forums)/

    "'hip developer' is an oxymoron"

    Tongue Out

  • Larry Osterman

    Ian2 said:
    Larry Osterman said:
    *snip*

    OK, how do we know you are real?  Show us a bit of that pre-emptive multitasking code then maybe we'll see ..

     

    rd3d2 (Bill G)

    Ian2: What do you mean "real"?  If you're asking if I'm the same person who writes http://blogs.msdn.com/larryosterman, the MSFT watermark on my posts should be enough Smiley.

     

    Others: And you're right that the function has no side effects - it's an interview question. And in an interview, I don't care about string vs wstring - they don't matter.   And even if they'd removed the .erase, the function is STILL broken - the core mistake was using string::find() - that causes the function to run in O(n^2) instead of O(n).

     

    But the developer in question didn't know that and didn't understand why a O(n) algorithm is better than an O(n^2) algorithm.

     

    And that's totally unacceptable to me.

  • figuerres

    Ian2 said:
    Larry Osterman said:
    *snip*

    OK, how do we know you are real?  Show us a bit of that pre-emptive multitasking code then maybe we'll see ..

     

    rd3d2 (Bill G)

    @Ian:  YOW!!  Hey Larry is the real deal.... he's been a round MS for a *LONG* time :--)

  • Sven Groot

    Larry Osterman said:
    Ian2 said:
    *snip*

    Ian2: What do you mean "real"?  If you're asking if I'm the same person who writes http://blogs.msdn.com/larryosterman, the MSFT watermark on my posts should be enough Smiley.

     

    Others: And you're right that the function has no side effects - it's an interview question. And in an interview, I don't care about string vs wstring - they don't matter.   And even if they'd removed the .erase, the function is STILL broken - the core mistake was using string::find() - that causes the function to run in O(n^2) instead of O(n).

     

    But the developer in question didn't know that and didn't understand why a O(n) algorithm is better than an O(n^2) algorithm.

     

    And that's totally unacceptable to me.

    I wasn't being entirely serious with all my responses. Smiley

     

    Though I have to ask, unless I'm missing something (and it's entirely possible since it's past midnight and I got up early today), I don't see why using string::find makes it O(n^2). Ignore erase for a moment, let's say it was done the more logical way by just keeping track of the last index and passing that as an offset to find. That means the contents of input are scanned twice, once to find the periods, once to copy it. That's O(2n) which equals O(n), not O(n^2), isn't it?

     

    Again, I could easily be wrong. Please enlighten me. Smiley

  • Ian2

    figuerres said:
    Ian2 said:
    *snip*

    @Ian:  YOW!!  Hey Larry is the real deal.... he's been a round MS for a *LONG* time :--)

    Yeh, I posted that and then had one of those 'why did I just post that' moments.  Having said that its probably part of what defines me as a geek (with just a little nerd thrown in for good measure).

     

    My 'favourite" interview question was something about if I was coding in the sixties what would I be doing differently?  I think I fuddled it and said something about having to be way more careful about performance (it still matters, but in those days just wasn't optional).  I got the job so I guess that was an OK answer.  I don't like code specific questions because I don't keep syntax stuff in my head (at least since intellisense was invented)

     

  • Sven Groot

    Sven Groot said:
    Larry Osterman said:
    *snip*

    I wasn't being entirely serious with all my responses. Smiley

     

    Though I have to ask, unless I'm missing something (and it's entirely possible since it's past midnight and I got up early today), I don't see why using string::find makes it O(n^2). Ignore erase for a moment, let's say it was done the more logical way by just keeping track of the last index and passing that as an offset to find. That means the contents of input are scanned twice, once to find the periods, once to copy it. That's O(2n) which equals O(n), not O(n^2), isn't it?

     

    Again, I could easily be wrong. Please enlighten me. Smiley

    Actually, I hadn't considered the use of substr which creates an additional temporary. Not entirely sure if that makes it O(n^2) though (as an aside, string::push_back only accepts a char so the original sample doesn't compile anyway, that's beside the point though).

     

    But my assertion was that using string::find doesn't automatically mean it becomes O(n^2). If we rewrite the bad algorithm thusly, so it no longer uses substr or erase:

    string MyFunction(const string &input)
    {
      string dest;
      int prevIndex = 0;
      int index;
      while( (index = input.find('.', prevIndex)) != string::npos )
      {
        dest.append(input.begin() + prevIndex, input.begin() + index);
        dest.append("\\.");
        prevIndex = index + 1;
      }
      dest.append(input.begin() + prevIndex, input.end());
    
      return dest;
    }

     

    Yes, this is obviously less efficient than Larry's second version. But, I do think it still executes in linear time.

  • figuerres

    Ian2 said:
    figuerres said:
    *snip*

    Yeh, I posted that and then had one of those 'why did I just post that' moments.  Having said that its probably part of what defines me as a geek (with just a little nerd thrown in for good measure).

     

    My 'favourite" interview question was something about if I was coding in the sixties what would I be doing differently?  I think I fuddled it and said something about having to be way more careful about performance (it still matters, but in those days just wasn't optional).  I got the job so I guess that was an OK answer.  I don't like code specific questions because I don't keep syntax stuff in my head (at least since intellisense was invented)

     

    Yeah.... i was just kind of surprised when i saw it ...

    but then i kind of feel like there are bunch of folks i "know" at MS even if i have never seen them in person.... just been using MS tools for so long and having almost as much time in this stuff as they do...

     

    my war stories go back to DOS after all... and even CP/M

    Lol Smiley

  • kettch

    figuerres said:
    Ian2 said:
    *snip*

    Yeah.... i was just kind of surprised when i saw it ...

    but then i kind of feel like there are bunch of folks i "know" at MS even if i have never seen them in person.... just been using MS tools for so long and having almost as much time in this stuff as they do...

     

    my war stories go back to DOS after all... and even CP/M

    Lol Smiley

    I'm sure that the combination of all of the videos and their posting in the forums gives us all a stalker type sense that we know people. Not that it's necessarily a bad thing. Smiley I promise that if I ever visit the campus that I won't be creepy.

  • spivonious

    Larry Osterman said:
    Dr Herbie said:
    *snip*

    Interesting. I was interviewing a lot of those graduates 15 years ago and I don't remember ever having that problem.  Most of the people I interviewed were bright, enthusiastic and knew the kinds of things I expected them to know. 

     

    That might be the result of really good pre-screening on the part of HR though.

     

    What worries me is the number of new developers I see that don't seem to have a grasp of fundimentals.  Developers who would write:

    void MyFunction(string input)
    {
        string dest;
        int dotIndex;
        while ((dotIndex = input.find(".")) != string::npos)
        {
            dest.push_back(input.substr(0, dotIndex-1);
            dest.push_back("\.");
            input.erase(0, dotIndex);
        }
    }

    instead of:

    void MyFunction(string input)
    {
    string dest;
    const char *inputString = input.c_str();
    int dotIndex;
    while (*inputString)
    {
    if (*inputString == '.')
    {
    dest.push_back('\');
    }
    dest.push_back(*inputString);
    inputString += 1;
    }
    }

    Note: Forgive the typos above - this is a real example of code someone wrote during an interview (resurrected from memory, so the code is likely to not work).  Even if the code isn't used in a performance critical area, IMHO the original example isn't nearly as clear as the second one (the first one also isn't correct since it doesn't copy the string if there aren't any '.' characters, but we won't go there).

     

    I would write:

     

    Sub MyFunction(input as String)

       Dim dest as String = input.Replace(".", "\.")

    End Sub

     

    Let the framework designers worry about algorithm performance. I just want the result. Smiley

  • Dr Herbie

    spivonious said:
    Larry Osterman said:
    *snip*

    I would write:

     

    Sub MyFunction(input as String)

       Dim dest as String = input.Replace(".", "\.")

    End Sub

     

    Let the framework designers worry about algorithm performance. I just want the result. Smiley

    That was my thought too -- which is why I'll probably never be good enough to work for Microsoft Smiley

     

    Herbie

     

  • vesuvius

    Sven Groot said:
    Sven Groot said:
    *snip*

    Actually, I hadn't considered the use of substr which creates an additional temporary. Not entirely sure if that makes it O(n^2) though (as an aside, string::push_back only accepts a char so the original sample doesn't compile anyway, that's beside the point though).

     

    But my assertion was that using string::find doesn't automatically mean it becomes O(n^2). If we rewrite the bad algorithm thusly, so it no longer uses substr or erase:

    string MyFunction(const string &input)
    {
      string dest;
      int prevIndex = 0;
      int index;
      while( (index = input.find('.', prevIndex)) != string::npos )
      {
        dest.append(input.begin() + prevIndex, input.begin() + index);
        dest.append("\\.");
        prevIndex = index + 1;
      }
      dest.append(input.begin() + prevIndex, input.end());
    
      return dest;
    }

     

    Yes, this is obviously less efficient than Larry's second version. But, I do think it still executes in linear time.

    FUD

  • bjd223

    At PSU all compsci / ist students are taught structured programming in C++ first, and then move to object oriented programming under Java and C#. Not sure if anything has changed lately but it worked out pretty well when I did it.

  • Charles

    In some sense, we could do a better job of focusing our platform wares (how many tools does it take to do the same thing?) and highlighting the great things that are built using them. Make no mistake, Windows is a great platform to target should you want to get into the software business. Windows is a big tent and any number of applications, using any number of tools, can be written to get the most out of Windows. The question is: why has Windows client app development declined? The tooling? Maybe. What do you think?

     

    C

  • Shining Arcanine

    Dr Herbie said:

    Meh.

     

    There has always been a conflict between what's taught on a CS Course and what business wants out of developers.

    15 years ago there were articles complaining that CS graduates were terrible developers; they got CS Degrees that taught them how to design a CPU, or mathematically prove an algorithm was correct, but that didn't teach them how to follow a spec from a client.

     

    Now CS degrees have moved the skillsets they teach closer to what business wants, and it's just the toolset that differs. Business isn't going to suddenly change its ways to suit the CS courses taught.

     

    Herbie

     

    I do not think business interests should have any say in the design of college curricula. They exist to educate people, not to train them like pigeons. Let businesses train their own employees.

     

    By the way, for anyone who does not understand the pigeon reference:

     

    http://www.time.com/time/magazine/article/0,9171,909994-5,00.html

    http://www.google.com/technology/pigeonrank.html

     

    The google link is actually a joke, but the link to Time.com shows that it is rooted in reality. With proper training, pigeons can be made to do a great number of things.

  • Shining Arcanine

    Larry Osterman said:
    Dr Herbie said:
    *snip*

    Interesting. I was interviewing a lot of those graduates 15 years ago and I don't remember ever having that problem.  Most of the people I interviewed were bright, enthusiastic and knew the kinds of things I expected them to know. 

     

    That might be the result of really good pre-screening on the part of HR though.

     

    What worries me is the number of new developers I see that don't seem to have a grasp of fundimentals.  Developers who would write:

    void MyFunction(string input)
    {
        string dest;
        int dotIndex;
        while ((dotIndex = input.find(".")) != string::npos)
        {
            dest.push_back(input.substr(0, dotIndex-1);
            dest.push_back("\.");
            input.erase(0, dotIndex);
        }
    }

    instead of:

    void MyFunction(string input)
    {
    string dest;
    const char *inputString = input.c_str();
    int dotIndex;
    while (*inputString)
    {
    if (*inputString == '.')
    {
    dest.push_back('\');
    }
    dest.push_back(*inputString);
    inputString += 1;
    }
    }

    Note: Forgive the typos above - this is a real example of code someone wrote during an interview (resurrected from memory, so the code is likely to not work).  Even if the code isn't used in a performance critical area, IMHO the original example isn't nearly as clear as the second one (the first one also isn't correct since it doesn't copy the string if there aren't any '.' characters, but we won't go there).

     

    Did you ask him what the computational complexity of his algorithm was? It looks O(nm) to me, while yours is O(n). When the entire string consists of '.', you can call it O(n^2).

     

    By the way, dotIndex will give you a compiler warning in the second one, because it is not used.

  • Bass

    Charles said:

    In some sense, we could do a better job of focusing our platform wares (how many tools does it take to do the same thing?) and highlighting the great things that are built using them. Make no mistake, Windows is a great platform to target should you want to get into the software business. Windows is a big tent and any number of applications, using any number of tools, can be written to get the most out of Windows. The question is: why has Windows client app development declined? The tooling? Maybe. What do you think?

     

    C

    The web is a royalty free standard with many different vendors (Apple, Mozilla, Microsoft, etc.) involved so it doesn't have the same lockin potential. The standards based web is open and a relatively slow moving target with extreme backwards compatibility.

     

    Lockin is a disaster, it leads to software rot. Software really doesn't rot, just like the Pythagorean theorem doesn't rot. But yet many enterprises are spending millions of dollars rewriting "legacy" code that is only legacy because it was locked into some vendor's platform or product line that is either retired or doesn't exist anymore. The ideal stitution is the code I write today should be useful 1000 years from now. But these days we have problems where code that is just a few years old is already "legacy". It's extremely wasteful and a lot of enterprises are seeing this. They don't want to make the same mistake by betting on proprietary technology they have no control over.

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.