This article is a fairly valueless press release for Dice, but be that as it may: there are no shortages for developers, there are only shortages for developers at the wages employers are willing to pay.
Part of the problem, for these .NET and Java jobs, is the job itself, not necessarily the pay. I get a half dozen calls per week for crappy internal .NET SharePointy positions at near the same salary I'm making. I wouldn't want to do those jobs for 150% of the salary.
Folks that like to program, usually don't like to write back office apps.
There is probably a number at which you or I would write back office apps, though. People don't do I-banking out of love, and there is a lot of headroom between well-paid devs and them.
I kinda like my job right now but for a million bucks I'd kinda like your Sharepoint installation, too.
I was hired as a C# programmer once, only to find out that they'd lied to me about the nature of the position and I would actually be working with SharePoint. I threatened to quit unless they gave me the job originally advertised.
Then the hiring manager bitched to me that all of the programmers they hired quit when they found out the job actually involved Sharepoint!
the hiring manager bitched to me that all of the programmers they hired quit
It's always funny when you hear someone complain that "everyone I've worked with in field X is an asshole" or "All the clients I have are assholes", etc. Pretty soon it's likely that you, not your clients, are the asshole.
Heck, I took a big pay cut to be happier. I was a .NET enterprise developer in the six figures.
There is something about building things outside the box instead of being part of an assembly line at corporate shops. The lack of politics and endless meetings is a bonus too. It's not always about the money.
This thread is indicative of the bias I see on HN. .Net and Java are "uncool" and therefore must not be suited for solving real world problems or doing interesting things. They are also often synonymous with bloated corporate bureaucracies and meetings. By these same stereotypes, should I assume that every Ruby developer is living in a party house with his 4 other co-founders, eating ramen and making social networking applications?
It's not bias, it's just a realistic observation of the market forces at work. People are willing to put up with bureaucracy and dull projects for more pay. There is no shortage of talent, there is merely an abundance of employers who are not realistic about market rates.
Until recently those were the only situations in which you could get a job as a Ruby developer – hamming it out on your own, in a small startup or at a consultancy.
It's still hard to get an Enterprise job as a Ruby developer.
In addition to being unable to pay what the market demands, companies (from my anecdotal perspective) also don't have any desire to train new developers into positions.
It's not that they're unable to pay -- they choose not to.
I see so many companies that want something for nothing. They want the automation and savings from the systems that developers are building, they're just not willing to pay for it. But then ask them if they'd rather go back to the manual business process they were doing before (that doesn't require paying developer salaries) and they look at you like you're crazy.
It seems the enterprisey .NET shops interviewed already hired all the crappy .NET developers who are willing to work for that kind of money and now they would have to move to more expensive ones than the ones they had before. Their reluctance is easy to explain.
Programmers are interesting animals - the good ones work for fun. As long as their bills are getting paid and work is interesting, they stay. Give them a brain-dead job, like anything Sharepoint-related, and they leave.
Programmers are interesting animals - the good ones work for fun. As long as their bills are getting paid and work is interesting, they stay.
I disgaree. They do work on interesting stuff, but getting bills paid isn't sufficient. There's no shortage of interesting work. If you can't find an interesting job at pay you find compelling then there's a problem.
Maybe there's a problem in my situation then. I've not yet found a job that was both interesting with "compelling" pay. Good pay, often yes. "Good" meaning I could pay my bills and have a decent life. But that's not "compelling" to me.
I'm not expecting "fuck you" money, but something that pays enough to compel me to be in a car for 2-3 hours per day commuting, or something interesting enough to compel me to move states.
We probably have different numbers for "compelling" pay.
It usually takes a lot of effort, time, sweat, and luck to find a perfect fit job. It has nothing to do with intelligence, and not everyone is willing to attempt it.
It's not the eight thousand dollars. Trust me. Most schools teach OO in Java. HR departments and often times hiring managers just play keyword bingo. A good developer who knows Java will pick up C# just fine.
Java, and it's ecosystem, are a little more difficult to use and master than C#, and IMO, warrant the extra average pay.
Perhaps it is the scope of the project. Java projects seem to be bigger than that of .NET. .NET tends to be internal apps while Java app could be like some sort of mother-ship type of application (or what people used to joke as the "Command Center" software) or huge integration project.
Having said that, I agree that Java ecosystem is more difficult to learn.
Many students during my college time prefer .NET because VS.NET Express makes a lot of things easier compare to Eclipse, Java, Ant, classpath, etc (forget Maven).
I believe it's the other way around. C# is much more difficult to master than Java in my opinion. You have reified generics in C#, there's true lambda expressions, the dynamic keyword, named arguments, p/invoke etc. Many of these things make the language more expressive and powerful in my opinion, but also give it a much steeper learning curve to truly master.
Java is a little more difficult to practically use because it lacks most of that. Writing clean, maintainable code in Java is a lot harder (for me, at least) than the same in C# (or even in Scala, and Scala seems to lend itself naturally to writing a mess).
Also, let's be honest: the Java ecosystem is a mess in a lot of ways. One of the biggest pluses to the .NET world is that things tend to Just Work a lot more than in the Java world. Not that this is a huge deal (I work in Java, and handle it fine), but considerably more knowledge of the entire Java stack is often necessary than on .NET.
Writing maintainable code in Java, in 2011 anyway, should be a lot simpler than C# due to the shared knowledge within the Java community.
There are probably more books teaching how to write better code in Java than in C#. Even if the number of books in C# that taught better ways to code is approaching the Java counterpart, they are more likely to be newer books and not necessary preached by Microsoft.
As much as people don't like (or abusing) Spring and Dependency Injection concept, more Java projects are using it (with probably some amount of unit-testing) as opposed to C#.
When you look at Continuous Integration landscape, most of them came from Java.
I think Java is much easier to learn because the online documentation and community is superior to C#'s. I've also found that you can't understand the entire stack in .NET because that information is often just not available. You could argue that this makes .NET simpler, but we all know that software abstractions leak. When they do, it's nice to be able to peel the abstractions away.
Oh, and Scala naturally lends itself to writing maintainable and bug-free code.
> I think Java is much easier to learn because the online documentation and community is superior to C#'s.
This does not match my experience in the slightest. MSDN is leaps and bounds better than the Java documentation and the available resources at places like Stack Overflow tend, in my experience, to be of higher quality and quantity. In this I find that C#'s lack of favor as a pedagogical language works in the C# developer's favor: there's much more signal to much less noise.
> I've also found that you can't understand the entire stack in .NET because that information is often just not available.
This is simply not true. There is very, very little information that is not available about .NET (largely derived from either reading the specs or inspecting the IL) and essentially nothing unavailable about the .NET libraries thanks to Rotor (for legally safe inspection of certain libraries) and Reflector (which poisons you for Mono contribution, but is a fairly accepted practice).
> When they do, it's nice to be able to peel the abstractions away.
You can, trivially. It is an indictment of the largely ASP.NET-focused developers mentioned previously that they do not, but it is not a difficult task.
> Oh, and Scala naturally lends itself to writing maintainable and bug-free code.
After some confusion from this statement I entertained, if unwillingly, the thought that you are serious. Scala is no Perl with regard to its distaste for readable code, but it lends itself to ambiguous or stupid syntax (the inanity about "using what you like" for parens versus braces comes to mind as a minor quibble, the flinging of underscores throughout "idiomatic" code being a much greater one). To complicate matters, Scala's IDE support (even in IDEA, the best of a sorry lot) is horrifyingly bad. To what Scala lends itself, I have not yet been able to ascertain, but "maintainable" has surely not been an adjective I'd use. Partial credit for "bug-free" due to its tendency to encourage immutability, for which I am very thankful, but...only partial. I still have to read the byte-vomit.
The best compliment that I can pay to Scala is that it is better than Java--damning with very, very faint praise. I'm praying that Ceylon or Kotlin comes along and deals with this insanity in an adequate manner.
I guess you and I have opposite experiences with Java vs .NET, but I am relatively inexperienced in the .NET arena and am willing to concede the point here.
I am not however, inexperienced with Scala or with programming languages in general. I was very serious about Scala. There is nothing ambiguous or hard-to-understand about Scala's syntax. If a couple of underscores or inferred parenthesis throw you off then I seriously doubt your ability to read source code effectively.
I mean, really. Interchangeability of "()" and "{}" bothers you? Making them interchangeable, along with currying, lets you invoke higher order functions in a way that is much more natural looking than what you can do in C#. The Scala code often looks identical to Ruby's blocks, which, as a second witness, most people also find to be a far more pleasant syntax than the equivalent Python code..
Can you really not, when you see "call(_,_)", parse it in your head as its more verbose C#-like equivalent, "(a,b) => call(a,b)"? If you can read the C# version, there is no reason you can't just as easily read the Scala one.
Is it so hard for you to see that "list filter pred sum" is equivalent to list.filter(pred).sum()? Scala is actually simplifying and unifying the language with this rule. Whereas most languages handle arithmetic operators specially, Scala can treat 1 + 2 + 3 literally as 1.+(2).+(3), which means that + is just a normal method!. In this sense, Scala is simpler and easier to grok than almost any other mainstream language!
And, Scala's IDE support, which is supposed to be fairly good at this point, has no bearing on the topic of conversation. Finally, There is nothing exciting to hope for in Ceylon or Kotlin compared to Scala. It looks like, in terms of language advocacy, we are direct enemies!
Don't forget that C# guys are usually Microsoft bred. Windows guys (in general) just can't seem to grok any other OS or command line tools while non-Windows guys can do ok in Windows (but they complain a lot about not being as productive as they could be). So hiring Java guys to do C# is probably easier than the other way around, but they might want more for the pain of having to deal with Windows.
Edit: There are of course exceptions to this, but I have seen it too many times to not see believe it is the norm.
Windows guys (in general) just can't seem to grok any other OS or command line tools
I have to take exception to that -- or at least the specific phrasing.
It's certainly true that most MS-platform guys don't grok other platforms. But I strongly disagree that they cannot do so, given a brief period to learn.
Almost everyone I know who does Windows dev work used to do Unix work. All you do in college is Unix. And most university recruiting is for Unix positions. Those .NET enterprise jobs don't recruit at colleges, but no college student knows C# or .NET or ASP.NET.
My experience is these people typically transition over later in their careers.
I'm not sure those figures tell you much. Java and .NET jobs tend to be in different parts of the country depending on the culture of the city. .NET jobs are concentrated in the east, where cost of living is much lower, and Java jobs are more concentrated in the west.
Dice believes that developers are worrying that if they specialize in .NET development, they won’t be able to branch out to other platforms.
That's a valid concern, in my opinion. I don't know why, but even talented Microsoft developers I've spoken to have been woefully unaware of developments outside of the .Net/ASP sphere. It's almost as if innovations don't exist until they've been incorporated into the CLR. I've seen similar attitudes in Java developers, but it appears to be far worse in the .Net community.
That was, in fact, one of the reasons I chose to keep practicing other programming languages while I was employed by a .Net shop. I didn't want to end up "stuck" knowing only .Net like so many of my co-workers.
I didn't want to end up "stuck" knowing only .Net like so many of my co-workers.
I'm in the same boat. It's a shame too, in my mind at least, because I really do enjoy working with the better parts of the platform (MVC, WCF, C# 4, VS 2010, etc).
I'm currently working in a .Net shop and the work is not terrible by any means (it's a fairly large scale web application used by school districts), but I'm starting to fall out of love with the MS lock-in and general attitude of the folks I've worked with so far. I'm pretty sure 95%+ of my current and past co-workers have no idea what hacker news is (or even /r/programming for that matter). The general reaction when telling someone about my side projects learning Scala/node/rails/etc on my (gasp) Mac at home is along the lines of "huh?".
I worked in .Net shops for a few years, back in the days before .Net MVC. Part of the reason people ended up (and maybe still end up) stuck in .Net might be because back then, as soon as you tried stepping outside of the .Net webforms box (i.e. tried to do anything remotely interesting) things because exponentially complex. Keeping all of the .Net classes and foibles in my brain during my day job was enough for me not to want to learn the intricacies of a different system in my off time.
That was years ago though... and since then I've happily moved on to being self-employed and using OSS.
Yeah Microsoft tends to deprecate and replace frameworks every few years. Usually it's an improvement, but they really keep you on an API treadmill.
Eventually I got tired of it and went back to primarily Win32 development for customer-installed apps and Linux for everything else. I feel like I can focus on quality rather than quantity much better now.
In my experience, looking at it from the other side is even worse. In fact, it's so bad that as soon as they hear Microsoft their brain shuts down. They get this emotional reaction that makes any rational discussion difficult if not impossible.
If it was merely zealotry, then I'd be okay with it. As you point out, there are zealots on both sides of any divide. No, the problem I'm talking about is ignorance. On the Unix side, people have at least heard of other frameworks. If you're a Django dev, you've probably at least heard of Rails, Plone, etc. If you're on the Microsoft/ASP.Net side of things, however, it's routine to encounter developers who haven't even heard of Django or Rails.
I wouldn't say zealotry is any better. I've had experiences where as soon as anything MS is brought up, or they find out you use MS technologies, you get looked at like you're crazy / inferior. Zealotry is a good word for it, because I'd get a similar feeling to when somebody finds out you pray to a different God, or even worse no God at all. In my opinion ignorance is easier to fix than zealotry.
Zealotry will do less damage to your career than epistemic closure.
If you had to choose one of two faults: Nothing But Microsoft OR Anything But Microsoft -- you're going to be better off as an ABMer since (theoretically) your ecosystem of options is MUCH larger. Rejecting Microsoft still leaves you with several other marketable options. Rejecting everything that isn't Microsoft leaves you completely at the mercy of a single platform that you have no control over (and if you did have control over it, it still wouldn't be ideal)
You're making the assumption that MS is the only target, it's not. The reason it's so destructive is because you eliminate certain options based on emotion rather than reason.
So on one hand you're dealing with a fanatic that only sees black and white, and the other you're dealing with apathy. Not exactly good options.
I used to find that some years ago, but not so much any more. Microsoft used to have a reputation for making a lot of quite shoddy software (VB/VBA/etc.), but most developers, even the most hardened OSS neckbeard-wearing types will admit nowadays that .NET isn't a bad framework and C# isn't a bad language.
You might be well-served to differentiate between "Enterprise .NET" and ".NET". I'd agree with a lot of what you're saying if it's applied to folks who "think in ASP.NET", but outside of that? Not so much. You've got Mono developers, who tend to bounce between Windows and OS X pretty regularly and a bunch of other folks who are at least aware of the stuff on the other side of the fence. And then you've got folks who use it as a tool--appropriate in some situations, not appropriate in others.
(As noted in a sibling comment, it's also very common to see people turn their brains off rather than entertain .NET as a sometimes-appropriate tool.)
I myself am a ASP.NET MVC developer by day, and play with Node.JS by night. I agree with you on the difficulty in moving outside the .NET world, but I will say ASP.NET MVC isn't nearly as bad as webforms. Webforms abstracts so much of how the web works away that that it's extremely difficult to wrap your head around anything else. And like you said, because the abstraction is so deep, it's very difficult to make room in your mind for anything BUT webforms. With ASP.NET MVC, I've found very little difference. The majority of the coding for most modern CRUD apps is on the client-side anyway, so the majority if your knowledge is transferable to Node.js. Express and ASP.NET MVC both follow a restful model, and I already had experience working with closures, async calls,from client-side javascript, so I haven't found the conversion to be very difficult at all.
Ah, okay. I moved away from .Net just after ASP.Net MVC was released, so I didn't get a chance to see what impact it would have on the community.
The reception to ASP.Net MVC, though, confirmed my original point about the .Net community. I heard lots of talk treating the MVC pattern as revolutionary, when, in fact it was something that was rather common outside of the .Net community.
It wasn't even the first .Net MVC implementation, Castle Monorail has been around since late 2005.. 3 or 4 years before the first version of ASP.Net MVC.
But it takes the Microsoft stamp to get a lot of these people excited.
See: ASP.NET MVC... it took years until the "official" framework came along for anything even close to sane became more mainstream in .NET web development.
Yes, there were other "Rails for .NET" frameworks out there. But, you are correct: the vast majority of .NET developers are waiting for the official Microsoft seal of approval before adopting anything. It's part of the culture that comes with choosing Microsoft for your stack: you want support, or at least somebody to sue when it goes wrong.
Part of the problem is that in Enterprise .NET, it's hard to convince your boss to use a non-MS solution. Unfortunately, a lot of .NET is done in the Enterprise environment, which results in a population of programmers that live in a very big bubble.
I was in that position. I professionally used .NET since its inception up until about 4 months ago. I switched to a JavaScript job at a company that doesn't use any MS tech at all. Not wanting to get stuck shoehorned as an MS-only developer was a major motivation for me making the switch.
This will be an interesting one to watch. I know a ton of great .NET developers who have bailed on the platform and switched to open source. This is anecdotal for sure, but if this is a huge trend then you're left with a bunch of companies with huge investments in a platform, and an ever decreasing number of developers who can actually code effectively for it. The salariesrates should go up, but these typical corporate .NET clients are cheap motherfuckers. I'd predict a resurgence of offshore consulting to meet demand.
However it does seem like devs for every technology are in high demand and low supply. It could just be as simple as that.
I'm a .NET fanboy, but the likelihood of me ever working for a .NET shop is next to nil. The work is just not interesting. Sure, if I just wanted to collect a (almost decent) paycheck, I'd do it, but given that there are a dozen other niches I can work in, I'll pick any of them over the .NET world. The only way I'd be converted is a massive paycheck and at least some interesting problems, but neither of those seem to exist in the .NET world, by and large.
I'm on the other side of the fence: At my last place we actually had some moderately interesting problems to solve, but had a hard time hiring because the vast majority of the applicant pool couldn't do anything that they couldn't look up on Google or StackOverflow.
Even with a moderately easy tech-screening process we could only realistically do second interviews with around 1.5% of the applicants we got. For as good as .net is, I think it's doomed to be relegated to accounting apps for the foreseeable future.
Amen. I got lucky- I'm a .NET developer now working for a small startup in NYC, but spent a long time in .NET shop hell.
That said, we're starting to look for another developer, and it's a nightmare. So many resumes of people that (without wanting to sound rude) belong in a .NET shop- I interviewed one guy that didn't even know SQL, because all he'd ever done was use prebuild factory methods for database access. He had a Masters.
untog, if you see this, could you drop me a line? Email should be in profile. I'm a .NET developer in NYC and may be looking to make a move. And I know SQL :)
The 2 .NET shops I was in had a pretty bad way of commoditizing the developers working there (and thus started believing offshoring was the way in this, the year of our lord, 2011).
This also led to them working in bringing the code to the lowest common denominator level and was a frustrating nightmare. I was a lone wolf and when I mentioned that I had implemented a couple systems using MVC and jQuery on the front end it blew some of the developer's minds. It's a shame because the framework is capable of a lot, it's just the enterprise shops are terrible of taking advantage of it.
Needless to say, I'm not a .NET developer anymore.
I switched to doing a lot of Flex/Flash/Actionscript and JavaScript related work. I was basically working along the entire stack when I was doing .NET work.
I doubt that is the case. With employment at record highs and good jobs not available I don't think people would rather sit idle than take up a job in .Net. The article can also be rephrased as "Demand for .Net developers surges." Of course it won't be as newsworthy then :)
Sure, there's always going to be a mountain of job applicants for each position, it doesn't mean they can do the job. Finding qualified .NET developers is the real challenge, someone who can architect and build a functional system.
These are the very type of people who are bailing on the platform.
21% were looking for .NET developers with 8-10 years experience.
Wikipedia tells me that .NET 1.0 was released in February 2002, 8.5 years ago. Good to see recruitment companies and HR depts have such realistic requirements. (Still, at least they aren't asking for anyone with 10+ years experience)
I started coding .NET around 1.0. Completely anecdotal but out of the dozen+ people I knew that dove in at the time - zero are still actively involved in .NET.
I rarely take a .NET contract. But what I can say is 1) They always pay my highest rates. 2) Generally it's a bad / scary experience in comparison to python or Clojure (where I do the majority of my work and contracting).
at least in the case of MS technologies, the developers were exposed to the most of the components (or their previous incarnations) of the platform well before official .NET packaging. I'm still wondering what good candidates were placed into one position i came across in 2005 that had 10-12 years of J2EE experience requirement. Somehow i was scared to apply to such a place - as i only worked with Java since 97 and with J2EE since 99 :)
Perhaps off topic a bit, but here's a recent run in with a .net shop.
I was brought in to work on a project. They'd installed a PHP-on-Windows setup for me because I was introduced as a "PHP guy" (which I mostly am, but I do other stuff as well). I indicated I could do the project in ASP.Net, but it would take me a bit longer because it's not my main platform. No... they needed it done ASAP, and were prepared to be a mixed shop. They were already running another PHP app on Windows already, so this was a natural progression. They were already having trouble finding .net people in the area - freelance or otherwise, so it seemed a concession they were willing to make. Find available talent, get job done faster, move on.
Project was done in July and August, then went up the approval chain. I was expecting to come back at end of Sept with a list of changes to make.
"Well.. our developer ported it to .net because that's what he's more comfortable maintaining."
So... rather than spending some time getting comfortable with PHP, they spent time reworking something in to ASP.Net, negating my work, and meaning there was a couple of weeks of other internal .net work not getting done either.
What does this have to do with .net developer shortage? Maybe nothing, or maybe those companies could be more productive by having staff that could work with mixed tech stacks more effectively. I'm stereotyping a bit - we've all met developer X who only knew one technology, and every problem had to fit within that one tech worldview. I've found it with zealots of all stripes, but perhaps it hurts a bit more at the enterprise level?
I know I'll get down voted for saying this but I just have to do it - could it be that developers no longer want to work for boring corporate assembly-line level "lets make yet another database front-end for yet another inventory management system"? Could it be that people who like to code actually care about the code and tools that they are using? Could it be that developers are seeing the writing on the wall about Microsoft and are leaving in droves?
I work for a .NET based startup doing fun and interesting things, so I know that C# and .NET can actually be fun to code in. However, most, if not all, of the .NET job listings I see on Twitter are boring soul-killing enterprise jobs. Or worse, Sharepoint!
Fortunately, there seems to be a renaissance going on at MS. They realise they no one likes working with their shit tools. Sure MS technology may "run the world", but all the cool/fun stuff is being done in the OSS stack. When was the last time you heard of a hot startup using .NET? MS wants in on the party and a lot of their new stuff has a deliberate non-enterprise angle with a focus on developer enjoyment.
I run a .NET shop where we do pretty interesting stuff, and it is sooo hard to recruit decent .NET developers. The first step of my recruiting process is a simple, but moderately challenging algorithm in C# to complete at the candidate's leisure and send to me. 80% - 85% don't come close to getting it right even though acceptance criteria are part of the very simple instructions.
Can you reveal the algorithm you are asking them to implement? Your anecdote is interesting in the context of the recent stories about a lot of programmers not being able to solve the fizz-buzz problem.
I'm not the parent but we're in very similar position (finding it very difficult to find decent .NET developers, candidates can't answer even the most basic algorithmic questions), so I'll answer your question for you.
I typically ask candidates to implement a function that calculates the nth element of the Fibonacci sequence, write a program that prints the values in a binary tree in ascending order and finally to implement an algorithm that finds the value of the element in the middle of a linked list. These are just "introductory" questions, but very very few candidates make past this stage so I very rarely get to ask serious / deep programming questions to candidates.
And believe me, I'm very forgiving on interviews and try to take into consideration that the candidate is probably very nervous, especially when they are fresh off the school, but what can I do with a candidate who can't figure out how to get the number of elements in a bloody linked list, even after carefully explaining how a linked list works? Or the ones who get the idea that they should be counting all elements but have no idea how? How could I discuss the finer details of type covariance or ask them how they would go on about implementing a face detection algorithm if they can't even come up with the naive solution to the Fibonacci "problem"?
> implement an algorithm that finds the value of the element in the middle of a linked list
I'm struggling to think of the last time I had to use a linked list for anything. I'd be tempted to give the troll answer: put the elements into a List<T> already, divide list.Count by 2....
Sure if it's doubly linked then you can walk it from both ends and meet in the middle, then think about how to handle the case where there are an even number of elements, but do you really want a serious answer about linked lists in .Net?
From a recruiting point of view, this kind of questions are indicators. They are easy to verify and they are correlated with some other, more relevant skills.
First, knowing your 101 Data structures is correlated to your Computer Science general knowledge. What relevance does it have? It depends on the job description. There are jobs that merely require churning out bland CRUD application code, and it does not make much of a difference if you know this stuff. But, in general, for anything that has strong performance requirements, it might be a concern.
By example, if you let me feed the troll, your solution shows a mix of cleverness, (potential) ignorance and unawareness of the high level goal.. that I might be concerned you would produce something like...
On the other hand, Linked lists also give you a hint of the ability of the candidate to manipulate pointers/references. This may or may not be relevant, again, depending on how often do expect to use this skill in your code base. A trivial solution would let you at least know that the person pays attention to detail and does not leave a mess behind. A more sophisticated approach gives you more information about actual expertise (like, if you know about cycle detection, this is a piece of cake).
> First, knowing your 101 Data structures is correlated to your Computer Science general knowledge.
I can't quite shake the idea that what you're really testing is if the applicant has been to the same kind of school as yourself.
> There are jobs that merely require churning out bland CRUD application code, and it does not make much of a difference if you know this stuff
I've seen some really interesting (and performance-constrained) code done in .Net that didn't use pointers or linked lists in any way. It's not either "bland crud" or pointers, that's a false dichotomy.
Of course, concepts like parse trees, A-B pruning or Hungarian method of optimization are things that are worth having a hold on. But "how often you expect to use the skill" of linked lists with pointers in many modern languages, Java and C# included, is effectively never.
No idea where the crap java code for a sorted list came from, hope you're not trying to put those words in my mouth!
In the .Net world, good companies do try to look out for "broader" developers who are aware of useful open-source software toolkits, and want to practice things like Dependency Injection, TDD, Continuous Integration etc. They generally make better coders.
Yes, I am aware of the CS vs street smarts debate. Everybody has its own opinion, and I am sure neither of us is going to convince the other, so I'd rather not go there.
At the end of day, you seem to miss my point altogether. Testing for the skill is not useful in itself. It is just an heuristic.
The industry is choke full with people that seem fairly competent and accomplished, who is able to produce code that fulfills the specification, but who also come with a collection of vices, bad practices, and simply cannot make trade-offs intelligently.
People like me wants to believe that, because CS foundations are not strictly needed for the task at hand, these people tend to ignore it for the same reason that they ignore other, more important, stuff that also is not strictly needed to complete the task at hand (but that will have a direct impact on the quality of your solution).
I am fully aware that there are great developers that do not come from a CS background. I am also painfully aware that there's people who excels at the CS 101 questions but cannot perform in a real world environment. At the end of day, this does not provide a final go or no go answer. It is just an indicator of whom you want to bring in for a deeper, longer interview.
> hope you're not trying to put those words in my mouth!
Not at all. I was just going on with the troll thing. Hope I did not offend you.
> At the end of day, you seem to miss my point altogether. Testing for the skill is not useful in itself. It is just an heuristic.
I see the point, I just disagree with it. There's some validity to using CS101 knowledge as a heuristic, but as you have admitted, it's not perfect. We just disagree on how imperfect it is.
That's not the point, the question is about understanding fundamental, abstract computer science concepts and being able to craft simple algorithms. Even if we don't manipulate these data structures directly these days in code, there are "real world" concepts that are very similar to these fundamental data structures such as HTTP redirection chains, various stages of a workflow and so forth. It is due to the very nature of computers that a good developer has to be able to find abstractions in real world patterns and solve problems using these abstract ideas. A linked list (or a binary tree) is a very simple abstract idea and it's a good device for measuring the candidate's skill at solving abstract problems.
Additionally, my view and experience is that unless we're trying to hire a specialist in a niche, domain knowledge (in this case, .NET) is considerably less important than general programming skills and abilities; a good developer with limited .NET skills would still write excellent .NET code, a developer who's very familiar with the .NET Framework but who's poor programming skills would be a liability for the company.
Last time my manager asked me to come up with a simple test for interviews I added a question with code and asked what it was: a bubble sort in C#. No one got it right, not even a "it sorts the array".
I don't want to publish it, only because I like it so much for its simplicity, yet efficacy in weeding out candidates. I don't want it to become too popular. I will say it has to do with processing a single array in a way that could come up in a business application (although I have never seen it). An important part of the assignment is to understand the simple instructions, which include the statement //sample test case (your solution should pass any test case), followed by a sample test case, an array of a particular length.
A lot of talk here about the types of businesses that normally do .NET work and how they aren't very good to work for, so I figure here's a good place to ask for some advice.
I've been working full time as a .NET dev and doing my degree part time for the last 5 years, graduating next month hopefully around the top of my class. I enjoy .NET, particularly ASP.NET MVC, and my current job has let me have full control over the development workflow, I use TDD,Git,MVC,Jquery etc. Looking at what I should do next if I was to change jobs it kind of feels like russian roulette trying to find a company here in Brisbane, Australia that hires good devs to do interesting .NET (or any development work) while paying well and without being a sweat shop.
My question is, where should I branch to if not in .NET? Java seems like the other big area around here but its all enterprise stuff as well. I've done some mobile development in my own time, got a couple of apps on the iOS app store and some Android on the way. One of which uses a NodeJS/MongoDB back end, but I'm not sure there's that many jobs around here for that (iOS/Android development may be a good option, though I do like web dev). I'll be looking to relocate in a few years, but for now, does anyone have any suggestions for what framework/language I should learn next?
To all the people here who said they moved away from .NET due to the kinds of employers and fellow developers that use it, where did you move into and how did that work out for you?
If you're looking for particular non-mainstream framework/langues jobs in Brisbane (Node.js being one of them) you should hang around in the Meetups (MeetupJS). Good place to get noticed and job offers.
Thanks Dekz, I've attended a few different meetups in the past (including JS) but haven't had time this year due to a heavy uni workload, will definitely be heading to the various ones around the place. Unfortunately the .NET one (QMSDNUG) is more geared to hearing about new Microsoft products than improving programming skills, but I'll definitely be getting stuck into some meetups around the place.
It's unfortunate that all non-software industry companies are getting tarred with the ".NET Shop" brush, because much depends on the company culture and who is running the development group. I've worked in some great gigs (and one or two awful ones) in settings you might not expect to be interesting and fun.
I'm hiring at the moment, and it's definitely in the "great gigs" category. Bonus, as part of this gig I occasionally get paid to ski and climb. Not that this has helped me find good candidates yet.
In other news, there is an excess of agencies who aren't offering real jobs, but are just collecting resumes to hand off to clients without even reviewing.
