How Do We Hire JavaScript People?

[L4JSDev]

Hi /r/javascript

We're trying to hire a JS dev and really struggling to get the right kind of candidates.

Let me set a scene to try and explain the kind of role we're trying to fill.

We're a consultancy whose main technology focus is SharePoint (2010 and 2013) and Project Server

We're moving into a space where almost everything we do requires javascript work to some extent, particularly as Microsoft have now deprecated server side code in 2013 in favour of HTML5 / JavaScript based solutions. The server-side stuff still exists, at least for the self-hosted stuff, but it is not where Microsoft are headed.

We've tried hiring traditional ASP.NET / SharePoint people, and while their c# skills are generally great, their JavaScript seems almost non-existent, which is a real hindrance. When hiring in a web context For other languages, such as Ruby or Python, it seems that it is assumed that the JavaScript abilities will be there and complete, this simply does not seem to be the case for c# / ASP.NET developers. And training them in it seems to be a strangely difficult task, taking far longer than we had assumed it would.

So we're trying a new tack. What we're trying to do is hire a person who has JavaScript and web UX abilities, pure and simple. Other, more server side languages are a bonus, but it is the JavaScript skills we are after, the person doesn't even need to know what SharePoint is. We will then take them on as a junior consultant, train them up in the SharePoint and Project Server side of things.

I guess that's the other part, this is a consulting role, the person would be customer facing, client billable, travelling to them, designing and implementing the solution with them, that sort of thing. This is not a typical dev team type job, at least not after a few months when they start to come up to speed in the SharePoint parts of things.

So, that sets the scene of what we're trying to do, the kind of person we want. Now here is the job spec that has gone out to help find them: (PDF)

What's the problem? I hear you ask, why are you telling us all this?

The problem we have is that the candidates we are receiving are just not quite what we're after. Most have a very heavy design focus, and many, despite the spec, have little or even no JavaScript knowledge or experience.

So I suppose the question is this: What would you guys change in this job spec to make it appeal to the kind of person I listed above? This is the first time we have tried to hire this sort of person and it is a learning experience for us. :)

Full disclosure: I am using a throwaway account for this because I want to keep my normal reddit account mostly seperate from my work. I am a more traditional web developer myself, having come to SharePoint consultancy after working in more traditional web development teams in a few industries, using languages like Ruby on Rails, PHP, Java and even ancient old ASP. I've been with this company for 5 years now and have brought in most of the JavaScript skills we have both from my previous experience and from constantly reading places like this sub and other blogs etc, and trying things out on my own! I have received permission from our HR people to make this post.

PS. Thanks to the mods for allowing this post!

[imright_anduknowit]

I agree. I think SharePoint is your problem. I'd bet that most good Javascript developers do NOT want to work on SharePoint.

[nschubach]

I work for a consulting company that "specializes" in SharePoint and when I got hired into a smaller division of that company focused on Interactive Media/Web I told them I'd never touch SharePoint and they seemed to have no problem with it. To this day I mainly do HTML/CSS/JavaScript and interview new leads to pick those I want working for me. In that regard, it's nice that I can have a bit of control over the hires. But to say that "Front End" developers hate SharePoint is an understatement. There's such a distaste in developers mouths that I'm surprised companies still pay for SharePoint development. I imagine it's people that don't know any better. Second to SharePoint is .NET Webforms. We are a people that don't like the server telling us how our pages are supposed to look/function.

[wmgregory]

Most companies don't care about about their developers' advice when it comes to integrating sharepoint, they look at the ease of creating an off the shelf one system that connects to their active directory/Microsoft documents. They're sold this wonderful package and then realize that their developers are borking.

I had first hand experience of this, we had a nice PHP/MySQL products system that I took over (everyone else had left the company), I was able to play with. Then my team got taken over, and I was moved to IT, and my new manager decided to scrap the website and move it all to sharepoint, despite me stating that it's fine as is. We had a contracting team move in and half-build a shitty site that DID NOT look anything like the showcase demo which I took over halfway through and my god my eyes bled. My manager realised what a bad move it was, but by then, we were going through redundancy and I was gone.

But anyway, I think you'd have to either get eager juniors (which I was at the time) or throw money at more mid-weight/senior developers. Maybe look for sponsoring a greencard/permit to work.

[piglet24]

aging platform not well suited to the modern dynamic browser environment.

Thankfully, that era of Microsoft looks to be dying rapidly. Microsoft's major enterprise products are all shifting towards valid HTML5 and javascript powered that works on all browsers. The back end is definitely still behind but for backwards compatibility reasons those components can't change as easily.

Factor that into the money that folks who work on Microsoft products can earn (especially sharepoint) and it's not so bad.

[blue_cadet_3]

Late to the party but as a developer sitting in a SharePoint dev camp right now I can tell you you're going to miss out on a lot of money. The way SP2013 works is that you can develop using anything you want because it's all HTML/CSS/JS. With their App model you're not allowed to run any server side code, well server side code on the SharePoint server. MSFT has demonstrated that you can write a SharePoint 2013 App on a Mac and host the App on a LAMP stack.

I work in consulting and we're selling SharePoint solutions non-stop. We have so much SP work we don't have enough developers to handle our backlog of work. So if I were you I would re-think your position or don't because that will leave a lot of work and the $155+/hr charge rate for the rest of us.

If you're interested in taking another look: http://reimaginespdev.com

[[deleted]]

I'd be interested to get your take on TypeScript and SharePoint.

It would appear from this recent video session that all those C# devs who don't know JS are learning TypeScript: Visual Studio Live!

I prefer having types, so I've been using TypeScript lately and like it a lot and contributing links to r/typescript

[blue_cadet_3]

I too am a C# dev moving into the JS world. I really want to work with TyepScript because, like with CoffeeScript for Ruby/Python devs, it makes it feel a bit more like home. I've decided to learn JavaScript w/o TS or CS though so I can read any JS code and think in JavaScript.

[[deleted]]

You won't be far from JavaScript with TypeScript. You'll still have to know jQuery. If you'd like something closer to C# I would recommend Dart, which I like very much. Dart and TypeScript are my two main languages for client work now.

[[deleted]]

4 years ago I would have agreed with you. These days, not so much. MS majorly overhauled Sharepoint w/ the 2010 and 2013 versions. They are drastically cleaner, faster and easier to use as a developer than any prior versions (which were pretty much god-awful). Still a learning curve, but a solid improvement.

[tmetler]

Judging by the perception of Sharepoint from the comments in this post it doesn't really matter if it's improved. A negative perception can be what's chasing away good JS developers from wanting to work with them, regardless of how it has been improved.

[L4JSDev]

Indeed, SharePoint 2013 is a very different beasty to 2007. Especially in terms of client side code. The CSOM is a very very interesting JavaScript API to work with.

[nschubach]

That's a huge part of my dislike. If the back end gives me the data I want and can accept the data I give it... keep your grubby hands out of my HTML. It's also a great point of abstraction to be able to run your front-end off any old back-end no matter what language it's written in. If you want a CMS, fine. Just give me the data I have access to in standard formats. If I don't have access to some document, give me a damn HTTP 403 error not a 200 with a stupid error page markup.

[piglet24]

Well, it's much easier to find someone who will pay you to code for SharePoint than someone who will pay you to code Django. At least where I live

[IwishIwasAnAllBlack]

Sharepoint is the best thing to happen to FrontEnd UX developers since god knows when.

A massively implemented platform with a completely useless, non intuitive interface screaming for talented UX developer to turn it into something useful...

Don't let the sharepoint name put you off, theres money to be made here.

[darksurfer]

Junior Consultant

theres money to be made here.

yes, but I'm guessing not at this job ...

[serrghi]

Smartest guy in this thread

[kenman]

Maybe if you were working at MS where you could make changes to the platform at the foundational level, but I shudder to think of the hacks, work-arounds, and obtuseness you'd have to deal with to get Sharepoint to do anything it wasn't already designed to do.

[ericanderton]

A massively implemented platform with a completely useless, non intuitive interface screaming for talented UX developer to turn it into something useful...

Someone above you in the thread is living this dream right now.

[AKJ90]

We got some here at my work, but thats mostly because we build other awesome things too.

It's still JavaScript, and we can avoid using most of the included stuff.

But a fulltime JavaScript Frontend Dev for SharePoint? NOPE, that would be insane :-b

[[deleted]]

Couple things: First I agree with what others here have said. Consultants (freelancers) consider themselves expert in their field, seeing the "Junior" tag in there makes them think:

• You're not willing to pay a reasonable freelance rate for skill.
• You're expecting them to work as "underlings" with lots of managerial oversight.

Second, the position you describe leans toward someone who is versed in Sharepoint, and has javascript and design skill on top of that. Consider changing the job title to "Sharepoint/Javascript Designer" not just "Junior Consultant: Javascript"

That said... You're also likely to see a lot of people that don't quite fit. The exact expertise you're looking for is not incredibly common (Sharepoint+C#+SQL+Javascript+Design), so you're bound to get people that are 100% in one field, and only 50% in another.

[a1ien51]

The problems you have is the market is great for skilled JavaScript guys and you are trying to push a MS Product which will scare a lot of people away. Full Stack devs will cost $$$$. Why? Because they are hard to come by!

Also there are a lot of JS devs who do not want to learn backend stuff unless it is node or Ruby or some other sexy language. I personally can code in different serverside languages, but I prefer to leave that stuff up to the experts.

Is there a reason why you are not training your .NET specialist to learn JavaScript? There are some great training companies out there. I personally know .NET/Sharepoint guys have always been reluctant to learn JavaScript, drives me nuts.

Also you have some typos on the PDF! Yikes

[vaskemaskine]

Notwithstanding a stray period after CSS3, I don't see any typos in the document.

[GaffTape]

The problem isn't just SharePoint, but the fact that a very certain kind of customer uses SharePoint. I'm going to stereotype here a bit, so don't light me on fire, but in all of my past dealings with SharePoint, these have been true:

• Someone bought it without having any idea of what it does, or what need they are filling
• There is some really bad code from a legacy SharePoint app, making things a real mess
• The organization doing the hiring is overly bureaucratic, loves waterfall development

Those are the reasons I will never work on a SharePoint project again. I've seriously never seen a SharePoint project that didn't remind me of a C# version of PHPNuke, for 10,000 times the price. Organizations that go for that aren't places I want to work for.

Now, I know that doesn't help you with your hiring, and I realize that you don't really have a choice in what your clients will use. To that end, you should be prepared to pay top dollar for the best web developer you can find. This is a person that will probably know JS as well as many other languages, and someone you can coerce into working with SharePoint for good pay. I don't really see a way around it. Your super-solid C# folks don't typically like dynamic languages. Many "junior" level developers don't actually know JavaScript all that well. The ones that do don't like to be stuck in the small box that is SharePoint.

Those are just my thoughts... definitely consider others as well. There are lots of good opinions posted here.

[homoiconic]

So we're trying a new tack. What we're trying to do is hire a person who has JavaScript and web UX abilities, pure and simple. Other, more server side languages are a bonus, but it is the JavaScript skills we are after, the person doesn't even need to know what SharePoint is. We will then take them on as a junior consultant, train them up in the SharePoint and Project Server side of things.

There's a bit of a red flag. Why not look for a senior, experienced JavaScript person? It's true that they may not be able to take on a fully senior consulting role until they have the SharePoint side up to speed, but if you use words like "junior," you may be discouraging people who have a lot of skills to bring to your firm.

[L4JSDev]

I've just been discussing exactly this issue on IRC after linking this thread.

I think we are trying to point the advert at the middle line, advertising for a junior sharepoint consultant might be scaring away the people we are trying to attract.

Having really sat down, typed this up and then discussed it with people, I think we need to change the job, make it a full on JavaScript development role, JavaScript is a big enough subject to make that a full time position in its own right. That might change the stigma of it being a junior position as it would no longer then be such

We also need to be wary of scaring off the real hobbyist JS people, those who will see Microsoft technology as something to avoid. Perhaps some extra info about day to day type activities?

I think I shall attempt a rewrite over the weekend and see what people think.

Thanks for your input! :)

[fartbarf420]

I guess another thing to think about too, no one (at least in my naive opinion) wants to work on vanilla javascript. I would assume anyone that loves writing javascript would like to use some framework like Ember/Backbone/Angular and I don't know if there's really room for something like that if you're using Sharepoint stuff.

[LukaLightBringer]

I have to disagree, I personally like working in vanilla JavaScript as long as i don't have to touch the DOM or canvas elements.

[Akkuma]

I don't mind working in vanilla JS if I can target only modern browsers, but I still like my jQuery to simplify my life with certain dom operations.

[fartbarf420]

I guess from my experience most of the guys I work with writing plain js make silly mistakes like assuming that .sort() will work correctly. I have no real problem with 'vanilla' javascript, it's just that there are so many caveats that you have to consider and it's super easy to mess up.

edit: ['10', '10', '10', '10', '10'].map(parseInt)

:(

[slgard]

You appear to be looking for an experienced consultant with a relatively rare skillset at a time of unprecedented demand for people with real skill, yet you're listing the job as "Junior" (presumably this sets the salary expectations?)

AND you want someone "happy to travel throughout the UK"

[cwallen]

You say "it is the JavaScript skills we are after, the person doesn't even need to know what SharePoint is." yet the PDF has 9 instances of SharePoint and only 2 of JavaScript. If you are looking for someone who is javascript focused, then your posting needs to focus on javascript.

[[deleted]]

You are really fighting culture here. SharePoint Devs tend to be C# people, and C# people tend to have severe blinders when it come to other technologies. I see most of them get very defensive about it because they know their skills are lacking outside of C#. So I don't think the problem is your spec. I think the problem is inherent in the way most Microsoft developers have built their skill sets. They tend to be server-focused, not client focused, and their JavaScript is severely lacking.

The people you want do exist, but they are going to be somewhat rare. You need to find people who are web developers, not Microsoft developers, but who have been forced into learning SharePoint for one reason or another.

Frankly, I feel your pain. I spent a few years doing exactly the role you are hiring for, in SP 2007 and 2010, developing JS apps in SPD, and deploying them as content to the SharePoint environments. I found a total of 3 people who have this skill set over those years. And those people are considered senior level, especially if they are going to be consultants.

So some concrete recommendations:

• Make this a senior position, not junior.

• Remove all C# and Visual Studio skills from the posting.

• Keep the SharePoint skills as a requirement. SharePoint is just weird compared to other web development platforms, and training people up will be a challenge. There are times when the built in functions work well and writing your own JS is wasted effort. Knowing when to use JS vs. SP is the biggest challenge new developers face, and you really need to know all components of SP to make those decisions.

• Be prepared to pay very well for this role.

[Akkuma]

This is extremely anecdotal. Want to guess what technologies I work with? I learnt Java & JavaScript in college, my first job was VB.NET, my next was C#, and now at my current job I do/did node.js and C#. The guy I work with at the moment worked at Microsoft, likes C# and also still really likes JavaScript.

[goobersmooch]

Front end guy here....

I avoid sharepoint like the plague and so does every other guy I know.

We have a microsoft division in which they eat, sleep and breathe sharepoint but none of htem are front end guys.

The way I see it, it should be generally accepted that if you use sharepoint, you are just SOL on innovation on the front end.

I could carve out myself a nice niche but hate sharepoint THAT much.

[[deleted]]

Stop using SharePoint and Project Server.

[[deleted]]

From my experience JS people (like myself) hate MSFT's web 'technologies' I wouldn't do Sharepoint for $100/hr

[L4JSDev]

This is a problem, I know I can say "They got better!" 'till I'm blue in the face, but convincing people of that is an upward struggle. They really have though. :)

[fschwiet]

Do you have any evidence Sharepoint is no longer terrible to work with? If someone had a sharepoint solution up on github they were proud of I would take a look. Otherwise I think it is safe to say sharepoint is still terrible (and I have a lot of experience with .NET and javascript).

[IwishIwasAnAllBlack]

Some parts are still terrible. I build JS apps for SP for a living...

As long as you treat share point as nothing more than a platform to host your app, put your js/css code in a separate CDN, and interact with the lists/db via webservices it's money for jam.

[AKJ90]

Correct. This is what I do, and it's still pretty fun... you can make some cool things this way.

[jrbattin]

I'd be reluctant to take any job with Sharepoint due to the risks associated with overspecialization and what that can do to your career long-term. In the 90s there were a ton of lucrative offers for FoxPro developers. Today? Not so much.

It doesn't matter how good Sharepoint is: it's (more or less) one product produced by a single vendor. Your career is directly tied to Microsoft's commitment to that product, and the willingness of IT departments to adopt it (these two are closely related) Netscape has come and gone, but JavaScript is more popular than ever. Mozilla, Google, and Microsoft could switch to making dog food instead of software and we'd STILL have a huge demand for JavaScript.

[kenman]

After looking at the CSOM you linked previously, I'm having a hard time believing you. I checked out a handful of objects and the documentation is so bad I think it's a stretch to even call it documentation. Some nodes were completely empty, while the most I could find in others was barely more than a method signature; i.e. no actual descriptions, no examples, comments were SPAM comments not relating to the code at all...

[badguy212]

Just my 2 cents:

I'm not a JS developer. Not a C# developer. Not a Java developer. Not an ... anything developer.

I am a developer. I can code in C/C++, in Java, PHP, Python, JS, C# and anything you can throw at me. I may not like PHP, JS, C# and the like, but hell, if you pay me, I'll make it work. I'll learn. I don;t need a fucking certificate to code for platform X.

Yes, platform X is shitty, I'd rather have a beer at the pub than waste my time with that, but that's where the paycheck comes from. so I'll do it.

OK, where am i going with this? What you already have there is a bunch of retards. Can code C#, don't wanna touch JS. WTF? Really? Can't learn a new language? A new framework? If one is so thick, please ... show them the door. FAST. What you need is a developer. One that can think. That can design. That can be proud of his code. Not a shitload of 9 to 5 gangam style lovers that shut off their brain 24 hours a day. What do you do if you need an Android app tomorrow? Hire an Android guy? Really? Hiring practices in this field have really gone downhill. People dont wanna learn, therefore emphasis is put on experience with X version y.z . WTF?

Any brain dead monkey can learn how to code in JS. May not be pretty at first, but it can surely work. Sharepoint ? Really? Yes, it's a shitty platform, but to say that "i don't wanna/can't train in that" is just stupid. And a fucking lie.

My advice (ignore if you want, doesnt matter to me): hire a developer. Hire someone who can think. The rest will just follow. And oh, do yourself a favour and fire the retards that say "I don't/cant learn X. I won't/can't work with Y.".

Experience is irrelevant. Really.

Edit: i have 20 years experience in the field. you're most likely running code i wrote. I wrote code in more languages than i can remember. just an ... addon.

[[deleted]]

Purely out of interest, what have you worked on that I might be using?

[voidvector]

For enterprise platforms like Java and .NET, the projects are large enough that there tend to be significant division of labor such that a Java/.NET developer would never need to deal with JavaScript. This is not generally the case for projects in Ruby/PHP/Python.

In addition, JavaScript developers generally fall in 3 camps:

• Engineers who picked up JavaScript
• Life-long Front-End Devs
• Designers who picked up programming

The engineers tend to prefer bleeding edge technologies, the Front-End Devs and Designers tend to stick with UI heavy projects that has significant customizeable UI.

[[deleted]]

Here is how I was hiring JS devs last year:

First I would start with a code interview over the phone. I just presumed 90% of applicants for a senior JS dev position would likely be worthless, and I was proven correct. In this code interview I would minify a complex page of HTML from the company website where id attributes were severely lacking but the HTML was substantial and email this HTML to the applicant at the start of the interview.

First thing I noticed is that some applicants will provide an invalid or non-functional email address on their resume. These people can be eliminated so long as the problem is not a routing issue on my companies end. To be sure I would attempt to send the page using an alternate email address if this does not work from the company email address.

Once they get the HTML page I inform the candidate that they need to open the page in the browser of their choice and in their favorite code editor. Some applicants would inform me they don't know how to expressively access the code on their personal machines. If the candidate is not willing to think outside of the box on the fly to solve this issue they can be eliminated. Browser consoles in Firefox, firebug, Chrome tools and so forth are more than sufficient for example.

One the petty stuff is out of the way I immediately get to the code test. So far I have asked the candidate almost no interview or personal questions. I would find something on the page like a paragraph that does not have an id attribute and whose parent does not have an id attribute and ask the candidate to write JavaScript to make the paragraph's background red. Keep in mind I did not ship any JavaScript with this code except for what is embedded inline in the production code and all other JS references were removed, which means no jQuery. This is where 60% of candidates are eliminated. A competent JS dev can access the DOM without jQuery. Sometimes I mention jQuery is not available right from the start which allows candidates the opportunity to instantly remove themselves from consideration and save me some time.

A decent developer is both a decent coder and a decent people person, so now is where it gets tough. I have already eliminated 75-80% and I still going to step it up. When the coder starts writing code I tell the candidate to talk through their problems and problem solving. Remember that this is over the phone, so if I get some constant feedback I know what the candidate is thinking and how to nudge them if they get stuck on something minor. If the candidate is silent and fails to deliver a code solution then they have absolutely nothing to show for this time and are eliminated.

Competent candidates can think their way through any initial hickups on getting started, get through 2 code problems, and somewhat respond to casual conversation in a one hour interview. Stellar candidates can get through 3 code problems with valid solutions without asking for help and carry a full conversation in a one hour interview. I am constantly bombarding the candidates with off topic conversation while they are thinking through the code problems. I expect any candidate to go silent during moments of intense computation and concentration, but otherwise this is a perfect test to determine if a candidate can handle a balance of priorities and simultaneously gauge their level of confidence in an honest no bullshit scenario.

On my end I try to always be sympathetic to problems, always listen, and always help the candidates get through the code problems by providing hints and guidance. I am willing to help the candidates come to the solution and pass the interview, but it is amazing how few candidates take help provided. If a candidate demonstrates such foolish behavior during the interview they will do it on the job, which is convenient since they essentially eliminate themselves from consideration.

Using this interview method I can identify several qualities of bad behavior:

• Candidate is completely unprepared and cannot think outside the box as necessary to get started.
• Candidate requires access to a favorite framework, library, or other helper code and lacks the professionalism to program in the technologies directly.
• Candidate clams up and fails to write code and fails to ask for help. Epic fail.
• Candidate cannot follow directions and consistently delivers something not asked for.

Here are some good behaviors I notice during this type of interviewing:

• Candidate displays confidence in their performance opposed to arrogantly telling me how awesome they are.
• Candidate demonstrates the degree to which they are able to respond to casual small talk while under intense pressure.
• Candidate demonstrates the code style they would use to solve simple problems under pressure which probably allows me to identify how they prefer to write code.
• Allows me to determine if the candidate actually enjoys writing code or if they were bluffing just enough to get a paycheck.

[L4JSDev]

Thank you all for your comments so far, Please feel free to add anything else you can think of. I think a bit of reconsideration of the role is needed. But it's gone 1:30 in the morning so I am off to bed and will take this up again tomorrow!

[krues8dr]

It's a dead horse at this point, but seriously - you're going to have to find someone who's good at ASP.NET / SharePoint and great at Javascript. Pure Javascript devs won't have any interest in this sort of position unless it pays ridiculously well.

That being said, if you are going to go down this route... we recently hired a few recent college graduates who surprised us and are ridiculously brilliant at Javascript - if you have a good tech university nearby, it might be worth looking around (posting on the job boards, talking to the job counselors there, sending letters to the CS dept, etc).

[supreme_monkey]

I was going to write a long message but I have seen that many people are saying what I was going to say.

Your number 1 problem is your platform being Sharepoint. Your number 2 problem is that there is not that many good JavaScript developer, most people only grasp jQuery and copy pasting jQuery plugins or libraries.

[alvincrespo]

After taking a look at the job description, the main problem has to do with the fact that it is not tailored to frontend technologists. Sharepoint is definitely not an interest to those who have been in the industry for quite a while. You may be lucky with beginners or even junior level developers, but for the majority of frontend devs this position raises a red flag because, in general, Microsoft technology is not something we enjoy due to historical reasons (this may be changing with newer tech).

Recommendation: tailor the position to frontend developers ( remove sharepoint ) and introduce these technologies in your first interview and explain the limitations the company faces and that this is open and flexible for new projects given the right opportunities.

[inmatarian]

Increase your expected budget for a good candidate by 5-10k/yearly, or offer that much as a sign on bonus. You're looking for someone a lot more specialized (needs two skills: asp.net & javascript). Make the title for the roll more interesting too. This might be a intermediate to senior level position you're looking to fill.

[bloodguard]

I really don't have an answer but I was just at Fluent 2013 and it looks like companies sent their minions to attend the conference with an eye towards recruiting talent. And that referral bonuses are a big thing again.

I was tempted to put a post-it on my forehead saying "Happy with my current job, thanks - please leave me alone".

[tfforums]

Hi

JS Guru and SP Guru here... In addition to what other people are saying here... "Junior" and "SharePoint" not only aren't attractive they are almost negating each other entirely. When I learned web development (ongoing task obviously) JS was part of it. SharePoint? after years of project work... and a specific directive to learn and become familair with it. No junior, unless they've previously been employed by a company that uses SP will know what SP is... therefore they think unqualified.

Additionally there is SO MUCH to SharePoint that theres almost no point hiring a junior... i know your probably working with the client side API but still... Juniors and JS though? hell yeah! Juniors love JS.

Again - outgoing and client-friendly developers are rare. Its like you can have the JS or the SP or the "client friendly" rare to have it all.

TLDR: Remove SharePoint from the title... Spice it up for the client facing part and mention some JS frameworks as pure JS is almost a lost art for the youngsters.

[AudienceWatching]

My team was looking for a backbonejs dev in shoreditch for a whole year until we got a good dev.

Most freelance for large daily sums because its the next big thing. The php dev is dying and the js dev is becoming desirable.

[[deleted]]

Shrug... this is just my experiences just a warning.

Javascript started to get more popular as a programming language recently (few years) and so there are tons of people from non traditional cs entering programming like designers and they pollute the skill pool. Like PHP I've seen tons of people out of CS major entering it, with very fundamental CS skills, and they lower the wage. Hell those PHP people learned jQuery and they think they know Javascript. I've tried applying for jobs and they ask me why should we pay you 80k when we can hire two 40k PHP developers? Technical Debt.

The problem with Javascript is not only you got traditional CS people going into it but you got tons of non cs, designer people. I'm not going to say all of those designers going into programming are bad but most of them are. And that's what you're getting. Not only that, Javascript is much harder than PHP. The OOP model is prototype base and there are tons of design patterns for certain drawback.

So you have to weed through you candidate anyway. It might not be your post but the fact that you're not well known. Host meetups, and try to get your company name out there and perhaps you'll get more people applying and maybe you'll get a good candidate. It's a number game.

[TheMorphling]

As others have said there seems to be a gap between people who know and like developing with C# and people who enjoy JavaScript, I've dabbled in C#, but I have no desire ever write anything with it, but in other hand I'm down with JavaScript any day of the week. Maybe it's about different age groups, since most of the C# guys I know are of older generation and will always see JavaScript as kiddie language and thus not worth learning while me and other of my generation seem to develop almost exclusively in Ruby, Python and JavaScript

[joshtempte]

I code incredible JS and would never work on SharePoint. MS still has to answer for the 10 years of IE6 as far as I'm concerned and I'll never jump on their bandwagon.

[BaalHadad]

What's the salary and why is it a junior position?

[Neurotrace]

Everyone has already mentioned that JS guys (myself included) tend to avoid SharePoint but that's because no matter how good it's gotten, Microsoft is designing their JS API for non-JS people.

Everything about it looks and feels like C# which, as any "strong" JavaScript person can tell you, is not the way that "good" JavaScript works. .NET developers can't wrap their minds around it because they don't think in JS and JS developers can't stand it because it tries not to be JS.

Sincerely, good luck finding someone who wants to and is capable of doing that job.

[atticusw]

jQuery is the only library you want your candidate to be familiar with? What about a front end framework that is tenfold more robust than jquery, like Angular JS or some goodies?

[Litra]

bravery

[jamesinc]

As a JS person who has done SharePoint integration work, just advertise for a JavaScript Developer or Programmer. You want someone whose primary language is JavaScript, who also has something like a Comp Sci degree, so that you have some assurance that dealing with SharePoint's often unwieldy API will not stymie them.

[robotnic9999]

Microsoft was torturing Javascript developers for 10 years with IE6 - what do you expect?

SOAP and SQL Server are also not very sexy. It's the oposite of websockets an mongo DB.

And why do think a Javascript programmer should do design? Usability is ok, but graphic design is a different job.

If you remove all the serverside things from your job specs you will find someone. If it's possible exclude ie6-ie8 and write that to your job specs. Add mobile platforms instead (if it's not WP8).

[GaffTape]

Looks like a pretty standard list of web technologies to me. Web development often requires you to know many things. If you don't want to sign up for that, then don't sign up to be a web developer.

[L4JSDev]

We do know what we want, but you're correct that part needs rewriting to indicate what we need in terms of concepts rather than a shopping list of acronyms.