<p>I wasn’t talking MS Office simple stuff :-). Purdue’s CIT program and many similar CT/CIT programs follow the usual Microsoft/Oracle/Java type curriculum paths for IT shops. </p>
<p>But, since you mentioned MS Office, take a look at what it takes to, say, integrate MS Office with Sharepoint, and for extra credit, throw in InfoPath, SQL Server and SSRS for reporting. In typical Microsoft fashion, the easy stuff is easy to do, but once you get into the programming part, the stuff is arcane beyond belief. </p>
<p>It’s simple - would you hire a CompSci graduate that is more in tune with requirements analysis, big project designs, coding in languages like Python and the like, etc. or a CompTech graduate that has spent the last 4 years on IT-shop staples like Oracle or .NET or ASP or PHP etc… Depends on your needs, and that’s the beauty of it.</p>
<p>The issue of ‘real skills experience’ is ancient, by the way. In the early-mid 80’s while we were learning all about Berkeley Unix, C, Ingres, and the like, (or busy with PL/1 on Multics) businesses wanted IBM mainframes, MVS, DB2, and the like. So, my college bought us an IBM 3090 monster. Then, Unix super minis became the craze and we bought some of these too (Pyramids, Alliants, yea). Then Sun workstations, blah, blah… It has always been a race between academia and business needs. Then, by the mid 90’s when Win95 came out that was pretty much the time where colleges stuck with their Unix systems while businesses moved more towards N-tier, and the rest is history… You may be able to ‘learn’ the basics from a book, but given how deep interviews go these days…</p>
<p>Now, why can’t I hire a new graduate that knows C++, Linux kernel, LTIB, BSP, etc?</p>