What I think in such cases is "unless I can convince him that this is a bad idea, then I should let him do it". Yes, I understand that sometimes we aren't entirely sure why a thing is bad, we just have a gut feeling that it would break something, or is a bad practice.
So first off I try to convince them with everything I got. That usually works if I have solid concrete reasons. If I don't and let them do it there way. Sometimes it turns out my instincts were right and I get to learn exactly what was right about them. Sometimes it turns out I was wrong and his way was much more efficient and I get to learn something new.
Either way, it doesn't make the junior dev feel I am imposing my will on him. People tend to work harder when they feel it was their idea.
When I was a junior dev (and some days I still feel like that), sometimes I needed to write a proof of concept to see why something wouldn't work. Luckily this kind of development (at least in the early stages of a project) was encouraged. I still throw together small scripts and apps to test ideas all the time (http://github.com/voltagex/junkcode)
I would assume most devs do the same all the time to benchmark technologies or approaches to problems.
(Then again I seem to meet far more devs who are telling me about using shiny new tech X and how amazing it is, than ones who actually tell me about how a specific tech solves their use case).
But about as annoying as senior devs who give bad advice or ignore half the words in your sentences and then give you bad advice, or who start giving you bad advice during a planning meeting after a 30 second brief about your problem that was directed to your manager.
And they prefer using uncool tools intelligently to solve a complex problem; rather than using the next cool thing dumbly that creates more problems than it solves.
And sometimes they are unbelievably set in their ways, for example using procedural code ( STATIC ALL THE THINGS! ) in Object Oriented languages like Java.
And that's the rub. When you are hiring experienced devs, are you getting Mr I-use-staticz or are you getting Ms Let's-use-boring-tech-because-it-works?
Sounds like a bunch of C# devs who didn't know Powershell and couldn't be arsed to learn it. Even though it has similar syntax. To some developers every problem requires the only hammer they have.
Must have been really bad. Why not just hire you on as a consultant?
I'm not fantastic with Powershell but there's another potential reason: you're not allowed to run "random" exe files on $SERVER but (signed) Powershell scripts are fine.
I'm not sure where the cutoff point is between this needs to be an app / this can stay as a script, but Powershell seems to lend itself to going either way. I can either incrementally replace C# functions with Powershell (while importing types and functions that I need) or incrementally replace Powershell with C# with the same method.
> Sometimes people don’t agree (e.g., it took months to get the non-version-control-using-team to use version control)
There's an easy way to stop that sort of attitude. The next time that a bug occurs, you tell that team that they must restore the code back to what it was previously, and provide diffs that show what they did so that you can review their rollback.
When they say they can't, you tell them that's their problem as they haven't implemented version control because they believed they didn't need it, and they need to go do it anyway. After they go through this exercise, you then offer to help them to implement version control.
That's not actually going to achieve anything other than making an already stressed team more stressed with a side of hatred for you and your pointless request.
In this day and age I'm not sure how you do persuade a team to use version control other than mandating it and sucking up the hostility while they settle in, but taking the opportunity to make a smug point while a team is firefighting isn't the way.
Oh yes, truly pointless. Much like their insistence that they can get by without version control really. The team has already pushed back on something that no professional software development team can get by without, and even the most amateur of software projects use. I mean, you need to ask yourself why they are so stressed and you know they aren't using version control?!? Cry me a river!
If you have a resume you're not "trendy". You're "trendy" if you have a github account full of projects in Go and Node-y stuff, a twitter-stream with a few thousand followers, some medium rants and (maybe) a linked-in profile.
my impression has been that node.js reached the top of its hip curve a few years ago, same with golang. not that they're disused, they're just not obsessive-compulsive topics. this is mostly based on what i (don't) see and hear at work and here.
again, based on what i see on hn, github is actually falling out of favor (we'll see if they can reverse the trend [sic] with the newly released features; the search removal inspires little confidence).
twitter has been around for too long to be trending upwards, it's like facebook. the populace split into users and abstinents has ossified. it's even more pronounced with linkedin which has been around much longer.
i have no idea what's supposed to be trending in programming instead though. recently it's felt to me like a plateau of sorts.
Unless you are specifically looking for social media skills, it can be a mistake to hire engineers based on social media presence. People who are good at self-promotion often play poorly in teams. Just sayin'...
The abundance and heterogeneity of various technology stacks, frameworks, methodologies and whatnot fuels this hiring mess. Twenty-five years ago, nearly everyone who called himself a programmer knew C and an interviewer could judge the relative strength of two candidates by really examining their programming skills and not some trendy keywords.
This sounds like a falsehood, brought about by the belief that the past was somehow simpler, because the relics from the past that survive into the modern day are few in number.
I doubt that everyone knew C. Lots of big firms extensively used COBOL. Fortran was important in science/numerical computing. Pascal was popular. The list goes on.
Need I mention that for decades, there were lots of competing assembly languages, and that only in recent years we've converged on three? That Harvard Architecture and Von Neumann Architecture competed into the late 70s? That compiling a program on a machine with particular hardware could be seriously difficult? The conflict between big-endian and little-endian systems? Computing has always been full of heterogenous, competing technology stacks, frameworks, methodologies, etc. Why? https://xkcd.com/927/
And in the 90s in particular: do you really think that designing software for this so-called "internet" and newfangled HTML and JavaScript was free of trendy keywords?
Indeed there were lots of competing standards and technologies, but C was still the kind of "lingua franca" among most (professional?) programmers. Many people used to write really intricate programs in it without relying on anything but standard library functions. It was about raw talent and people used to take pride in the way a program was written and not just what its effect is.
And yes, it all started to change in the mid 90's with the advent of Windows and the web.
I started programming professionally about 25 years ago, and it was exactly the same. Windows was rolling out into the office spaces, replacing old mainframe line-of-business apps.
MS Visual Basic was the new hot thing on the block. Delphi was the same thing but in Pascal. There were a bunch of database-with-front-ends like FoxPro and Access that you could build a windows program with pretty easily.
Actually, C occupied pretty much the same space as it does now: there's some people using it for serious stuff at serious companies, but it's not RAD so no-one else is interested.
It's overly simplified, like "in 2010's nearly everyone who called himself a programmer knew JavaScript". From what I remember software stacks were far from simpler and standardised, between Mac toolbox, 68k assembler, x86 assembler, Object Pascal, DOS, Windows, MFC, VCL, OS/2, AppleTalk, IPX, NetBIOS, OpenDoc...
A very large number of software developers today don't actually write much new code. The job is more about wiring up libraries, frameworks and APIs rather than designing and implementing new things. Consequently you need more organisation and focus than "real" programming skills like math or logic.
I think it is fairly common these days to allow the candidate use any language he or she finds convenient. But now there is another problem! Twenty five years ago everyone who called himself a programmer could do algorithmic stuff. And now there is a growing cohort of "programmers" who proclaim that they are above it and instead take pride in their masterful ability to call APIs.
Is the anti windows/.NET bias really that common? I have been a .NET dev for 6 years because that was my job. But I don`t believe that makes me useless on any other stack. In fact lately I desire to work on something that feels exciting and fresh again but sometimes I feel like .NET devs are looked down upon and it`s not so easy to land a job or contract outside .Net land.
I wouldn't say it's an "Anti .NET" bias, as much as it's an "anti too many years in the same exact thing" bias.
1. Choose a different language for your next side project.
2. Step in the door with C#, try to help out on projects or change positions inside the company.
3. Attend hackathons, contribute to opensource projects.
A good programmer can quickly feel comfortable in any programming language. Recruiters feel more comfortable when you can actually show proof of that.
I have side projects in JS and TS (Node.js), Python, C (~500 loc projects). Mostly I care about solving a specific problem. Learning a new stack just so I can put it on my resume would require time I don`t have :(.
> A good programmer can quickly feel comfortable in any programming language.
This is not true. It takes a not-insignificant amount of time to just learn to write idiomatic code, let alone making oneself familiar with all the quirks and idiosyncrasies of libraries and frameworks.
Additionally if it's your first exposure to a non-Algol language, you're going to have a hard time... you definitely won't feel comfortable quickly. But at least going from, say, Java to Python, you can quickly feel fairly comfortable writing Python code just like you would Java! (Your coworkers who understand "Pythonic" might hate you though.)
If you don't have 3-5 years experience in language/framework X, no jobs in language/framework X will be forthcoming. People hire based on what you know, not your ability to learn. A new hire who can "hit the ground running" is an asset; one who can't is a liability.
My first company (as a non-programmer) was very much like this. It was very corporate and they weren't willing to take a risk on cross training a hobbyist without the requisite boxes checked on a resume. It was frustrating but I also understand the CYA logic behind it.
There's someone willing to take a risk on you somewhere for some amount of money. Having a github with noob code in the language you are trying to get hired for helps. If you are just starting out, being able to show you want it bad enough to learn it off the clock is a strong signal vs "I'll start learning it if you start paying me" (which is...also a signal).
I don't mean to be hurtful, but you sound like you've exactly the same biases the original post is about, and you're rationalizing. Seriously, not all good hackers fit any cookie-cutter definition of a hacker.
I think why .NET is looked down upon is because many have severe lack of experience with .NET. I too have made assumptions of .NET because of my experience was only webforms in a small course at my university.
Ironically, I have recently started using .NET MVC for my projects since I think it's really great. It beats many alternative MVC-frameworks in my opinion.
The wast majority of people, who claim .NET experience can launch Visual Studio, then some wizards to generate skeleton of the app and then fill something to have a CRUD "solution".
They spoil it for the folks, who are truly experienced. The claims in the CVs are so maximized (Dunning-Kruger at the extreme), that it's simpler to just ignore .NET experience.
"The wast majority of people, who claim .NET experience can launch Visual Studio, then some wizards to generate skeleton of the app" -
This is the ignorance. There are people who are pretty bad on other stacks as well. I know many competent .NET developers. And many terrible PHP developers.
On average the average .NET developer is more skilled then your average Python developer. This has about as much substance as your claim.
I think most startups I've seen are using some form of POSIX back end. I've been advising corporate techs with only .NET experience to start learning some bash at least.
I moved from commercial .NET coding to startup-land a few years ago, and there's definitely a learning curve. I had to ditch Windows on my personal PC and start using Linux at home to really get the hang of it. YMMV.
Funny to read, because I have the reverse experience. I have for long been using Linux and classic open source tooling for my work and am now moving to use Windows and .NET.
I have immense issues understanding the platform and how everything work. For example, scheduling jobs is something I still don't fully understand.
However, I still use the terminal by using ConEMU with Git Bash to get git in the terminal because I don't know how else to do it. But you mention bash and awk, I have never in my years of experience really used these tools a lot either.
Maybe some small bash-script to backup or something similar, but nothing else really. You don't have to use it and most of the times it's easier to write a python script or what not.
I haven't really bothered to learn any PowerShell except "Update-Database" in the Package Manager Console.
DLL Hell could have got a lot better since I last had to deal with it. I occasionally bump into a dependency problem with Ruby gems that reminds me of it.
I don't use bash a lot, but there is an expectation in Linux-land that everyone has some familiarity with it. That's not true in the Windows world so much. In my experience anyway. I'd be interested to see if a much more functional shell environment generates more use of it.
> The mess of terminal windows and text editors that I code in now is frustrating at times.
Just use emacs for everything! It runs in X, it runs in a TTY, it runs everywhere.
My own stack is st[1], tmux & emacs, with Firefox as my browser, within a tiling window manager. I have a single terminal open at any point in time, with tmux multiplexing the sessions. I use C-z as the tmux escape key, because it's easy to type and doesn't do any harm if I accidentally type it outside of tmux. I autostart emacs in server mode from a systemd unit[2] and run it under X.
Sometimes I use emacs's TTY or shell modes. This is something I'd like to explore more. If I did this, I might be able to have one window for both shells and text editing.
Regardless, I have one terminal window to rule them all and one editor window to rule them all. With Firefox tabs, I only need one web-browser window too (although I'm considering using emacs-w3m and/or eww more).
>Sometimes I use emacs's TTY or shell modes. This is something I'd like to explore more. If I did this, I might be able to have one window for both shells and text editing.
> I think most startups I've seen are using some form of POSIX back end.
Typical hip startups use "tools" (frameworks, libraries, etc.) that abstract underlying platform to such an obscene degree, that it doesn't really matter, if the platform is POSIX-compatible or not.
On the contrary, when these tools invariably break, knowing your way around POSIX environment is indispensable. Something as simple as invoking strace on a binary to find out where this damn thing looks for files it needs can save you hours.
>Is the anti windows/.NET bias really that common? ... I feel like .NET devs are looked down upon
I don't have evidence of a wide random sampling of "trendy" employers but based on anecdotes[1][2], I think it is.
Many trendy companies (a.k.a. "hot startups") overwhelmingly favor a Linux + open source stack. If the hiring managers at these companies see a resume with just ".NET/Winforms/WPF/ASP.NET", they perceive a negative signal.
Yes, writing a loop to display a list in ASP.NET should be Turing equivalent to writing a loop in Node.js/Golang but people don't think purely on equivalences of computer science concepts. They also think about "culture" and a resume that's exclusively ".NET" looks "corporate" and "enterprisey" instead of "cutting edge" and "hip".
My advice to potential job seekers who only have "MS .NET platform" as a skill: start a github profile with projects using Linux/Node/Golang/etc to help counteract the adverse cultural selection bias.
[2]"And the .NET developers are mostly enterprise folks who don’t like working in rough-and-tumble startup world. Remember, I worked at Visual Studio magazine and had a front-row seat." from http://scobleizer.com/myspaces-death-spiral-due-to-bets-on-l...
It's not just cultural. Writing idiomatic C# does not mean you'll write idiomatic Javascript. Nor does it mean you'll write idiomatic Python.
Being in the .NET ecosystem exclusively can also mean a reliance on IDEs and .NET-specific tooling to be productive (or things like Eclipse refactoring for Java).
And there's the simple fact that there are a lot of qualified candidates who do more than just .NET/just Java. Polyglot programmers are more likely to be flexible and be in the right environment.
Of course people can be good enough, but it's not just about the looks. Things happen differently depending on the tooling.
Now, the extended part of this discussion is that maybe it's fine, and companies should be able to onboard people into a technology. Because, hey, it's just programming right? But that could mean looking at a multi-month training session until you're looking at someone as productive as the guy who's familiar with the tech already. Not all experience in programming is equivalent.
An aside: I feel like this discussion usually has a lot of "web programming is easy" undertones (it hasn't been explicit but we all know what "trendy" means). But I don't think there would be as much of this discussion if it were something like "web-only developer applies to work on embedded systems with basically no C experience".
"Programmers who used Java or C# (when interviewing with us) go on to pass interviews with companies at half the rate of programmers who use Ruby or JavaScript. (The C# pass rate is actually much lower than the Java pass rate, but the C# numbers are not yet significant by themselves.)"
I think that depends on where you live really. In the area I'm in being a .NET developer is clearly an advantage.
One reason I, and others like me have looked down on .NET developers, is that a large number of them aren't any good. I've meet brilliant .NET developer, some of the most talented developers I know are .NET developers, but the crappiest developers I know are .NET developers as well.
Some developers are completely ignorant in respect to computers, the Internet, algorithms and new technology in general, and they are almost exclusively working on Windows and by extension .NET. These are developers that can make code work, but take Visual Studio away from them and they cease to be developers.
It's by no means fair, because as I said, some of the best developers I know are .NET developers. It's just that I've never see anyone working on Linux/Unix be completely ignorant other languages, tools and platforms.
> These are developers that can make code work, but take Visual Studio away from them and they cease to be developers.
Ha, during my brief stint at a windows-shop after graduating, I did meet a few who couldn't get their heads around the concept of having a build happen without someone clicking a green triangle button in VS.
It probably varies by geography, but the .Net scene I was in really didn't have a bias toward CI at all (or testing, or almost any decent development practices).
I wont argue about it, our experiences differ, and that's cool :)
There is nothing inherent about the .Net stack that makes it biased or preferential-towards CI. Other than the fact that you can "do it" in a CI context, I can't think of anything else. Care to enlighten me?
Bear in mind, a lot of .Net developers don't even know it's possible to compile their projects outside of Visual Studio. Msbuild, Nant, csc.exe, "what are those?"
The standard for .NET shops is TFS. When you create a TFS project you setup CI and automated builds.
"Bear in mind, a lot of .Net developers don't even know it's possible to compile their projects outside of Visual Studio. Msbuild, Nant, csc.exe, "what are those?" There's probably plenty of java developers like that as well.
I've never seen Team Foundation Server in a .NET shop. It's either been SVN, Git or Perforce. That being said I think it's very individual, but many small companies won't pay for TFS, they barely want to pay for Visual Studio Professional/Enterprise edition
Those sorts of developers exist on every platform. The trendy platforms are simply too new for non-adaptable developers to have yet made themselves visible.
Replace .NET with Java and Visual Studio with IDEA/Eclipse and you'd probably be right again with the same post. It's not really a .NET problem, more like a bell curve and popularity problem.
I struggle to understand, from a practical standpoint, where it comes from. The performance of ASP.Net is becoming outright ludicrous[1]. I've personally rewritten a lot of C++/CLR to C# and we've seen performance gains over 20% each time. C# is a language that hasn't gone stagnant, regular iterations on the language are made to meet real-world demands.
Now that the OS is no longer an issue, why isn't C# seeing more startup usage? Just look what StackOverflow does with it.[2] Startups shouldn't be judging developers for knowing it, they should be looking at it themselves.
The problem is that with .Net experience comes a very big reluctance to "re-use" existing, open-source libraries. I've seen it first-hand, devs that "only" know the .Net stack. You come at them with any solution that involves "free" due to a library/project being open-source, and their brains nearly explode (bit of hyperbole, there).
Really? Everyone I know in the .Net world is busily building upon open source libraries via Nuget, which is an NPM equivalent. Most of that open source code is hosted on Github.
Now .Net is now also open source it would seem that the only proprietary part to the stack is Windows itself, and shortly .Net is going to be running on any platform.
In my experience, trying to get people to use NuGet is like pulling teeth. When OSS dependencies are considered cromulent, vendoring, sometimes just straight-up binary vendoring, has been my experience with .NET shops. Those are the above-average places, though--I've seen a ton of reticence around using anything with an OSS license.
Coming from a Mono background, this was very weird to me.
> I've seen a ton of reticence around using anything with an OSS license.
Very true. This used to be a point of contention where I work, but was easily fixed by having an automated process for getting our lawyers to approve OSS code (with a Nuget or Github URL). We still have to do it on a per-project basis (not per-license), but we're using lots of OSS code now and I've made a little headway on open-sourcing some of our own stuff.
These days OSS advocacy isn't that hard, especially with the hard facts demonstrated by CoreCLR.
And that reluctance comes from being mentored by senior software engineers who have been burned by using the latest shiny, and appropriately mentor the junior developers against using the latest shiny. We .Net developers build mission-critial enterprise apps using only the .Net stack, and most senior .Net devs would applaud one in doing so. Now I'll admit that the .Net stack is a moving target. But I'd rather have one commercially supported moving target than a dozen OSS moving targets. No rational person likes having their head explode. Being "free" has nothing to do with it.
Bias towards Windows is an interesting one. As someone who programmed on Windows for 9 years, I got away with writing code in IDEs and since most apps had GUI and command line was less than worthless, I was never exposed to simple tools that could be chained together under a minute that one had to spend hours either writing, or looking for a software that did the same in Windows.
It wasn't until I started college, where I had to use Linux to get my assignments done, etc. that my mind got stretched open. In three months I couldn't believe I survived in Windows for that long.
As an employer, the fact that someone has only ever developed in Windows and also uses Windows at home, tells me that at best they can appreciate unix and unix philosophy, but that it's unlikely they could build tools that do the right thing and play well in a unix environment, no matter how many years of experience they've had building tools.
But not only that, unix goes deeper and teaches you about how to do things inside your program, even if that part never talks to other programs. Things like do the dumb thing first; or when you have nothing to say, say nothing (e.g. `ls` prints nothing if no files found), etc. It's about mindset and values and those are almost always dictated by the environment. Also values cannot be looked up on stackoverflow and copy/pasted in 5 minutes. They take a long time to sink in and I can understand why an employer would want to skip that cost when hiring.
I second that. When I was a student, I use MS stack a lot and sweared by it, but never really got to use the command line, since everything could be done faster using the GUI, and the command line had no benefits I could possibly see at the time.
I had to really use it when I started to do automated builds, and since then it opened my mind on the value of command line and above all the unix philosophy, which I really consider as super important now.
If I had to hire, I'd be relunctant to hire someone with Windows-only experience, not because I think the stack is bad, but because it's unlikely this person adhere to the Unix philosophy and is able to write scripts for small tasks, and automate important tasks with scripts.
> But not only that, unix goes deeper and teaches you about how to do things inside your program, even if that part never talks to other programs. Things like do the dumb thing first; or when you have nothing to say, say nothing (e.g. `ls` prints nothing if no files found), etc. It's about mindset and values and those are almost always dictated by the environment. Also values cannot be looked up on stackoverflow and copy/pasted in 5 minutes. They take a long time to sink in and I can understand why an employer would want to skip that cost when hiring.
"Unix culture values code which is useful to other programmers, while Windows culture values code which is useful to non-programmers." (really: read the whole article!)
It's not that unix folks don't appreciate it, but that it's not clear what to appreciate. From solely a personal standpoint, years of both using and programming on Windows taught me nothing about its values. However, I can talk about Apple and its values for hours and I've never owned anything Apple except its keyboard.
Joel, the author of the article you linked to, states the core value of Windows as being "useful to non-programmers" basing it on "By contrast, Windows was created with one goal only: to sell as many copies as conceivable at a profit". The former does not follow from the latter.
Microsoft didn't need to rely on usefulness to anyone to sell many copies, and they didn't. As for why Linux isn't non-programmer friendly, I beg to differ. Android is a prime example and the argument as to why it's not doing well on desktop, as Linus Torvalds puts it, is because no one ships Linux on their desktops. Microsoft has a lot to do with that. When and if they ever do, Aunt Marge will be as happy using Linux without even knowing it's Linux (does the average non-programmer know that Android is Linux?)
"1. Make sure the printer is turned on.
2. Connect the printer to your system...
3. A message will appear when the system is finished installing the printer..."
I'd say on the contrary, Android shows what it takes to make Linux do well with the general public - a huge company to ignore like 80% of the standard Linux install and build a whole new UI layer from scratch that is designed to appeal to end users.
As with much of Spolsky's writing, it's a really fun piece to read, and thought-provoking too. But I think the bigger distinction between Unix and Windows is not differential valuation of programmers and non-programmers: it's believing that non-programmers exist or not. From the Unix perspective, everyone is a programmer, and that is appropriate: anyone is capable of directing a computer to achieve tasks. From the Windows perspective, programmers are wizards who deliver things to end-users (and there are higher programmers who deliver things to lesser programmers as well, which is why proprietary software is okay).
I'm pretty firmly in the Unix camp on this. 'I can't program' should be as rare as 'I can't read.'
Programming exists so most people don't need to program - in the same way that other professions exist so most people don't need to become experts in medicine, law, engineering, building trades, or car maintenance.
What makes programming so special that it needs to be different here?
> Programming exists so most people don't need to program - in the same way that other professions exist so most people don't need to become experts in medicine, law, engineering, building trades, or car maintenance.
You might as well write, 'reading exists so most people don't need to read,' which would be equivalently true.
> What makes programming so special that it needs to be different here?
Because directing computers to perform work is as fundamental a skill in the modern world as is reading. Yes, there are people nowadays who cannot read, and there are some few jobs for them. But there aren't many, and it's not a good place to be.
Programming is not a specialised skill: it is a general skill with applicability in almost every field of human endeavour.
If anything, using a non-windows OS teaches you about being able to even "navigate" a command-line, or understand basic concepts such as file-paths. Such as "../" or relative vs absolute paths, what "/" means, etc. I'm amazed at how often such things are missed and never understood, even by individuals who are in the "maintenance" side of IT and have bazillions of "certs" for everything from networking to administration.
"Windows greybeards" who originally came from DOS also know the whole thing about navigation etc. I admit that for a long time (before Powershell was introduced) the default shells of GNU/Linux were far better than cmd.exe of Windows NT (not even to speak of command.com of Windows 9x). Whether with Powershell this is still the case or not is yours to decide.
The old perception of .NET devs is that they're provincial in their approach to tech outside of Microsoft. Stacks are always top to bottom straight from MSDN or P&P: jQuery, razor, ASP.NET MVC, WCF, EF, MSSQL, TFS. Part of this is MS fault: the silver/gold partner licenses provide financial incentive for businesses to stay in the fold by being MS stack proficient. I've seen Biztalk shoe-horned into a product mostly because it was included in the quarterly MSDN mailout CD package and hey, it's free!
To some degree, it's true. Many of my colleagues never touched node.js til Microsoft started using it. Or Linux til Azure supported it. Or functional programming til F#, or git etc.
Java developers seem more comfortable searching online and piecing together a solution from oracle, apache common, other 3rd parties. It feels like they're better at critically inspecting packages for performance, applicability, adoption since they don't have a mother corp creating or blessing every product. nuget has helped a lot of .NET devs come out of their cave and explore the great unknown that is open source.
Hopefully Microsoft's recent reinvention of itself changes both this perception of .NET devs and whatever reality is behind it.
> Many of my colleagues never touched node.js til Microsoft started using it.
Couldn't there also be the reason that before Microsoft started to become active in Node.js the Windows support for it was really bad (bad Windows support is a typical problem of lots of open source projects; I mean: I could understand it if OS X (at least the same degree proprietary) support were similarly bad, but this is usually not the case).
Node is very attractive for a variety of reasons, and TypeScript complements it like hand in glove (which is completely intentional, kudos to MS on that part).
Transitioning to Node+TS from .Net is fairly straightforward (setting aside the completely new tooling, building, open source package resources, etc), and you get microservices + much better performance with minimal friction.
Granted, large-scale systems of the Node variety are a world's difference from .Net, but that is not insurmountable.
The appeal is more than simply improving compatibility -- the whole microservices movement had been happening beneath Microsoft's noses, and this is their response to it. It is nothing short of impressive how they have expanded the .Net stack in order to remain current.
Ex Amazon here. I've done a lot of interviews and I've never seen candidates being refused an on-site interview for having extensive Windows experience.
Still, the hire rate would be really low. Most would have little knowledge of what exists outside of an IDE: OS internals, system design, networking.
14 years .NET developer here. Oh, I regularly am involved in LAMP and other uncool stacks, but I'm still labeled .NET developer.
After all these years, I still am mystified by the whole technology/stack religion that pervades software engineering. I come from a mechanical engineering background. There's many ideologies on how to solve mechanical problems, but I would never hear "oh I see you have AutoCAD on your resume...we are looking for more of a life-cycle-engineering type of engineer" during an interview. A discussion like that would not even make sense.
The whole .NET/LAMP/XAMPP/GemStone/whatever solution stack you use does not define who you are.
I still consider myself a Mechanical Engineer who happens to be in the software engineering field who happens to choose .NET to solve problems since I'm highly productive on that platform.
> Is the anti windows/.NET bias really that common?
I think it's less common now than it used to be but back in their heyday Java devs looked down hard on .NET devs. I think it's because MS visual IDEs, going all the way back to vb6, made a lot of people think they were professional developers just because they could create a basic crud program with a functional GUI very easily. This ended up promoting a huge amount of unusually bad code/coders to production environments and with that the bad rap .NET devs get to this day. The perception is that developers outside of the MS ecosystem usually have to be a little bit more erudite in the way they went about learning their programming language of choice.
I've strangely also found that this works the other way as well.
I have strong experience in the .NET ecosystem and good experience with nix platforms and commonly related technologies (including Java and Ruby). When I interviewed for a part time freelance gig with a company on Upwork, they were concerned about my nix experience. They wanted to make sure that since they were a .NET shop, that I wouldn't try to get them to use any non traditional Windows based technologies.
I told them that I'm not partial one way or the other - I just like to use the best tool for the job regardless of where it's hosted. I did end up working for them for a short period of time, but it didn't work out long term.
I find that "how can he improve?" is probably a much better question than "Why don't you want him"?
Ask the first - and you'll get real actionable items to improve on.
Ask the second - and you'll get the recruiters equivalent of "you're cute, but I already have an imaginary boyfriend".
While a company might pride itself in hiring generalists and "we do a bit of everything", very often they're just looking for someone to fill a specific position for a very specific need.
Those needs might change in 3 months, (and then they'll be glad you're a generalist), but they're hiring someone to fill the gap NOW.
This is especially true for startups, who have limited funding, believe in "move fast" mantras, are afraid of hiring someone that might need to be fired, and are afraid to take time for ramp up.
> While a company might pride itself in hiring generalists and "we do a bit of everything", very often they're just looking for someone to fill a specific position for a very specific need. Those needs might change in 3 months, (and then they'll be glad you're a generalist), but they're hiring someone to fill the gap NOW.
So in other words: The startups present plain lies in their job requirements and complain that the people that submit an application don't fit what they really want.
IMHO the easiest solution would simply to be honest...
"Wall of text" is usually reserved for people who don't use paragraph breaks; such a complaint is unfair on a perfectly well-formatted page. If you want it narrower, maybe make your window smaller?
IMO, it's almost impossible to stay focused when the text is poorly formatted as it was in this article. With just a couple of lines of CSS the readability would increase tenfolds.
I shouldn't have to make the window smaller in order to be able to read the authors post. If people find the formatting too frustrating, it's their problem as they want to convey a message to me, not the other way around.
>...the TLDR seems to be not to hire based of trendy skills,
No, the essay is not about skills but about trendy pedigree. The examples of "pedigree" being defined by being at trendy company such as Google/Facebook/Apple instead of a stodgy one like Microsoft. Or the "pedigree" is graduate of top-10 university instead of a 2nd-tier one.
One possible solution to outsmart the flawed thinking about pedigree is a "Moneyball" approach that ignores schools or past employers.
Then don't work at those companies. It seems there's always .NET jobs - I get recruiters all the time bugging me about those gigs, but I get nothing on any of the other languages I've worked with (and the .NET work I've done is a very small % of my career). Perhaps it's a location thing - Houston is definitely a .NET town.
Some areas are location specific. Richmond VA seems to be a .NET and Java town mostly. My team's stack is Apache httpd PHP and Java mostly on Linux. A little scripting in Python and bash.
It would be cool to have a map showing what stack/language is most marketable in what area, so that one can adjust time spent on learning new tools depending on where they want to go. But maybe these things evolve faster than the time scale involved in getting enough experience to be attractive for employers.
And the San Francisco Bay area is _not_. That's been frustrating. Fortunately, I had a lot of PHP in the past so that helped me find a place when I decided to roll the dice and leave Texas.
Now back to scraping up some Python and coming up with a good project to throw on GitHub to show "Yes, I are engineer. Here is me saying 'shibboleth'."
I sometimes think there's a built in pomposity in the whole attitude of hiring, looking for someone "good enough to qualify." Instead, I like to think of it as, we are looking for someone to help us, someone who has different experience and knowledge, someone who could tell us how we can improve. Then instead of this adversarial situation of selecting a new ingroup member, it's a solicitation for assistance with a built in humility.
Appreciate the humanization of both job candidates and employers inherent in the shift you advocate.
I have done a bit of hiring and it was very hard to walk the line between effective use of my time and being open to people with all kinds of experience. (It was a junior position and I talked to some very junior candidates.)
But it is always important to remember that there is a human being on both sides of the table.
Could you expand on how you ended up walking that line? Did you feel you wasted your time on under-qualified people? Did you end up hiring anyone who initially didn't seem like a textbook candidate? If so, how did they turn out?
The reason I ask is that I've always been nervous about applying for jobs when I don't have every skill listed on the ad.
The advice I've been given is usually something like "Apply anyway. The job advert is a wish list, not a minimum."
But I'm still terrified of an interviewer opening my CV and asking how the hell I slipped through the screening process. Or even worse, being too polite to be so blunt and awkwardly going through the motions of an interview.
It would be awesome to get the perspective of an interviewer.
I interview tons of candidates. The resume tells me nearly nothing, just what you've worked on before. Not how much, out how well that went. So in terms of some "textbook" model fit, the question is a little silly.
Generally few people are really good. And their spread out unpredictably across the landscape, so you have to just interview lots of people to find them.
I definitely wasted time interviewing underqualified people. But I wasted time interviewing some overqualified people too (because of salary/location expectations that should have been communicated up front). Actually, all of interviewing feels like wasted time (you have this burning need, and you want to fill it yesterday, or better yet a month ago, and yet you have to go through this process and learn about all these strangers, while the building feels like it is on fire).
Note that I said feels like wasted time, not is wasted time. It's a bit like learning a new programming language--you end up going down lots of blind alleys before you find the way you really want to go.
(All we could afford was non textbook candidates, and out of 3 hires, 2 worked out.)
As far as walking the line, as I got more comfortable interviewing, I always worked off a rubric, and set things up so that I could ease out of a phone interview early if it was clear that they didn't live up to their resume. Ended up doing the same thing with the in person interviews as well. Definitely screened by resume.
> I've always been nervous about applying for jobs when I don't have every skill listed on the ad.
This is a hard problem because some institutions write wish lists in their job reqs, and some write hard and fast requirements. And you don't know before applying. (And sometimes the goal posts in the organization move when their "requirements" meet the labor market.)
Personally, I'd apply if you have half of the requirements and feel like you can speak to the way you learn.
If you're interested in the company, I'd also take the extra step and do some work around it, whether that's writing a pain letter ( http://www.forbes.com/sites/lizryan/2015/03/01/how-to-write-... ) or writing a simple client against someone's external API or creeping^Hscanning LinkedIn, Twitter and Github profiles and finding out about the team and company.
>But I wasted time interviewing some overqualified people too (because of salary/location expectations that should have been communicated up front).
Well that's your own fault as the job advertiser, and when I say "you", I mean almost all companies that advertise jobs. You almost never state the salaries to be paid, so tons of peoples' time gets wasted by pointless interviewing which gets followed up with insultingly low salary offers.
If you're a cheap-ass and want to pay a pathetic salary, you should state this in your job ad, so that non-deadwood people don't bother to apply to your job.
>This is a hard problem because some institutions write wish lists in their job reqs, and some write hard and fast requirements.
It's not that hard to tell the difference. When the word "required" is used, that sounds like a requirement to me. When a separate list is preceded by "nice to have", "plusses", etc., those are obviously skills that the company would like to have in a candidate, but are not hard-and-fast requirements. If the company is so stupid they can't write a simple job advertisement this way, and they use the word "requirements" or "required" when they really meant "nice to have", then they don't deserve any employees at all.
Actually, this is exactly the type of person I like to interview. One that's already thought ahead and read the posting and decided if it was even close to a fit lifestyle-wise for them, and technically.
Thank you. When I look for a job, I'm not looking for the very top salary (usually those go to the very top performers, which I'm not, I'm good but not top 1%, or are companies which expect too much time), but there are a good number of companies out there trying to get good people for bottom-of-the-barrel salaries. I don't want to waste my time on those places. They usually have other big problems in addition to poor pay too.
Honestly, I wish every job posting included the following:
- salary range (and an honest one too, not one where they post a mediocre low and a great high, but then never actually offer the high number to anyone and just offer the low number by default)
- work location - sometimes it's not that easy to figure out where a company's office is located, or they have multiple locations. The address is important, because it determines my commute time.
- office environment - is it open-plan, cubicles, offices, shared offices, etc. Some photos would be good.
- computing environment - do you use Windows (7, 8, 10), MacOSX, Linux (Debian, Ubuntu, RHEL, etc.)? A combination? (RH in a VM for development, Windows for email/Office). What version control do you use? (git, SVN, or (ugh) ClearCase)
- standard benefits package: insurance company and regular single-guy premium, number of days off/year, etc.
- a fairly detailed explanation of the actual work involved in this position: what technologies you'll likely use, what the project is, etc.
- number of people in team, how team works together (Scrum/Agile, waterfall, etc.)
If companies would just post all this info with their job requisitions, it'd save everyone a lot of time. I see posting filled with paragraphs and paragraphs of flowery crap about how wonderful their "collaborative team environment" is or their corporate philosophy or whatever, but the things I listed above are what are important to me in a job and what will determine if I'm happy in that job. Spare me the flowery prose about how wonderful your company is; I'll make that determination on my own.
Why should the company lead with what they are willing to pay? Why is it on the company and not the possible employee? Why shouldn't every phone screen begin with the possible employee saying "this is my salary range" and politely exiting the call if the screener won't validate that the salary offered is within that range?
When I buy a car, the person selling the car sets the price. I can take it or leave it.
When I rent a house, the landlord sets the price. I can take it or leave it.
When I'm selling my labor as an employee, why am I not the person setting the price that the company takes or leaves?
I'll tell you why, because the first party to state a number in any negotiation is at a disadvantage, because the counter party suddenly has more information.
Now, there's a valid case that the employer/employee relationship is asymmetrical enough as it is (one employer -> many employees) that the company should give up that negotiating point, but if I ran a company, I'd want to justify that. (There's also a case to be made that, especially with knowledge work, the employee has an asymmetrical advantage because they know how hard they are working, and it's hard for the employer to know.)
That said, when I enter into a new engagement to sell my labor, aka an interview, I do my best to make sure they want to buy my time before I set a price. It's negotiation.
Edit: I love the parent comment even though we disagree, upvoted.
>Now, there's a valid case that the employer/employee relationship is asymmetrical enough as it is (one employer -> many employees) that the company should give up that negotiating point
That's exactly why I think the employer should give up that negotiating point.
The other reason is that employers are constantly whining about how they don't have enough engineers, can't find qualified people, etc., and then lobbying Congress to do something about it. Employees don't have this kind of political power.
Finally, I wouldn't mind if negotiation were simply eliminated with job salaries. You don't negotiate with the cashier at Walmart about how much you're going to pay for some vegetables or a TV. The price is the price, take it or leave it. It'd be better if everything were that way, so that consumers could compare things more accurately. There are many nations where the posted price is not the actual price, and haggling is expected and normal, even on something as mundane as groceries. Without exception, these nations are backwards and economic disasters. There's a reason for that.
There are many nations where the posted price is not the actual price, and haggling is expected and normal, even on something as mundane as groceries. Without exception, these nations are backwards and economic disasters. There's a reason for that
That's a big claim that you make very authoritatively. You should back it up, or change your wording to better express that you're making a hypothesis without much evidence.
Do you have any counterexamples? Haggling is very common in countries like India and various Middle Eastern countries. To say any of these countries have world-leading economies would be quite simply false. India's getting better, but it's basically adopting western culture.
Well as for some prominent examples haggling is considered bad form for small transactions in the nordic countries and they do kind of well. All the places I go to that have a culture of haggling seems to be way worse off.
I guess others can provide more data points that points in this direction but I'd also appreciate counterexamples.
What solipsism is objecting to ("big claim"/"hypothesis") is the statement "There's a reason for that", which implies that there's a causal relationship between the prevalence of haggling and countries being "backwards and economic disasters" (for which there's been no evidence provided).
Only the company knows how well they will be able to turn work into the money that they can use to pay the worker.
The candidate can show the ability to do whatever work the company may require, but if that work does not increase revenues in some way, it will not be able to keep the worker employed indefinitely. Obviously, there's a lot of room for speculation here.
The worker has a general idea of the average amount that many other companies might expect to value the work of similar workers. So the prospective employer has to signal that it can monetize the work more effectively than the median company to attract better than the median quality of candidate.
If your company is building yet another CRUD business app, you do not need above-median skills, nor could you afford them. If your company is building a new, Wall-Street-killing trading platform, you need the 99th percentile of skilled workers, and should therefore be offering 99th percentile pay, because the work will eventually be worth billions of dollars.
The candidate knows how much their labor is worth on the open market. If the prospective employer does not know how much the open position's work will be worth to the company, it really shouldn't be trying to fill it until it does know. If you want to reach the higher-quality candidates, you have to send a clear signal that they will not be rejected for wanting too much money, which happens all too often with companies that need to pinch their pennies or extend their runway.
There are companies out there that will hang up the phone if you say $100k. And there are also companies out there that will struggle to hold their poker face at being offered such a great discount on an employee. You won't necessarily be able to determine which is which before you apply.
When the company does not say up front, it is implicitly saying "we will pay you exactly what you are worth, as determined by negotiation, with no predetermined limits." If they wait until halfway through the second phone screen to bring it up, and then say, "that's more than we can pay", they are wasting the candidates' time.
That is why the company should lead with their salary maximum.
The analogy is not a fixed price on fungible goods in commerce. The candidate has a unique artwork, to be sold at auction. The auction house would very much like to establish that potential bidders have at least enough money on hand to meet the prospective employee's reserve price before giving any of them paddles, especially when the bidding procedure can last several weeks per bid. The candidate does not want the reserve to be known, as they would prefer to get a higher price. Likewise, the prospective employers do not want their maximum bids to be known to their competition. But as they can only complete the purchase by making the highest bid anyway, their wishes do not matter one little bit. You have no business bidding on a Van Gogh painting with only $5k in your pocket, looking for something nice to hang up in a hotel room.
The employer is the one that makes the offer. They are selling the pile of cash, and the employee either buys it with their labor, or leaves the offer on the table.
This is exactly what I look for when I interview for a new job. It's inclusive, shows humility and a willingness to learn through others' experience. Any other attitude belies an employer that's arrogant at best, and at worst nurtures a narcissistic blame culture.
There is not a hiring team out there that even bats 90% let alone 99. The problem is that they significantly hinder their ability to get stuff done when they spend too much of their time in vetting/hiring mode. I've been there and it's no fun at all.
But this is required for the hiring staff to give the appearance of being important and needed within the company. If managers really understood how effectively non-management engineers can find and hire acceptable candidates when you remove the bullshit from the process, they would be confronted with the cognitive dissonance of their choice to staff up an army of HR and recruiters and talk all day about "ZOMG how hard it is to hire a good engineer!" and "look out for the toxic worker" and other such drivel.
I think cubano is referring to the mindset that "it's better to skip over 100 good people than to hire one bad apple" which is very silly but a common attitude in certain kinds of organisation.
It really depends on what 1 bad apple is, that it is someone that is not the most productive but is still productive and don't completely harm whatever they work is seems too much but often that is the meaning in use.
I've had this problem when it's time to adjust headcount (smaller, or trying to swap people out to get more done).
I'll keep the Eeyore person that self selects tasks and issues that are of low complexity (say, 2 on a 5 scale) than the self confident idiot who keeps asking for 4/5 stories when they're really only good at 3/5 on a good day.
That jerk is creating 5/5 stories that I have to burn myself out on (they are either notably quiet or loudly in denial when this happens). I don't care how much project management or the marketing guys like him, even an empty desk would be better. At least an empty desk is predictable.
That approach makes a lot of sense to me. If you can actually manage people, filtering for "not dumb" is usually sufficient to get the desired result.
Most companies demonstrate this with H1 contractor hiring. They usually don't bother with the cool kids club screening in those situations. One of the smartest people I ever worked with had a degree in Chemical Engineering from some mid-tier university in India that I never heard of. That guy would never get hired as a FTE at that company, because he didn't drink and didn't have the cultural "fit" nonsense.
When I interview candidates, the make or break question for me is does the person possess critical thinking skills?
Various things may point one way or another for this, but it is a mistake to assume [insert working at a particular company] is an indication that someone has to have the skills, as well as to assume someone not having [insert pet qualification] is an indication that someone does not have these skills.
Sadly, there is a severe lack of this skill applied in our profession, and it is probably the costliest common mistake I see.
instead of asking them stupid, verbatim-recall questions, i give them a problem and ask them how they would solve it.
i.e., "a customer reports his website is running too slow. describe how you would identify and solve the problem."
it's a good sign when they start asking you follow-up questions, like "is it load balanced? is there a database?". it's a bad sign when they say, "just restart the server".
I got asked "what happens when you hit return in the browser?" After I had traced from the keyboard driver through libraries and runtimes to the browser event system, then back down thru the network layers to sockets, then thru IP events to land a packet on the remote router, they called a halt. Apparently nobody had actually answered the question before.
IMO Its a good exercise for problem-solving, and plumbs experience and terminology. I'm not so sure you learn anything about the subject's actual programming skills?
well yeah, it's just one question. programming and devops proof is in the pudding. we just ask for code samples and a walkthrough, and go with our gut. maybe a few technical procedure questions.
in my experience it's the other things that will make or break an employee, like whether or not they have an actual work ethic, or is a closet drug addict, or gets too drunk and touches women inappropriately at company events.
these are things you can't test for in an interview or background check, and i find it strange that nobody ever mentions this kind of stuff because personal problems are the most common kind we run into. it's rare to hire someone totally incompetent if you yourself have extensive experience in the work you're hiring them for.
I think that's actually a really good question. It shows deep knowledge and understanding of everything that is happening during a user interaction which is essential knowledge for a webdev. Plenty of "front end developers" have no clue what an HTTP request is.
Nobody was discussing how a keyboard works, but how the web works after you press return on the keyboard. And it's sad that too many web developers in general[1] seem to have the weakest understanding of such basic principles.
[1] super-anecdotal self-selected data points from hiring and conversations
If any front-end developers do want to learn more about Internet/browser networking, I'd highly recommend the book High Performance Browser Networking by Ilya Gregorik. It looks like there's even a free version now available online:
I think that both this question, and beachstartup's question about speeding up a website, are totally decent interview questions, for a intermediate-to-senior web developer.
But if anyone thinks that either of these questions is testing "critical thinking skills", or "problem solving", then I would like to hear in what way. Both of those seem to me to be pretty much archetypal "verbatim-recall questions".
Experience and exposure and education and ability to brute-force recall all of the above is valuable. But it's pretty much the exact opposite of what beachstartup said (s)he was testing, and there is zero "problem solving" in the "what happens when you hit return in a browser" question.
I'm a little bewildered how anyone could confuse these diametrically opposed aptitudes.
True. It takes all kinds of questions to get a good impression.
But I'd just like to protest, my answer was not 'brute-force recall'. It was simple experience. See, I've written code at all of those levels. None of it was booklearning.
I'll start by noting that this sequence of comments is just nit-picking, and if that bores anyone, stop reading. That disclaimer disclaimed...
I don't honestly care if it was booklearning or not, and I don't see what it has to do with my kvetch. I'm happy to believe you that it was learned from experience.
What does "brute-force recall" mean to you? To me it means that you are only repeating things that you knew before the question was asked, as opposed to dynamically generating new knowledge during the time that you answer. Whether you originally got that knowledge from books, or from experience, or from Mr Spock doing a mind meld, it's still memory, as distinct from problem-solving or critical thinking or perhaps more generically we might name "wit" as the counterpart of memory.
Again, I'm absolutely not knocking this form of knowledge; memory without wit is perhaps inflexible, but wit without memory is impotent. Memory is a good thing. Memory makes up the much greater half of expertise; this is why seniors get paid more than juniors (would you rather hire an IQ180 noob who knows nothing about the problem, or an IQ120 worker with 20 years of relevant experience?).
But I'm getting pedantically wound up about this minor nit: both you and beachstartup gave examples of interview questions that are tests of memory, and framed them as tests of problem-solving. If problem-solving is the thing you want to test, those are terrible interview questions for that particular purpose.
Wow I had a similarly perplexing and bad experience interviewing there.
It was for a UI Engineer position. I did very well on all of my technical coding challenges, with the exception of an algorithm question, which I still managed to complete once the interviewer pointed me in the right direction.
I was later told that while everyone really liked my culture fit for the company one of the interviewers with whom I sailed through the challenge thought I did mediocre, and the algo question asked said I "really struggled". It was pretty devastating but I just chocked it up to me needing to dig in and study harder.
When I interview, I start with a description of the couple of team members they'll be working most closely with, for, or leading. After that, I like to ask "With your limited understanding of where we're strong right now, what do you think your biggest contribution to our team will be? what will we learn from you?"
I've not done any validation studies on the answer, but it's certainly the question that has led to the best conversation.
Yeah, definitely. I never felt more like the Mike of the story than I did interviewing at Airbnb. Every interviewer was fresh out of school, very smart, fashionable and attractive and definitely wanted to prove something. Despite doing rather well and scoring exceptionally well on personality, I was still passed on, and it's hard to shake the feeling that maybe it was because I wasn't a hipster. They just had this air of superiority the whole time.
It's not about trendiness. It's about valuing experience with a specific stack out of all proportion to what that's worth - perhaps because it's one of the few things that's easy to measure.
I've looked at going in the other direction - onto .NET. There's a lot to like about the framework. But I can take a job on the JVM and be paid like the dev with 7 years' experience that I am, or I can take a job doing .NET and get paid like a fresh grad, despite the two systems being about as similar as it gets.
And I've watched plenty of people in suits be hired at trendy startups. Maybe the bar will be a little hire, but it's not an instant firing the way wearing a t-shirt to many companies would be. A lot of tech companies really are better at this kind of thing than other companies; there is always room for improvement but there's also room to celebrate the things we do get right. Stop listening to DHH.
I interviewed at Loopt (sama's YC company) 4½ years ago. When I went out to lunch with their tech guys, they joked about a guy who had come in before me in a suit, and how that really hurt his chances to get the job. Though I knew enough to dress casually, I was coming from a company in the midwest where I had to wear a suit every day. Both extremes seemed absurd to me.
I eventually turned them down in favour of another offer.
I completely agree with the article. I worked for EC2 for >3 years and consistently exceeded team expectations. I'd get pinged by recruiters all the time while at Amazon. Now that I work for smallish not-for-profit, no recruiter seems to be interested any more. What's interesting is that I'm more active in OSS projects, have far more experience than I had when I left Amazon. Totally weird!
I see wonderful symmetry here. There are TrendyCos (hot startup unicorns), BigCos (established companies like google or amazon or microsoft) and UnknownCos (not in the limelight so there is not much information about them). Likewise there are TrendyDevs (hotshots who produce one heavily github-starred framework after another), BigCoDevs (multiple years of experience at one of the BigCos, probably were responsible for some important part of one of their numerous services) and UnknownDevs (been there done that, hard to say).
And here is the rub. There are certainly many undervalued gems among UnknownCos and UnknownDevs but also many abysmally bad workplaces and programmers. So you either have some inside knowledge about them (a referral, an acquaintance working at UnknownCo), have some magic method for separating the gems (like tptacek claims to possess) or it is just too risky to consider them.
There's no magic to it at all. Have every candidate work on programming problems related to the work you do at your company. Have every candidate work on the same problems, and let them do it from home. Build and iterate on a rubric for grading those challenges.
It is amazing to me that almost nobody does this, but: almost nobody does this. They have programmers write code on a whiteboard, or on some whiteboard-coding site; they have them do programming puzzles ("solve Towers of Hanoi non-recursively"), they have them talk about code, or, more likely, computer science trivia. They'll have them "pair off" with one of their own programmers and "fix a bug". They'll have them work as a 1099 for a month to see if they're any good.
In reality, most companies are trying to hire on trendiness; they want people from the right schools and/or the right cohort of companies. They're aggressively courting friends and colleagues of their existing team, and the special people get very different interviews than everyone else. The actual technical evaluation is mostly a facade.
Maybe this is an US thing. I changed jobs last year and nearly every single recruitment process involved exactly that, after a remote interview them giving me a small project worth 2-5 hours of work and then going over what I produced one week later. This was for companies in central and northern Europe.
I have had a few of these the last year or two. Never been paid. More than half of them are a waste of time. I have refused quite a few of them.
The last "shouldn't take you more than two hours" exercise that I was given involved jumping through hoops to get set up on Instagrams API, only to discover that I was in a sandboxed mode, and needed my account approved before i could get anything more than metadata out). I didn't even get started coding, so I am not sure what exactly the test was meant to achieve.
No, there's no principle, there's a ~20 minutes old idea that we engineers are so obviously awesome that companies should actually be paying us for the privilege of interviewing us.
There may exists engineers obviously awesome enough for that to be feasible, and great for them (but they are probably also obviously awesome enough to not have to go through coding tests, so it's a moot point) and even if I could perhaps (judging by certain recruiter-emails) scrape by as one of them, I certainly couldn't five years ago.
Back then, if I'd had to be good enough on paper alone to warrant not just being put through the recruitment process, but to be paid for it was well, I am not convinced I'd have been considered (and yes, I did a take-home test, and I aced it and it made up for my near-total lack of on-paper qualities).
Of course, companies shouldn't waste their applicants time with needlessly extensive tests, but there certainly exists no 'principle' by which you have a claim to be reimbursed for spending a few hours on an application.
Actually, for actors it does. If you go to a casting session, you should get payed for it. That's because they had a first chance to filter you out and they are not entitled to waste people's time. For the first filter, they use their CV and their reel (video of the actor showing itself).
I think that the same rules should apply for programming jobs. Just look at my resume and my publicly available code (that is linked from my resume). If you decide I am good enough to interview me, pay a reasonable hourly rate. This would stop the abusive practice of giving big problems to solve in our free time.
If this is true of programmers as well (and I have no opinion on whether it should be), it should be even more true of standard on-site job interviews, which are more disruptive to your work schedule and more demanding of your time and attention. But, of course, people do not generally get paid to go on job interviews.
It's at least reasonable to cover travel costs for interviewers. I was given a $40/day stipend for food and reimbursed gas and hotel when I interviewed at my current job.
This is a sound-bite, not something that holds up to scrutiny.
If you decide not to interview with possibly great places based on this, you're essentially saying that all future expected gain isn't worth some set hourly rate for 2-8 hours of your time.
Also, what's your free time worth? For me, sometimes it's worthless, and sometimes I feel like I'd sell my soul for 10 minutes to myself.
I'd so much rather do a project with my own tools and from the comfort of own home than commute several hours across the city for a several hour interview.
If all it required was an hour phone call and a small project, I'd totally do it for the right company.
I was not, at any of them. Yes, I was effectively giving them my time but it doesn't sound unreasonable when you compare it to the alternative: I'd spend that same time answering whatever obscure coding questions or far-fetched exercise they had but in a far less comfortable setting (and arguably less representative of my skills). Not to mention how I'd probably have to do the interview at a time they're working, instead of doing it on a snowy Sunday evening, at my discretion.
Its a crap waste of time. Take home exercises have little more in common with the job than a white board exercises. And not all devs are going to do half a days work for free.
People say this in every thread about hiring, and it never makes any sense to me at all.
Companies that don't hire using objective at-home tests hire instead with grueling on-site interviews that knock out an entire business day (most of them last a whole business day, some recent interviews peers have gone on have taken multiple business days, and all of them at the very least kill the day for anything else). The latter is obviously worse than the former; I don't even see how any other argument could be colorable.
What I'm beginning to think is that this kind of pushback comes mostly from developers who are well-connected, and so they never experience the grind that less well-connected but equally-capable developers do with interviews.
Yes: if you're at a point in your career where you can get a job in any of 6-7 different companies just by raising your hand, saying "I'm available", and having a 30 minute conversation with the VP/Engineering who you worked with 2 jobs ago, everything is a waste of time. I am not here to tell you that you should make things harder for yourself.
If used wisely, at-home coding tests should be far better than the average mess of a technical interview.
The problem is in the hands of TrendCo, they can be used crudely to find the trendy hire who has the exact same ideas about engineering as the hiring person. Because giving the test costs TrendCo nothing, they are happy to throw people at it until they randomly find someone who is exactly what they are looking for.
Anecdotally, I and 2 people I later befriended applied for the same role. We each spent 4 hours on the task, all 3 of us strong coders who made a solution that would be suitable for any startup, all 3 taking different approaches based on our styles. We were all rejected, because none of the 3 of us hit upon the exact approach the company was hoping for, but didn't ask for. There was no opportunity to ask for this feedback either. And it took them nearly a month to bother looking at my code (even after I called).
Since then, I won't take these kind of tests unless I have reason to believe they are being given in good faith as a way to determine if a programmer is capable, not as a way to find their perfect ideal of a programmer.
If you had asked at Matasano how we evaluated our work-sample tests, we'd have told you. In fact: the first contact any new candidate had at Matasano was a 45-minute-long phone call with a director+ (for a year and a half: me), during which we explained our process in excruciating detail and answered any questions that came up. If we got even a hint from a candidate that they might not know exactly what we were looking for, we'd get their mailing address and fedex them a stack of free books; we gave them cheat-sheets on what parts of those books to read, as well.
I have the strong impression that a typical SFBA tech hiring manager thinks it's crazy to give candidates cheat sheets for interviews, and that helping candidates with technical evaluations decreases rigor. THE EXACT OPPOSITE THING IS TRUE. Evaluating technical ability under unrealistic pressure and with unrealistic restrictions confounds the results of the evaluation.
Of course, you have to design tests that are valid predictors for candidates who have received tips and assistance and practice and resources. That sounds hard! But it isn't. The best predictor for a candidate's ability to do the kind of work you really do is, simply, the kind of work you really do. Not problems from a book, not trivia questions, not one algorithm poorly implemented on a shared coding site and a Skype call, not whatever bug is at the top of the bug tracker today, but a sample assignment given to a real member of your team, the same one, for every candidate, graded the same way.
I completely agree with all of that! If only more hiring managers were so thoughtful. Now, I'd only do this kind of at-home work if I can talk to someone who will explain how their hiring processes works, and I get the sort of good vibes that your post gives.
The problem is that a lot of companies put out the take home test and then expect a long on-site as well. One or the other would be fine but take home tests are easy for the company to send out a lot don't take them that seriously.
Have every candidate work on the same problems, and
let them do it from home
To be fair, I've seen a lot of good arguments against programming assignments. I think at the end of the day, the employer needs to conduct some method of determining if the employee has the technical capabilities needed for the specific job they're being hired for. However, there are MANY other factors too like "how well they get along with the team" that need to be considered. That's what they're trying to determine with the pairings and other stuff you mentioned I think. Whether that works is another story.
Every team I've talked to starts out with some X-factor they think they need to assess for. It's my belief that if you can have the discipline to stop filtering for X-factors, you'll build better, more effective teams, because those factors are really just vectors for personal biases.
Regardless of whether you agree with me about that, I think we can all stipulate that if work-sample technical evaluations work (and: they do), most of what companies try to evaluate in on-site interviews is stupid. No part of working effectively with a team requires timed recall of how to implement a stable quicksort, or reversing a doubly linked list at a whiteboard.
At the very least, using work sample tests allows you to build an on-site interview process that honestly engages with "team fit" (or whatever your X-factor is).
My guess, though, is that when more teams adopt work samples and then go through the motions of trying to design a pure team-fit interview, they're going to realize --- once they don't have "implement Bellman-Ford on this whiteboard" to fall back on --- how unequipped they always were to evaluate team-fit in the first place.
The problem could also be that many teams simply don't have the time or possess the knowledge to do an assessment like you're suggesting (which I agree is a good way to assess candidates). It requires someone to actually design an assignment (which is a task that many coders might not be good at), and requires one or more people to evaluate it.
The ridiculous whiteboard coding of puzzles probably stems from laziness or inability to implement what you're suggesting. I know that personally, if someone asked me to developed a work sample evaluation for my job, it would take me many hours to come up with something, and frankly I even once complete we would have no way of knowing if it is actually a good predictor of whether or not someone is the right employee.
Hours? It could take a week, and if you're going to hire more than one person this quarter, it will still be worth it just in the time savings from not having developers deliver bad interviews.
Have you done this? My worry would be that sooner or later you'll have a candidate who posts the assignment online ruining your weeks of effort. It also seems like it makes it much easier to cheat if you make it a take home.
Yes, I ran a process like this for several years. I ran recruiting for the largest software security firm in the US; before that firm bought us, I used this process to more than double the size of my company. When I left, to work on a recruiting startup, not one of the people I'd overseen hiring had quit or been fired.
We paid the market median to new hires; we definitely didn't buy our way to that turnover (NCC pays better than a lot of early stage startups, but not better than late-stage ones).
No, I attribute the turnover to the recruiting mechanism. We found great people who were sorely mispriced by the market, and we took advantage of that to create a win-win scenario: people without the resume to get a similar job at a competing firm got an extremely impactful resume bullet and a good-paying job, and we got people who genuinely wanted to be on our team and weren't applying as a once-a-year lateral job-hopping gamble.
(I have no problem with people job-hopping, by the way, but every employer is trying to minimize their exposure to that.)
You were also recruiting for a "cool" sector where people would be learning marketable skills. Do you have any evidence that the same technique would work for more "boring" companies? (I ask because I'd like to convince my manager that creating a work-sample test wouldn't be a waste of time)
I agree completely. But in many organizations recruiting and hiring would be considered overhead instead of strategic, and thus a target for outsourcing to someone in HR or some outside firm. The problem there of course is that those people have neither the ability nor the inclination to create or evaluate a work sample challenge.
Really my comment was just to help demystify why this sort of thing doesn't happen in many companies based on my own observations.
If you substitute the candidate's time in an in person technical interview with the estimated time for the take home assignment, I can't see the issue. I would gladly give 3 hours of bullshit algorithm white boarding exercises for 3 hours of homework.
My last job search wasn't typical (I thought of starting a consultancy, so didn't search for a job per se), but one before that showed to me that it's exactly what people do. A company that was looking for a guy to write mobile SDKs asked me to build an Android app with embedded webview and animate html stuff with JS based on gyro movement. A slot game company asked me to build a minimalistic slot game from scratch (thanks to them, I have a clean minimalistic and complete game on github now). Another game company asked me to build a small endless shooter — and I ended up being the only candidate who moved texture offsets instead of actually moving game objects to infinity.
Each of those tasks took from 4 to 8 hours, and 2 of those got me an offer. And of course, I used the same method when I consulted others on hiring decisions or hired people myself. So, based on personal experience, companies do that, and it works.
I'm glad that I'm starting to get feedback like this. I believe you that more companies are doing work sample tests.
For the the gigs that asked you to do these problems: did you also get interviewed with a standard programming interview? If you had to guess, between 1% and 100%, how much of the weight of your technical evaluation do you feel was on the sample challenges you did at home, versus Q&A and whiteboard coding on-site (or on the phone)?
Don't remember details about interviews, but I'd tell that homework was about 75%, because in those two cases they told me that I exceeded their expectations and they learned something new from my projects.
FWIW I presented this option to my senior management and HR at a "household name" software company and was essentially told we can't do this because it looks like a test and we'd have to do the same test for every candidate or else open our selves up to discrimination issues, no matter which team the position is for, and that was a no go.
> "we can't do this because it looks like a test and we'd have to do the same test for every candidate"
Oh, what a terrible tragedy, to give candidates consistent evaluations that are actually comparable between each other... /s
I get the point you're presenting, but at the end of the day it still boils down to "we can't use tests because then we'd have to be held accountable for objectivity, we prefer instead a system that lacks any kind of rigor such that any result may not be effectively challenged, officially or otherwise".
1) HR (presumably taking direction from in house counsel) takes the position that it will be difficult to distinguish between a work sample test and an IQ test
2) We are a large organization with very broad roles. The Performance Team hiring for a Senior Software Engineer will probably want a different work sample than the Analytics Team...
It is simply not true that the Perf team must deliver the same work-sample test as the Analytics team.
Let's not dignify that argument. I absolutely believe you that your company has allowed HR to sabotage your hiring process, and that sucks. But let's not pretend HR is right to do it.
Ironically, a work-sample test which WAS the same across every developer would be closer to an IQ test than if that work sample test were tailored to the role.
There's probably a solid argument for giving every candidate for the same role the same work sample test; otherwise you might naturally want to randomize some parameters or choose from a bank (if you think "cheating" is likely).
I'm looking for a leadership role. Whether that happens at my current company (I'm an IC with a lot of technical leadership and mentorship responsibilities) or elsewhere only time will tell.
If you or anyone you know is interested I'm a software developer and spend a lot of my time on cloud architectures/containers/multi tenancy optimizations but just generally enjoy solving business problems with technology. In a past life I cofounded a startup that didn't turn out to be viable after going through an incubator (not YC). I have a resume, LinkedIn, Github etc.
The HR involved must be applying cargo cult rules of thumb without understanding the actual rules and the work the company does (which is, unfortunately, distressingly common for HR organizations.) If the actual work you did was such that a work sample would be indistinguishable from an IQ test (which it isn't, for almost any real work anywhere, and you'd have to be ignorant of either what the work is or what IQ tests are to make that mistake for most jobs) then IQ tests wouldn't be problematic in any case: IQ tests aren't specially prohibited in employment, they were just the immediate subject of one notable case which held that anything with a greater impact on a protected class is illegal if that impact is not warranted by the validity of the filter at issue as a measure of performance in the job for which it is used as a filter.
Not only that, but there are several very large companies that do in fact use IQ tests during screening (that's a stupid policy, for what it's worth), so I'm pretty dubious about the claim that IQ tests are unlawful.
They are lawful when you can demonstrate a link between on the job performance and the IQ test. Given how g-loaded software development this should not be hard to show.
It saved us enormous amounts of time at Matasano. When we designed our work-sample rubric, our #1 concern was filtering out people who interviewed well and/or had great resumes but weren't worth a billable hour on a real project, but our #2 concern was interviewing faster and getting results back to candidates quickly. (We didn't discover the best reason to do work-samples --- discovering hidden talent --- until after we'd started doing them).
With standardized interviews and challenges, our whole hiring pipeline became entirely mechanical. We could send our a challenge and its instructions in 2 minutes, and evaluate the response the next day (or week, or whatever) later in less than 5 minutes. 7 minutes, to produce a technical evaluation that crushed a competing battery of tech interviews by several senior staff members that took 4-5 hours to do.
Yes: like I said, the goal was to get results back to candidates faster.
The biggest complaint we'd been getting from candidates before work samples was that our process took too long. Our goal became to get the entire process done under two weeks (from its worst point, a month or two earlier, of 1.5 months, when someone finally posted an anonymous complaint to Glassdoor about us).
After iterating a couple times, we could reliably go from first contact to hire/no hire, with a motivated candidates (ie: one who would work with us to schedule the interview process aggressively) inside of a single week.
As a candidate, I would be a little wary of this process. You're asking me to put in multiple hours of work, but you only put in 7 minutes. So the incentives are misaligned: you are incented to give these challenges to many people, even if they have a low chance of passing through. But as a candidate, I don't want to sped multiple hours if I have a low chance of passing through. This is one reason why full-day on-site interviews aren't so bad - if I've gotten to that stage, I'm probably pretty likely to get an offer.
First, I don't concede the idea that this is a concern I need to ameliorate, because the work-sample process consumes fewer hours of candidate time than the conventional interview does, and, better still, consumes those times as, when, and where the candidate chooses to make them available: an hour a night during the week, say. Do the work from your favorite quiet bar. Do it during your coffee break.
I am spending a lot of time these days talking to people interviewing in the valley, and what I'm seeing is that the norm candidates are subjected to is 7+ hours of 6-7 on-site interviews. Candidates have to go through all the interviews, even if the first interview has effectively ejected them from the process.
Compared to that horrid process, I don't believe I have to justify anything about my process.
But, if you read downthread, you'll see that we in fact did a lot to ameliorate the (bogus, I think) concern that we were incentivized to soak up hopeless effort from lots of people.
I was thinking something similar. When one party can waste the other party's time at little cost to their own, the situation can be abused. If a job ad wants you to submit to a test before you even talk to a hiring manager, this is a signal that the employer doesn't care about wasting your time. I can see the advantages to automating the hiring process but as a candidate I am less inclined to engage with a party that has no "skin in the game".
Think of the design world:
Potential client "A" asks multiple desperate artists to work on spec in hopes that they will get the commission.
Potential client "B" call you up and talks to you, sends you some napkin sketches and generally engages with you for an hour before asking you to do a design.
Both clients want you to do a design (test) but one clearly doesn't have any skin in the game.
Assuming you're a decent designer, which client do you respond to?
Aha! I sort of like that, then. Assuming of course that it actually does work.
Back when things were simpler, we had a multiple guess questionnaire that did the similar. For onsites, we then looked for evidence of rigor and thoroughness, the ability to estimate how much communication was required, had they deployed real systems?
You understand that it sounds like you "fixed" hiring, and so we're all sorta skeptical, right? If you could bottle that, there's your billion.
I am talking my book in the sense that my business works a lot better if companies get saner about how they hire people, but Starfighter is not the commercialization of the idea I'm talking about here.
>It is amazing to me that almost nobody does this, but: almost nobody does this.
There isn't enough feedback when someone has a bad idea on hiring. People will very quickly tell you if your code sucks though (this is a good thing), which might be the kind of feedback needed to get hiring changed.
I am fine with asking for candidates to work as a 1099 for a month if you pay them the standard 1099 contractor rate, which is almost invariably more than 2x their FTE rate. I am not fine with the industry norm of paying people their eventual FTE salary on a 1099 basis; that's a scam.
I think it's pretty dumb to do that, though, because most software developers can't take a month off of work from their current job to see if they're a fit for your company, and none of them will put their health insurance in jeopardy to do that.
I also think it's pretty silly to design a process that deliberately demands a month of time to make a decision that could be made effectively in a week.
That strikes me as a very costly way to build a team. Independent contractors are expensive; they know, better than most other developers, what their time is worth.
It shouldn't be on top of that! It wasn't for our process. Of course: we did in-person interviews. And in-person interviews are disruptive no matter what you do. But:
* Our in-person interviews were shorter than typical in-person interviews because they weren't tasked with fully teching candidates out.
* Because they didn't try to tech candidates out, they weren't as stressful, and so were less draining and unpleasant.
* Because our in-person interviews were entirely scripted (the interviewers had very little latitude with what they could ask and how they could ask it --- which they hated, by the way), they were easy for everyone to deliver.
* Before candidates arrived to their interview, they already knew (because we told them!) that they were likely to receive an offer from us based on their performance on the work-sample tests.
I understand why people resist the idea of coding challenges, given:
* They're not going to get feedback for weeks, months, or maybe ever
* The challenge is going to be graded pass-fail, or whimsically, without rigor or consistency
* They're going to have to do the exact same grueling bullshit draining dehumanizing programmer interview anyways
* They're not going to see the challenges coming, or, for that matter, know exactly what happens next after the challenges are done
That process is super common, even at companies that ostensibly do challenges. It sucks. I agree, no company can really get away with this in the long term.
But those are also chickenshit problems. Switching from unstructured interviews to work-samples is hard: you have to change your mindset on how to qualify candidates, and there's a leap of faith involved. But getting candidates feedback, telling them what to expect with your process, keeping a schedule, and having processes in place to be consistent aren't hard problems. They are table-stakes common sense business execution, and if your team can't handle that right now, your team is mismanaged.
Can you share an example of challenge given to candidates? In the past, I've used "script a file sharing tool that handles encryption", which worked well and took candidates ~4/8 hours to complete, but isn't something we used directly in our projects.
Sure: we wrote a very simple retail trading system as a one-file Ruby app. It used a custom binary protocol. We had candidates reverse the binary protocol, implement enough of it to test the system, and find vulnerabilities in it.
We had a grading rubric for the challenge that was based on the kinds of things people found in the application. We evaluated performance on the challenge on a 1-5 score; depending on how you did on other challenges, a 3 would keep you in the game, and a 4-5 probably assured an in-person interview.
I love this approach. I'm also wondering what you think about giving well-designed work-sample tests over Google Hangout instead.
The candidate shares their screen with you, so you can watch as they solve the problem in their own dev environment. You can understand how they approach problems (quick and dirty, slow and methodical, lots of rewriting, etc), and you can ask questions at the end. You get a good sense for how they work as an engineer even before having to bring them onsite.
This seems to resolve the time asymmetry of take-home tests as well -- the interviewer spends as much time watching as the candidate spends working.
The only downside I can see is that you have to design your problems to take about an hour instead of the 2-5 hours you could imagine for a take-home test. But, you can break them up into multiple rounds, and give additional exercises to the candidates who do well on the first one, for no more total time cost than a collection of onsite interviews.
For what it's worth, I've done this at my startup and hired a great developer, and got very positive feedback about the process from the candidates I didn't end up hiring.
As someone who's had to do a few take home tests as well as coding with someone looking over my shoulder, I am definitely not a fan of the latter. I prefer to sit down and think about a problem, maybe even read it and let it sit in my head for a day or two before I actually start the coding. I also feel like shortening the time and making it synchronous would remove the opportunity to revise and polish the code I've written, which is one of the advantages of the take-home test format.
My ideal interview format would involve a work sample test, followed by a code review of said work sample, and also a reverse code review (candidate is given some code to review). As an added bonus, all of this can easily be done over email without wasting too much of anyone's time, especially compared to an all day in-person interview with lots of whiteboard time.
I agree that this is "better" than the alternative, but it can be absolutely exhausting for candidates actively searching for a job. I feel like it's recently become much, much more common (from my small-ish sample of me and some friends).
My issue with this approach is fourfold:
1. Most companies have no idea how to structure a problem that is both informative to them and also not abusive to the candidates time.
2. Companies generally do this right after the recruiter phone screen, which most likely doesn't give the candidate enough information to decide if the next steps are worth their time.
3. Most companies still do a whole suite of normal tech screens after you work on a take home problem.
4. If you're actively looking, getting a bunch of these over a short period of time is likely. I know during my full time search, more than 50% of companies had a take home test right after the recruiter screen. Most of these were 4-8 hours of work each, due within the week.
A lot of startups structure it more like hazing or a barrier to entry than an evaluation criteria. I have some fun (read: horrifying) anecdotes from my recent search that illustrate the problems above, but I don't think any of my points are surprising.
A nice alternative would have been to simply have one or two projects completed that are straightforward to evaluate and walk companies through them, letting them ask me questions.
Here's a really simple test for whether a work-sample scheme is effective, or just a bullshit trend-chasing afterthought:
Does the work sample test offset all or most of the unstructured tech evaluation the company would otherwise do?
If it does, that means they have a work-sample test rubric they believe in, and they're hiring confidently. If it doesn't, they don't believe in what they're doing, and the programming challenges they're assigning can thus reasonably be seen as more hoop-jumping.
In the latter case, it's up to you to decide whether a prospective job is worth extra hoop-jumping. Some teams are worth it!
I think that's fair. I've had both the former and the latter, but unfortunately most of my experiences fall into latter case, where it's simply been hoop jumping. Most of my friends (all about to graduate, so a good number of examples) are experiencing the same.
For example one company gave a problem with five parts, with the final part being solve longest path on a bipartite weighted graph (which is quite a hard and time consuming problem). After that, the next step was a phone technical screen, then an on-site with 4-5 more interviews, most being white-boarding. It was basically hazing instead of an evaluation criteria.
An alternative is my last job, which had a take home test that took about 6 hours, but that was the whole technical part of the process. Being on the other side reviewing them, the problem absolutely gave enough information.
I totally get there's a right way to do it, but like most interviewing trends, companies seem to just be adding this as a step instead of revamping their process.
Does the job they're interviewing involve finding the longest paths on weighted bipartite graphs? Or is this just non-recursive Towers of Hanoi pretending to be a realistic work sample?
No, the position most definitely had absolutely nothing to do with longest path or combinatorial optimization.
Anyway, my larger point is that what I've been seeing interviewing is that these tests are becoming much more common at US startups without companies removing/reducing the rest of their technical evaluation process, nor really structuring the problems to be a good signal.
In an ideal world where companies do take home tests right, I think its a great solution. But what I've been seeing more often than not doesn't support that, making it hard to support.
I'm really curious what you've been seeing at Starfighter. Are partnering companies still going on to do a full technical interview? Or does Starfighter largely replace their normal technical evaluation?
Ignoring the fun of the challenges themselves (which probably isn't entirely fair), the latter makes it very compelling for a candidate. The former does not.
Most of our partners have a somewhat abbreviated interview for our candidates, but everyone (as far as I know) still techs our candidates out.
I'm actually fine with that! We make no pretense of having designed a screening process that is appropriate for every job. What I'm less fine with is the fact that the norm, even for abbreviated tech-outs, is 7-8 hours of on-site whiteboard interview.
How much time do you give candidates to complete their work samples? I'm curious whether work-sample tests filter out, say, parents with young children, in which a company with a 4-6 hour technical interview might be preferred over an unbound take-home assignment (in addition to the possibility of more interviews).
I don't like it but I do understand it from the employers perspective. Most hiring is done to avoid risk. Went to a top school, working at a popular company and already using the tech we use? Come in for an interview. Missing one of the three? We'll phone screen. Missing two out of the three? Not worth my time.
The OP's point is that "This only works if you pay the appropriate amount".
If you go with that process, but discard the "money" variable, you'll only interview the people who got rejected from every one of the well-paying companies.
I understand the other two, but I'm curious why "working at a popular company" makes sense to you. What does that have to do with avoiding risk? Is it the assumption that those companies don't make hiring mistakes?
A lot of companies founded by young people, hire other young people and believe the best tech is what they learned in college: Command-line python, javascript. They don't realize that teachers teach python because it's easy to teach, rather than because it's the best language for the real world, or that tools make people more productive in the real world (where they can be afforded).
And both groups do a disservice to each other when they cannot work together. There are a lot of new ideas that we greybeards can learn from the greenies and there are a lot of tested foundations of which the newer generation is often unaware of, especially those that were taught to not worry about resources.
Also, one of my old 40something coworkers taught me how to do so many legit unix things. He also told me what stocks to buy and gave hilarious relationship advice. ... Maybe I shouldn't have quit that job.. haha
In interviews I actively try to down play the companies I've worked for and the things I've done with them. The reason I do this is that I don't want people to come in with unrealistic expectations and expect me to live up to them. I also don't believe in preparing for interviews. I'm ok with the rough edges I have. I want my imperfections to come through on some level. Yes I have a preference for certain technologies. I love what I do. They should be more concerned if I didn't have an opinion. It doesn't always work out in my favor. shrugs Rarely, do I serve up great interviews back to back on different days. I'm an front-end guy because I love building them. That's all.
I struggle with this as well and it worries me. I tend to be painfully realistic about things I can and can not / have not done. However sometimes I feel like I need to do a better job of selling myself. Walking the line between 2 extremes is quite difficult.
As a candidate I'm looking for an employer that wants me (or that has a real urgent need or want for a good candidate). This is usually evident at interview or before. You can tell they really need someone, rather than having to grow for the sake of spending their VC money.
As an interviewer what I'm looking for in a candidate is someone who really has enthusiasm and passion and wants to work for me. It's less important how they look on paper, I want to know how much they want to work with us.
I think we're starting to see the need for 'laborer' programmers. There's a lot of relatively unskilled glue/laborious coding that needs to be done. When you need someone to hammer a bunch of code out for you, you don't need an experienced and flexible software engineer as much as you need a kid with a well-trodden neural pathway that lights up when they write code in your tech stack.
I think code schools are effectively training programs for this kind of work at the companies that use them as hiring pools. I would be surprised if these companies didn't influence the schools' curricula in some way. If they aren't doing this explicitly, they should, and they should absorb some of the cost that is currently being levied against the students. Right now, we're at this weird point where students are paying for their own training at these 3rd party facilities that more or less kind of guarantee them maybe a job at this list of very specific companies but no guarantee... Something feels a bit sleazy about it. I don't know how transferrable the education you received at a code school will be once you leave the company that hired you from it.
I think the field of software engineering/programming/whatever has broadened so much that you have to have some distinguishing, domain-specific feature to get a job somewhere--the distinguishing feature of the 'trendy' programmers is usually the tech stack alignment. Maybe general knowledge of writing good, maintainable software is moot in the face of an efficiently trainable workforce, short-lived code, and a diaspora of tech stacks.
> I think we're starting to see the need for 'laborer' programmers. There's a lot of relatively unskilled glue/laborious coding that needs to be done. When you need someone to hammer a bunch of code out for you, you don't need an experienced and flexible software engineer as much as you need a kid with a well-trodden neural pathway that lights up when they write code in your tech stack.
What do you think those indian programmers were doing for the past decade?
> I think we're starting to see the need for 'laborer' programmers. There's a lot of relatively unskilled glue/laborious coding that needs to be done.
I have a computer for that! Seriously, that's one of the things a computer excels at. This is what is so nice about a language with strong dynamic typing: it makes writing the sort of code which writes glue code reasonably easy.
How do you get your computer to solve the problem of "this text needs to be 2 points larger, a darker shade of red and 5 pixels to the right" without involving a programmer?
I've worked on the Avon AU website and we had a few hundred tasks like that. It's why (to link back to my current pet peeve) I'm upset that my relatives are unwilling to learn a tiny bit of web design because "it's too hard". There is a market for people who ONLY know how to do this. (There were two people in the company I was working for and my team only got access to them one hour every week - they were that busy.)
> I think we're starting to see the need for 'laborer' programmers.
The mass offshoring effort in the US through the 00s was exactly this. The problem that many companies discovered is that you really get what you paid for. If you spec something out to a 'T'[1], you'd get exactly what you ask for - warts and all. If you don't provide enough detail to do that, you get to go back-and-forth until you do. And if you want anyone to troubleshoot a mildly complex issue... well, good luck. Maybe one in ten of the people who wrote the code from your spec have that ability.
Some equilibrium has returned, but not before the damage was done - causing a lot of unfortunate misconceptions about the abilities or lack thereof for entire demographics of people.
> code school
For the most part, these are an attempt to create the same thing without the offshoring - 'teaching code' of that sort has been relatively common in offshore markets I've worked with in past jobs. I don't think that's their intention, but it does appear to be the end result.
[1] To the point where you're more or less pseudo-coding the solution
There kind of used to be acceptability for this - i.e. architects designing the class topology and sometimes even method names, and handing it down. From what I've witnessed, this started to fall out of favor around the early 2000's, if not before.
The problem (at least as I imagine it) was that this is inefficient when the designs need to change and one person gets a really soft easy job and the others get a lot of detectable grunt work.
Now we have the opposite problem - the "architect" title is kind of despised by people who know what it means, and everybody designs - but often those designs are at odds with each other, and usually too entwined with ego to come to compromises that make different sections of the code work well together.
There is a complex balance between finding the right level of top-down design and order and using all the assets of the team to make sure things are good and stable, and in particular, maintainable to folks who are going to be new to the code.
S/he must be good because s/he worked for X known company.
It's a pervasive bias, especially in tech where certain brands are lionised to the point of nearly becoming sacred. Brand association alone will get many a person through an assessment process with sometimes with the complete abandonment of any semblance of due diligence.
Remember the Scott Thompson scandal? Basic stuff like lying on your resume did not stop Yahoo! from making a pedigree hire. Must be good because PayPal.
We have to all work very hard to educate ourselves that we are all inherently susceptible to this bias.
I'm 50 years old and my day job is teaching teams how to perform better. I still code - love coding. But several years back I decided I could do more good in the world by helping multiple teams at a time than simply coding.
My "real" job is, of course, startups. I save for a while, then work on various startup projects. I'm learning a lot.
So now that my latest startup project is coming to a close, I'm thinking of where to go next. Instead of hands-on teaching, I'm seriously considering getting back to coding. Sit down, make something happen, look at a job well done.
The problem here is this: all I know how to do is make solutions happen for people in a dozen or so different technologies. I haven't spent time trying to keep up with the cool kids. C++? Sure. STL? Not so much. All the basic web tech (HTML, CSS, Javascript, etc)? Sure. Angular/Meteor/etc)? Nope. F# and OCAML? Love me some functional programming. Haskell/Erlang/etc? Nope. SQL Server, MySQL, some Oracle? Yep. NoSQL, Cassandra, Mongo? Not really. Once I knew enough to get the work done, well, I just got the work done.
There's a difference between coding to get things done and spending time with toolkits and frameworks because they're popular in the market. Back when I was a senior programmer, one of the most important things I did was try to guess what the cool kids would be doing in 3 years -- then study that and get some experience. This paid off over and over again. As somebody who just wants to make things happen, that's not a priority.
This leads me to my second observation, from sitting on the other side of the table looking for developers and working on staffing models. The dirty secret of the tech industry is that nobody has any idea how many developers they actually need. There's so much variability in teams, and you can break the same work down so many ways....there's a lot of risk. (Yes, there are several heuristics you can use. Insert long discussion here about how they're only heuristics.)
So at the end of the day, you have a lot of companies that want to be trend-setters chasing after what all the companies think are the cool kids -- the trend-setting hires. I remember sitting down with a SV CEO a while back talking about his 100-person shop. Everybody in the place had some cool-kid story attached to them. The place was a mess, but it was a trendy mess.
At times, I am not convinced that these companies would do much better with some kind of "sweep the street" approach to hiring, vacuuming up a huge number at a time and taking them through some structured filtering/training process. I've even thought through how such a model would work. Haven't found anybody willing to experiment with this yet, though :)
As arbitrary as the system is, I'm not sure its any better or worse than any other system. And the simple fact of the matter is that buzzword-based, trendy hiring has been with us for decades. I doubt its going anywhere soon.
> At times, I am not convinced that these companies would do much better with some kind of "sweep the street" approach to hiring, vacuuming up a huge number at a time and taking them through some structured filtering/training process. I've even thought through how such a model would work. Haven't found anybody willing to experiment with this yet, though :)
Didn't IBM and a few other big iron shops do this in the 50s/60s with secretaries? iirc, they could apply to be programmers and would get trained.
"Contractors are generally not the strongest technically"
Where does this come from? I actually see a contractor as someone who had experienced way more "war stories" than the guy who has been sitting in the same chair for 10/20 years. As a contractor, you are exposed to more technologies, more business sectors, different working cultures.
I'm biased (being a long-term contractor), but I would agree that this statement is exactly wrong.
Breadth of experience counts and you can't get that without having 'been around'.
On the other hand, if you're hiring a contractor who has had lots of very short contracts, that should raise a warning flag.
Quite simply tho, why would any good contractor want to go permie? the attraction for me is simple... I get paid twice what I would otherwise get in a permie position.
Why would it raise a warning flag? I'd move to Australia for a one-week job, but I would hate moving to another town for six months. [I'm in Europe.] I just can't see any drawback to short-term contracts.
Certainly in my experience, all my contracts have been a minimum of 3 months, but averaging around a year and going up to a couple years or even more if you include return contracts.
Its not necessarily the length, but the lack of extensions that is a warning sign. Most projects do not last a short time so a lack of extensions indicates a problem.
I worked for a company which extended my contract to two years, but I've been in five or six different projects during that time. All but one (Avon AU which is ongoing) have been completed successfully.
I am really biased towards short, "solvable" projects :)
Contractors go back to permanent jobs for lots of reasons.
Re-locations, change in family status, social reasons (sure does get lonely working from home), aiming for managerial roles, a more stable income (even though less per hour) being able to focus on programming(without having to hunt for new contracts after each project is finished).
Yeah, was being slightly tongue-in-cheek when I said that. I know many fellow-contractors who have turned permie, but for me personally I've gained so much professionally, experience-wise and of course monetarily that I would never go back to permie-land.
I've also been lucky in that I've never been forced to work away from home and have always gone from one contract to the next with no gap.
In the case of Microsoft which is the context, this is generally true because the hiring for contractors is less rigorous (and pays less) than SDE. Most v-dash's I know spring for the opportunity to re-interview and trade up to FTE for benefits/comp and longevity of course.
"Consulting" or "contracting" can refer to different kinds of work arrangements. One of these is what's called "staff augmentation."
Large companies with huge teams of full-time employed software programmers will often hire contractors to fill gaps. These contractors are typically contractors-in-name-only: they work under exactly the same conditions as full-time employees but with a worse tax situation, without access to benefits, and without eligibility to receive equity or cash bonuses. They are often contracted through intermediaries who take a large cut. These contractors can be fired more easily than their full-time employed colleagues, and they may often work on time-limited contracts that cannot be renewed. (They often do not count against a manager's allotted "head count.")
These contractors are typically in this position, because cannot get hired as full-time employees. They often jump between contracting jobs until someone gives them a chance or until they manage to get a client to "convert" them to full-time.
Staffing firms are in on this. If a recruiter sends you to interview for a contract role at some large company, it means they don't think you could get a job as a full-time employee. Hiring managers also know this. If they see you've only ever worked as a contractor, then they will assume you don't have what it takes to get a job as a full-time employee.
Agree that this is the exact opposite of my experience as a contractor in the UK. I work as a contractor because the money is much better and because I have access to a wide variety of interesting projects. In the UK the contractors have the power - the companies I work for would hire me full time if they could.
Similar situation here. The company I'm currently contracting for mentioned they struggle to find experienced Scala devs who will interview for permanent roles.
I think this is an U.S thing where this kind of division has sprung up - so you have
contractor ("temp", "paid less")
full-time employee
consultant ("paid more")
There is a pretty important distinction here -- We have seen in the US consulting market (at large corporations) an influx of 90s style contractor arrangements for staff augmentation. This is basically the counter to failed outsourcing efforts. These contractors almost entirely work for large groups like Robert Half, Tata, Infosys, Tek Systems and others.
We also still have a very very strong consultant labor force making 2-3x what W2 full-time employees can pull in. These consultants generally work through smaller consulting firms that take smaller cuts for the placement/handling billing and invoicing.
Perm - Mid level benefits + Pay (maybe options in a startup)
Contractor - Individual with their own Ltd company, pays less tax and much higher take home pay but without any benefits.
Consultant - On-site via a supplier on a framework of some kind, however, often a permanent employee of the supplier with the supplier cashing in the margin.
At least 50% of the tech workforce in companies I work with or where peers are at in London are made up of contractors, especially in Banking.
Totally agree with you here. The contracting market in the UK (particularly London) is much more lucrative than relative permanent roles, even when their benefits are taken into account. It's actually more lucrative on tax here, though the Gov't are trying their best to change that.
It's also my experience that you get what you pay for, contractors in the whole tend to have a much wider breadth of knowledge from various sectors and hit the ground running whereas I don't tend to see the same appetite from Permanent employees (in most cases!).
A good way to know what kind of contractor they are is to look at the vendor. Robert Half, Tech Systems etc probably augmentation. Smaller vendor, or independent. Better chance of "Specialist".
I've worked for Fortune 500 companies around here. The senior full time employees have been working at the same place forever, so their skills are often outdated. They get paid a lot less, but they are often fine with that, because the place gives them the one thing they want: status. Changing jobs means you might not get that status. In comparison, the top contractors get far better pay, have worked in more than one or two places in their career, and are the guys you want to hire.
It's probably different in the bay, where big tech companies have little trouble paying 200K+ compensation packages, but around here, just contractors do.
Why do the contractors get paid more? Because they can get paid without talking to HR, or meeting any pay bands. Last year, I worked with other three contractors, whose names anyone in the Scala community would recognize. 200-300K a year range. The best full timer they had (which just quit, after being told how silly he had been by being full time), made 110K.
Being well known means that switching to work for TrendyCo isn't difficult though.
I'm a contractor for a large research facility. The arrangement is almost exactly as you describe, but I am a W2 employee. They hire researchers with phds and such, while offloading all software work to contractors.
I took the job a year ago with the hope its name recognition would be helpful in the future but I had no idea there was such a stigma around contracting. I'm starting to look around again, so I guess I'll see how it effects me.
There are two types of contractors and they lie on either side of the skill bell curve. What you describe are the lower end contractors. Top end contractors refuse to take full time. They run their taxes through S-Corps, come in to fix the most challenging problems, and big-co's get in bidding wars over their next contract.
I think in general, you are correct about the skill difference between contractors. But there is more to it than just that. Low end contractors don't choose that path, they end up their because they either, like you said, are low skill, or because they made career mistakes and need to get back on track. I would definitely fall into the latter group.
You absolutely nailed it on the head. I am one of these "staff augmentation" devs and it has been bothering me for awhile now. I would love to try my hand at one of these "trendy" startups as a full-time employee but I am pretty much the opposite of what they seem to be looking for:
- non-technical degree from a local state school
- 35+ years old
- only have a couple of years of professional software development experience and most of it as a contractor/consultant
- not white
- most of my work is back end bug-fixing, maintenance, being in an on-call rotation, and occasionally integrating some system to some enterprise database
- buzzwords in my resume (Java, Borg, RPC, Hibernate, SQL, XML, Eclipse IDE, DAO, DTO, etc) probably scares off the young devs because apparently anything remotely related to J2EE or enterprise is evil
- my real employer is one of those Indian staffing firms
I tried one of those "dev auction" sites (Hired.com) one time. The "talent advocate" assigned to me got really excited upon hearing I am currently a contractor at the BigCo. in Mountain View, CA. She immediately put me up on auction and I guess her enthusiasm got to me since I got excited as well when I started seeing all these cool San Francisco startups viewing my profile.
Then both of us were disappointed when none of the startups were interested. The auction period came and went. I had zero offers to chat on the phone despite dozens of views. She was nice enough to give me another auction round and I went for it. Only a half dozen new views on my profile that time but at least I got one phone interview out of it. The talent advocate was a bit confused by the whole thing and couldn't understand why most of the startups didn't even want to speak to me. She did offer to personally reach out to some of the startups on my behalf but I knew what happened so I politely bowed out of the auction.
So I guess I have this stigma now and I know it's only going to get tougher the older I get. I want to fix this and hopefully move to a full-time product development role before it is too late. Should I quit my job and go back to school? Join a coding bootcamp or "hacker community"? Continue working as a contractor and keep applying to startups on the side?
As the article suggests, I think it's just code. The recruiter is being subtle in case the employee overreacts and passes on the message to the candidate. Contractors are expensive, more experienced, less malleable and can give other employees ideas that there's an alternative.
Graduates and junior developers will burn themselves to hell and back trying to impress their employer because they don't know any better. That includes people who have never worked for a proper business (i.e. not a VC backed startup).
Uhm, I remember hiring one contractor twice. The first time for $50/hour. The second time for $400/hour. He wanted more, but I was able to talk him down to the same rate as the other contractor. They both worked in crypto.
As for me, after co was acquired, I was a FTE for one day, with great benefits. But, the lawyers wouldn't clarify a claus in the FTE contract that would exempt my IP. Was I assigning it or excluding it? Their answer was "either". Before that, I was working for 4 days per week for the startup and 1 day per week on my own projects (at 4/5ths the pay).
I know plenty of indy developers that are absolutely brilliant. Sometimes they take on side projects as contractors.
Depends on the area of expertise and how you buy that expertise.
Many contractors are really installers, and are great at bootstrapping a product or service. But... they know little or nothing about the actual running of the thing they setup. They don't get how to integrate their product's magic with your ITSM system, or what metrics to monitor, etc.
On the developer side, I've seen more than my share of consultants who are high-priests of whatever methodology/language/framework religion they preach, but have a hard time delivering value.
"Contractor" can mean, entrepreneurial person who's made a career helping a range of companies who's internal developers couldn't get the job done.
Or it could mean, someone that a company took on with a day-rate because they needed a warm body, but didn't want to actually hire them either, in case someone better came along.
It comes from the incentive structure of the recruiter and says less about the potential hire.
Recruiters are often paid a commission for every one of their successful hires and that commission is often split between an immediate payment and a payment (or payments) when the hire hits specific milestones (6mo, 1 yr, etc). Recruiters don't like trying to fit contractors into non-contract roles because they're worried about the contractor leaving before the recruiter's remaining commission is paid. If that happens, the recruiter puts in just as much work and gets paid less. They'd rather discard those resumes that they consider to be riskier and focus all their time on people with a history of staying at least 2 years in every one of their jobs.
There have been a number of posts about hiring practices lately. And a lot of them contradict each other. My conclusion is, that people hire people that are similar to themselves or similar to how they would like to see themselves, and the whole hiring process, the style of interviews and coding tasks and the sources from which they hire, is based upon this model.
A company founded by Stanford CS students will focus on ivy league CS students; friends of mine have a pretty successful consulting company and none of them has a formal CS background, but years of experience delivering complex software; they focus on guys that can deliver, regardless of background. Some people never went to MIT, but have a deeply ingrained wish that they would have - by surrounding themselves with MIT grads, they suddenly generate the wanted association.
The Ivy League is actually an athletic conference, believe it or not, and consist solely of schools in the Northeast.
The schools are Brown University, Columbia University, Cornell University, Dartmouth College, Harvard University, the University of Pennsylvania, Princeton University, and Yale University
I assumed he was using it as a metaphor, because the actual Ivy League schools aren't especially known for computer science. So "ivy league [of] CS" as in the top CS schools, not literally the Ivy League schools.
As a Midwesterner from the heart of Big Ten territory, I am often disappointed that Carnegie-Mellon, Northwestern, Purdue, Illinois at Urbana-Champaign, Michigan, Wisconsin, Minnesota, Ohio State, and Indiana are seldom mentioned in such lists, despite all of them being world-class schools for computer science. Sure, the Ivy Leaguers and Californians, and the closer-to-the-coast schools are remembered (except maybe Georgia Tech, Maryland, Pennsylvania, Penn State, or Johns Hopkins), but it's like the space between the Appalachians and the Rockies is one vast flyover wasteland not worthy of notice (or venture capital).
Rice, Texas A&M, and Texas at Austin are also ignored pretty often, but Texans can be offended on their own behalf without my help.
As another person from Big Ten territory, you might as well add University of Washington to that list. I often find interesting work (research, course assignments, etc.) from there, and it's typically ranked highly in CS, but it also seldom is remembered.
>by surrounding themselves with MIT grads, they suddenly generate the wanted association.
Could you clarify what you meant here? Was it that 1. those who surround themselves with MIT grads discover an ingrained wish that they would have gone to MIT, or 2. that they satisfy a pre-existing wish to have gone to MIT by instead surrounding themselves with MIT grads? In the case of (2), are these effects tangible as they might expect?
The latter. Having been to quite a couple of interviews with hiring managers, most of them interviewed in a way that they would have hired themselves, so case number 1. Case number 2, hiring people that they subconsciously wish themselves to be, is coming more from an observation of all these hiring practices posts here on HN. The latter would be quite a nice empirical/psychological study, though I fully expect such a study to already exist.
Disclaimer: I'm living in Germany and nearly exclusively interviewed in Germany so far. There's nothing comparable to the top US schools here, so school reputation is probably much less important than in the US.
>
Disclaimer: I'm living in Germany and nearly exclusively interviewed in Germany so far. There's nothing comparable to the top US schools here, so school reputation is probably much less important than in the US.
Most hiring processes spend gigantic amounts of effort to see how a candidate works as a member of the team, without actually having the candidate... work as a member of the team.
I suspect that the reason why, is that so few engineering teams do pair programming full-time, complete with daily-or-more rotations.
Pairing gives you the ability to spin somebody up rapidly enough to see how well they do on real code, and at the same time get a good read on personal fit from multiple team members.
Pivotal is shockingly good at this. You start with an hour-long pairing exercise over the phone. If that goes well, you come in, sign an NDA, and pair on two different projects, with a block for lunch in the middle.
That's a grand total of ten hours of screening time.
This process isn't fool-proof, mind you. But it does do a good job of answering the most important question: Do I want to show up for work, tomorrow, and start working with this person?
Perhaps just as importantly, it gives the candidate enough information to answer that same question for themselves.
Nothing tells you whether or not you want to work somewhere, like actually working there.
Great answer. When I see these ideas floated around, I always think that these companies will never hire people who value their time and have at least a decent job. When a company comes to me with these great "deals" the first thing I say is thank you very much and move their emails to my spam box.
I get the sentiment behind this, but bear in mind that interviewing is a two way street - and the company is often spending a lot more on it than you are (of course, they can better afford it).
That's worth possibly negotiating the amount of time or staging earlier parts with less impact.
I wouldn't say no to an interview that is going to burn a day, but I also wouldn't go to one without a pretty good feeling that I was likely to accept an offer if it came.
I mostly think of interviews as at least as much of a chance for me to evaluate them as the other way around (even the way they choose to interview tells me a lot).
you're asking me to feel bad for a company that probably has millions in seed funding for investing a day in a new hire? hah, no, not going to happen. I (and probably most people here) already have a job that pays me for the work I do, this company can either do the same or they can walk. The one thing that's not going to happen is for me to pity them for the money they are investing.
No, I didn't ask you to feel bad for them. I only pointed out that there is at least some symmetry in the situation. I don't know where you got the very odd idea that pity is/should be involved.
There is no reason that you can't have a mature interaction with a company where you both agree to invest some time and effort in a process that could benefit both of you. If it looks like a bad risk to you, don't go. If you are doing a competent job of this, you should know what an interview process looks like before you agree to the interview. If there are aspect of it you aren't sure about, you should ask about them. If their reasoning doesn't convince you - respectfully decline the interview.
The most valuable thing about an interview process is an exchange of information. Thinking about it too much as a time-for-money trade off can miss this point. Of course, if you can find a more time efficient way to exchange the same information, that's good all around.
In my experience, pairing interviews usually falls into two categories: one where you're tapping away at a problem while your interviewer is doing a work assignment (but please ask me questions), and the second is where the interviewer is grading you (and interjecting) line-by-line rather than actually participating. It's rarely the case when pairing goes as it should i.e. a collaborative work process.
I agree. I interviewed with Pivotal, and it was fairly distracting for me to be asked to work on a problem where the interviewer clearly knew the solution, and did all the typing. It wasn't fun.
It was a gigantic waste of time. Some whiteboarding would have been adequate; it would have been better, even, without all the weird keystroke errors and unwritten expectations on the codebase.
While I have great appreciation for problem solving and human interaction, pairing on a non-customized computer, on a random code base, with someone you met 5 minutes ago is absolutely the wrong way to go about interviewing.
I've done work sample tests: they take a lot of time (time is money), and I don't really have enough invested in this company to want to work for free. I'd much rather do a work-sample after the onsite - let's at least determine if we are comfortable around each other before I start investing hours of my after work life into this thing.
> I'd much rather do a work-sample after the onsite
Pivotal Labs and Pivotal Cloud Foundry teams default to 100% pairing.
What you experienced is basically the actual job. It's perfectly OK that you didn't like it, lots of people don't want to work that way once they've tried it.
But it wouldn't make sense to find potential pair programmers by not pair programming.
However candidates for Labs will see stuff our clients consider commercially sensitive (sometimes their mere existence is commercially sensitive), sometimes candidates for Cloud Foundry will see stuff that is commercially sensitive for Pivotal.
Mind you, I did a round of interviews a few years ago and everyone had an NDA at the door. I read them and none of them were silly, so I signed them.
Almost all silicon valley interviews are a 1hr phone screen and a full day of interviewing with lunch in the middle. What they seem to be asking seems to be about the same amount of time. And TBH it's less intense sounding since it should be a mostly normal work day.
> Arrogant absurd process with no basis or evidence in reality.
Do you sell t-shirts? I would like to buy one.
In fairness, though, most people who decide to take an offer have self-selected. Malleability might be one reason. Another could openness to new experiences.
If pairing and rotations is truly a critical part of how your company builds stuff then this isn't a bad approach. But there are plenty of productive coders who would struggle with this.
I think part of the reason people how those like themselves of that that's the only area where they have any confidence in their ability to assess skill. It's easy to say that this person is just like me, only a few years behind (or ahead!). But someone with a vastly different style and background is much harder to assess. Even with the same questions - as they're often kinda bullshit - it's hard to interpret the responses.
For a generic/flexible developer position I'd purposefully avoid hiring people from "brand" school. You'll definitely need to be over paying, and they will likely be poached.
I unless you need like a PhD who is the top expert in X (and you're willing to pay any price) .. it just seems like a bad bargain
Would love to put all these "no, THIS is how you hire properly" people in a (virtual) room together to hash things out. Someone is the most correct and the others are all more wrong than that person. We could go really slowly and break down all arguments etc. and see where things fall apart or when things contradict other arguments. And actually get somewhere
Success or failure of an employee is based on what the company does with them after they are hired. It doesn't matter how "great" an employee is when they come in. I've seen people come in as senior devs but you'd never know it. I've seen some employees hired and ran off when they couldn't clean up a hot load in record time.
I tend to agree with most of this (university, GPA, subject, blah blah blah). Bits of paper that are signals of arbitrary things (family standing, ability to take on debt, country of birth).
Anti-Windows bias doesn't really feel like an example of 'pedigree' to me, though.
I can't imagine programming on Windows. I can't even imagine using the OS. I moved away from Windows ~a decade ago and haven't looked back - it seems to be getting worse every year (the business model for W10 appears to be surveillance?).
Anyone care to chime in? What's the appeal of Windows in this day and age? To me it really feels like 'big companies use it so their programmers do'.
Regarding the attraction of windows.... market-size and momentum.
Remember a good softie is flexible... that includes getting experienced on all OSs, dont limit yourself... Windows isn't all that bad (and ignore all the silly surveillance scare stories).
Good software should be platform-independent, good software engineers should also be platform-independent.
The appeal of Windows for me is inertia. I keep using it because I can keep using my preferred programs, namely: Winamp, MPC-HC, and my video game library. Perhaps once my desktop with Windows 7 installed dies I will put Linux on a new one as the idea of using 10 terrifies me.
I did try to use Linux a few times in the period between 2007 and 2010 but I never found a desktop environment I liked enough. The file browsers and music players always left much to be desired.
I can't say much about how the programming compares as I stick to the command line mostly but I do prefer the thought of using the Win32 API over whatever might, might be available on Linux. Do I choose GTK and its copious unique types (even for integers) or do I force myself to learn the abomination that is C++ to use Qt? What audio subsystem do I use from the dozen or so that is around?
Video game library is a fair point. I use W7 in a VM for that, though I find myself playing games less and less nowadays.
I guess it's that I don't do GUI programming. I mostly produce software that does things directly (rather than enabling others to do things).
I fundamentally have very little use for a GUI unless I were producing software for someone else to use (e.g. QuickBooks or something).
I think that's probably the barrier in both directions. GUI users don't usually see eye to eye with terminal users. It's vi-vs-emacs all over again. :P
- binary compatibility for GUI applications over decades (try to get to run an application that was linked against GTK+ 1.x under a current GNU/Linux system)
- I personally prefer the Visual Studio debugger by far over gdb (but YMMV)
- there is exactly one way to write GUI applications against (WinAPI) - all other libraries as MFC, WTL are just wrappers for it. Try writing an X11 app against XLib or xcb and you will find out why Windows is better in this point.
- the same holds for other GUI functionality as clipboard and drag & drop (OK, admitted, it is a PITA under Windows, but far worse under GNU/Linux/X11)
- When developing GUI applications under Windows vs. say Gtk+ oder Qt under Linux: If there is some functionality, which is very low level (say, support for multiple mice): Under Windows for this there is Raw Input and under X11 there is XInput2. While the Raw Input feels integrated quite well into the style of the whole WinAPI, using XInput2 when developing using Qt oder GTK+ feels really foreign and I always fear that I will break something. In other words: When developing for Windows the APIs often look much more homogenous than under GNU/Linux where I personally feel that there are different libraries with different styles (but you might feel differently)
- I find the MSDN documentation much more helpful than man pages, but this might be my personal preference, at least I feel that when under Windows something is documented it is nearly always documented really well, while the quality of documentation varies a lot under GNU/Linux and is (for things that change more often) often outdated
- Also I consider it as a bad idea that many Linux devs consider code as documentation if by default most "user-centered" GNU/Linux distributions will not install by default the source code to any installed package.
- I personally prefer the slightly "overengineered" style of the Windows API instead of having to hack something (sometimes ugly) together if the API will not provide what I need; but this is again a matter of preference.
that is a great presentation. the degree to which everything is asynchronous in NT is awesome. it's a shame techies don't engage with it or dig in to it and just say that linux is better because it has a better shell.
Are the usual GNU/Linux shells still better than Powershell (being better than cmd.exe is trivial ;-) )? I'm really interested in a serious evalution from both Windows and UNIX nerds.
it also comes down to explorer vs anything else. I'm a huge fan of NT, but everything else is kind of mediocre. using someone else's windows computer recently I had the awesome experience of running an installer, being told I needed to install the ".NET 2.0 runtime", so I go to the control panel and select "remove programs" then select "add programs." why is add programs behind a button that says remove programs?!
the criticisms of the technology are skin deep but when you're using the system, you're interacting primarily with the skin, so...
Speed of setup, and a standard stack everyone knows.
You don't argue over which email server you use, you just setup Exchange.
You don't argue over nginx, apache, etc just use IIS.
It's also configured quite well out of the box, where as Linux you spend several days getting it all configured to perfection.
When you just want to focus on the business problem at hand, I find it brilliant. Where as in other stacks you get caught up in technology, for technologies sake.
> It's also configured quite well out of the box, where as Linux you spend several days getting it all configured to perfection.
Uhm, no. Most distros comes with sane defaults, perfection is something you work hard with to achieve on both Windows and Linux. Counter-Example: how to run get max performance out of 10Gbps Ethernet on Windows.
So far none of the responses have gone on a business tangent, yet usually business guys are the ones who decided on / enforced the MS-only doctrine. I assure you some MBA veep who's never touched a keyboard did not make the decision based on the accurate technical details in some replies.
The first one is hiring. Supposedly everyone knows windows, great hiring pool. I donno if I believe that anymore, but in the old days there was certainly no shortage of MCSE to hire. It doesn't matter if the UI for the OS and office software change completely every couple years because "everyone knows windows" so training costs only exist for alternative OS or alternative office software. When that linux genius quits he's irreplaceable, isn't he? That's a great position to be in if you're that guy (me), but business people hate that. To some extent this is a young person vs old person problem because college campuses (campii?) are owned by apple, not MS. MS is just to run the dorm xbox, that's all. This is strategic planning on the part of decision makers.
The second is financial embrace and extend. Once you got one windows server or a couple desktops, inevitable licensing agreements make the marginal delta of "another windows box" extremely cheap (maybe zero) vs the measurable costs of mac etc. BSA / etc audits will make your life a living hell unless you participate in this scheme. This is bean counting on the part of the decision makers.
The third is interoperability. Unless you're the worlds most boring company you'll be doing something weird and under the first topic above, everything weird has by default windows clients or drivers or applications. There will be a windows client for an eprom programmer or I2C driver. There might be alternatives but it will work under windows. Then see the topics above. You will need windows boxes... you just will. This is pragmatism on the part of the decision makers.
The fourth is CYA. Like decades ago, "nobody ever got fired for buying IBM" today "nobody ever got fired for buying MS". You could get fired for buying a mac and it doesn't work, or installing linux on a server that crashes, but no quality of service, including zero, is low enough to get fired for buying microsoft. No matter how badly the system gets powned or how much stuff gets stolen, you can't get fired if you bought MS products. Just doesn't happen. If you can afford it, and you like being employed, the decision seems clear from a risk management perspective. Cowardice on the part of the decision makers.
The fifth is support. Business people think we get support by calling a script reader in India who tells use to wipe, reinstall, and reboot, and furthermore that is worth money and worthy of making procurement decisions. In the real world we know we use google for support and non-MS stuff googles better. But business people like a risk management of a nice security blanket of telephone support from a dude with a nice looking certificate. Its not actually useful of course, but business people don't understand it. Business people think computer support is like medical support and you call 911 and get fixed up, but 911 converted to computer support would be a pretty funny standup comic routine. Essentially this is plain old ignorance on part of the decision makers.
.NET runtime and framework with Dev Studio are very very good. If you haven't tried for a long time, you owe it to yourself to take a look.
To me my stereotype - if you're in a corporate world and want developers that like users and spend a lot of time on complicated business problems - you're likely to see lots of "windows developers".
If you want some to write apps with lots of technical complexity and simple business logic, you're better off with "unix developers".
Not stuck on the CLI and text terminals culture. The Windows developer community knows its way around basch, Technet scripts and Powershell, but we rather use nice comfy GUI tools.
C++ (moving away from C), .NET languages, COM and nowadays WinRT offer programming paradigms that follow Xerox PARC ideas and drive forward developer experience.
Those kind of developer experiences being shown by Bret Victor.
I could say the same about Mac OS X developer experience.
For almost a decade I was a dedicated *BSD and GNU/Linux user as well, but they seem to be stuck being just yet another UNIX clone without any consistent plan for anything outside C and POSIX APIs.
> Not stuck on the CLI and text terminals culture.
See, those of us who use Unix & free software see that as a benefit, just as the literate find the written word to offer advantages over picture books.
With a keyboard, I am able to enter hundreds of discrete inputs: with a mouse or touchscreen I have one 2D input and a few buttons. With a keyboard I am able to have a conversation with my computer and my data; with a mouse I point and click, which isn't much different from pointing and grunting in human conversation.
See, some of us that were already into computers when Sun was a startup got bored of it.
Your answer is a typical example of UNIX CLI users that need to express themselves as being more intelligent than GUI users, while forgetting that some us do have enough CLI experience and decided to grew out of it.
I can use macros and key + mouse combos in FPS style across many GUI applications and if I ever need a CLI, Powershell or Terminal (Mac OS X) are just a click away.
Mouse use has a much higher risk of CTS and other work-related injuries. [1]
I've worked at startups and enterprise environments, and what has always remained constant at every Microsoft/Enterprise company is the troves of obese, unhealthy, arthritic middle-managers that can barely use a computer anymore because they got lazy and succumbed to using GUIs to get their basic work done.
Now, they are stuck on MS because any foreign GUI elicits a sudden "NOPE!" from them. They are constantly unhealthy because none of them have standing desks. They don't have standing desks because mouse use is extremely non-intuitive in such setups and in many cases dangerous [2].
By surrendering to the mouse and the GUI, my older co-workers are low-quality producers, exceedingly lazy, and otherwise slowly dying.
My console emulator has looked the same for the last ten years. I can SSH into any UNIX system and it's familiar to me. Innovation hasn't slowed me down at all.
> Yep that says it all. Hardly the example of what innovation means.
It appears you fundamentally misunderstood my point. Though innovation has occurred on my Linux system (and on my MS system) without fail for years, I haven't hard to learn bizarre new mouse movements and locations of menu items. Rather than slow me down, I can begin taking ADVANTAGE of innovations right away because they aren't implemented on CLI interfaces in a detestably-arbitrary manner.
Also, I don't get your first point. If people got unhealthy and unemployable due to something OTHER than the mouse and GUI usage, then so what? That doesn't negate my point at all. It simply shows that yes, more than one cause exists for obesity and brain rot.
It's been shown through years and years of clinical study that the injuries received at the modern office have to do with the movements associated with mouse usage. Keyboard use is easy to adapt safely to the modern healthy workplace (standing desks, padded surfaces for wrists and feet, etc.) Mouse use, on the other hand, barely works correctly for the seated and unhealthy worker, and works even less properly for the worker trying to make healthy changes.
> He said "not stuck on". I work the whole day in my dev env. I want something that hundreds of paid people created over several years at Jetbrains or Microsoft. I use CLI and a DevEnv. Just like some things aren't possible to input easily with a mouse, just as hard is it to visualize some things with a text UI. What is easier: adding a CLI to a polished graphical application, or making a polished graphical experience when you have a CLI?
This practice of hiring for tech glamour is bubble behavior. I'm an old guy, so I remember back in 1999 some nitwit hiring companies were demanding five years of J2EE experience.
Don't worry; if the overfinancing bubble bursts, or even deflates gently, people with salaries and get-it-done tech experience from outside the Silicon Valley reality distortion field will once again have an unfair advantage.
727 comments
[ 4.1 ms ] story [ 284 ms ] threadSo first off I try to convince them with everything I got. That usually works if I have solid concrete reasons. If I don't and let them do it there way. Sometimes it turns out my instincts were right and I get to learn exactly what was right about them. Sometimes it turns out I was wrong and his way was much more efficient and I get to learn something new.
Either way, it doesn't make the junior dev feel I am imposing my will on him. People tend to work harder when they feel it was their idea.
(Then again I seem to meet far more devs who are telling me about using shiny new tech X and how amazing it is, than ones who actually tell me about how a specific tech solves their use case).
Then they decided it was too hard, threw it all away, and just decommissioned parts of the application and run everything else manually.
Working under brilliant minds like that you can see why I quit.
Must have been really bad. Why not just hire you on as a consultant?
I'm not sure where the cutoff point is between this needs to be an app / this can stay as a script, but Powershell seems to lend itself to going either way. I can either incrementally replace C# functions with Powershell (while importing types and functions that I need) or incrementally replace Powershell with C# with the same method.
There's an easy way to stop that sort of attitude. The next time that a bug occurs, you tell that team that they must restore the code back to what it was previously, and provide diffs that show what they did so that you can review their rollback.
When they say they can't, you tell them that's their problem as they haven't implemented version control because they believed they didn't need it, and they need to go do it anyway. After they go through this exercise, you then offer to help them to implement version control.
In this day and age I'm not sure how you do persuade a team to use version control other than mandating it and sucking up the hostility while they settle in, but taking the opportunity to make a smug point while a team is firefighting isn't the way.
(except if they use clearcase, in this case I'm not taking the job unless I'm literally starving)
It is basically made to be sold to bosses by a high price
eta: ... and 10k+ karma on HN and SO ;)
Most of those are not as 'intellectually stimulating' let's say but it might be interesting to have something there
again, based on what i see on hn, github is actually falling out of favor (we'll see if they can reverse the trend [sic] with the newly released features; the search removal inspires little confidence).
twitter has been around for too long to be trending upwards, it's like facebook. the populace split into users and abstinents has ossified. it's even more pronounced with linkedin which has been around much longer.
i have no idea what's supposed to be trending in programming instead though. recently it's felt to me like a plateau of sorts.
I doubt that everyone knew C. Lots of big firms extensively used COBOL. Fortran was important in science/numerical computing. Pascal was popular. The list goes on.
Need I mention that for decades, there were lots of competing assembly languages, and that only in recent years we've converged on three? That Harvard Architecture and Von Neumann Architecture competed into the late 70s? That compiling a program on a machine with particular hardware could be seriously difficult? The conflict between big-endian and little-endian systems? Computing has always been full of heterogenous, competing technology stacks, frameworks, methodologies, etc. Why? https://xkcd.com/927/
And in the 90s in particular: do you really think that designing software for this so-called "internet" and newfangled HTML and JavaScript was free of trendy keywords?
And yes, it all started to change in the mid 90's with the advent of Windows and the web.
25 years ago, the challenges were much different. It's "Trendy" because its relevant.
MS Visual Basic was the new hot thing on the block. Delphi was the same thing but in Pascal. There were a bunch of database-with-front-ends like FoxPro and Access that you could build a windows program with pretty easily.
Actually, C occupied pretty much the same space as it does now: there's some people using it for serious stuff at serious companies, but it's not RAD so no-one else is interested.
1. Choose a different language for your next side project. 2. Step in the door with C#, try to help out on projects or change positions inside the company. 3. Attend hackathons, contribute to opensource projects.
A good programmer can quickly feel comfortable in any programming language. Recruiters feel more comfortable when you can actually show proof of that.
I personally know many languages a little bit, but I find writing my CV to target a specific stack results in a better responsive.
As an opposite to what, exactly?
> A good programmer can quickly feel comfortable in any programming language.
This is not true. It takes a not-insignificant amount of time to just learn to write idiomatic code, let alone making oneself familiar with all the quirks and idiosyncrasies of libraries and frameworks.
My first company (as a non-programmer) was very much like this. It was very corporate and they weren't willing to take a risk on cross training a hobbyist without the requisite boxes checked on a resume. It was frustrating but I also understand the CYA logic behind it.
There's someone willing to take a risk on you somewhere for some amount of money. Having a github with noob code in the language you are trying to get hired for helps. If you are just starting out, being able to show you want it bad enough to learn it off the clock is a strong signal vs "I'll start learning it if you start paying me" (which is...also a signal).
Ironically, I have recently started using .NET MVC for my projects since I think it's really great. It beats many alternative MVC-frameworks in my opinion.
In reality its a fast moving stack, that's constantly innovating.
The wast majority of people, who claim .NET experience can launch Visual Studio, then some wizards to generate skeleton of the app and then fill something to have a CRUD "solution".
They spoil it for the folks, who are truly experienced. The claims in the CVs are so maximized (Dunning-Kruger at the extreme), that it's simpler to just ignore .NET experience.
This is the ignorance. There are people who are pretty bad on other stacks as well. I know many competent .NET developers. And many terrible PHP developers.
On average the average .NET developer is more skilled then your average Python developer. This has about as much substance as your claim.
I moved from commercial .NET coding to startup-land a few years ago, and there's definitely a learning curve. I had to ditch Windows on my personal PC and start using Linux at home to really get the hang of it. YMMV.
I have immense issues understanding the platform and how everything work. For example, scheduling jobs is something I still don't fully understand.
The thing I didn't get (and still don't fully appreciate) is the power of bash - you can write almost-serious code in this!
And some of the standard CLI utilities (stand up awk) are like pocket universes of depth and complexity.
Windows probably has a lot of the same stuff, I hear good things about PowerScript, but it's not so standard to use it as a code monkey.
I miss Visual Studio sometimes. The mess of terminal windows and text editors that I code in now is frustrating at times.
However, I still use the terminal by using ConEMU with Git Bash to get git in the terminal because I don't know how else to do it. But you mention bash and awk, I have never in my years of experience really used these tools a lot either.
Maybe some small bash-script to backup or something similar, but nothing else really. You don't have to use it and most of the times it's easier to write a python script or what not.
I haven't really bothered to learn any PowerShell except "Update-Database" in the Package Manager Console.
I don't use bash a lot, but there is an expectation in Linux-land that everyone has some familiarity with it. That's not true in the Windows world so much. In my experience anyway. I'd be interested to see if a much more functional shell environment generates more use of it.
Just use emacs for everything! It runs in X, it runs in a TTY, it runs everywhere.
My own stack is st[1], tmux & emacs, with Firefox as my browser, within a tiling window manager. I have a single terminal open at any point in time, with tmux multiplexing the sessions. I use C-z as the tmux escape key, because it's easy to type and doesn't do any harm if I accidentally type it outside of tmux. I autostart emacs in server mode from a systemd unit[2] and run it under X.
Sometimes I use emacs's TTY or shell modes. This is something I'd like to explore more. If I did this, I might be able to have one window for both shells and text editing.
Regardless, I have one terminal window to rule them all and one editor window to rule them all. With Firefox tabs, I only need one web-browser window too (although I'm considering using emacs-w3m and/or eww more).
[1] http://st.suckless.org/ [2] https://www.emacswiki.org/emacs/EmacsAsDaemon#toc8
I recommend eshell
[1] https://technet.microsoft.com/en-us/library/cc738335(v=ws.10...
Typical hip startups use "tools" (frameworks, libraries, etc.) that abstract underlying platform to such an obscene degree, that it doesn't really matter, if the platform is POSIX-compatible or not.
I don't have evidence of a wide random sampling of "trendy" employers but based on anecdotes[1][2], I think it is.
Many trendy companies (a.k.a. "hot startups") overwhelmingly favor a Linux + open source stack. If the hiring managers at these companies see a resume with just ".NET/Winforms/WPF/ASP.NET", they perceive a negative signal.
Yes, writing a loop to display a list in ASP.NET should be Turing equivalent to writing a loop in Node.js/Golang but people don't think purely on equivalences of computer science concepts. They also think about "culture" and a resume that's exclusively ".NET" looks "corporate" and "enterprisey" instead of "cutting edge" and "hip".
My advice to potential job seekers who only have "MS .NET platform" as a skill: start a github profile with projects using Linux/Node/Golang/etc to help counteract the adverse cultural selection bias.
[1]https://blog.expensify.com/2011/03/25/ceo-friday-why-we-dont...
[2]"And the .NET developers are mostly enterprise folks who don’t like working in rough-and-tumble startup world. Remember, I worked at Visual Studio magazine and had a front-row seat." from http://scobleizer.com/myspaces-death-spiral-due-to-bets-on-l...
Being in the .NET ecosystem exclusively can also mean a reliance on IDEs and .NET-specific tooling to be productive (or things like Eclipse refactoring for Java).
And there's the simple fact that there are a lot of qualified candidates who do more than just .NET/just Java. Polyglot programmers are more likely to be flexible and be in the right environment.
Of course people can be good enough, but it's not just about the looks. Things happen differently depending on the tooling.
Now, the extended part of this discussion is that maybe it's fine, and companies should be able to onboard people into a technology. Because, hey, it's just programming right? But that could mean looking at a multi-month training session until you're looking at someone as productive as the guy who's familiar with the tech already. Not all experience in programming is equivalent.
An aside: I feel like this discussion usually has a lot of "web programming is easy" undertones (it hasn't been explicit but we all know what "trendy" means). But I don't think there would be as much of this discussion if it were something like "web-only developer applies to work on embedded systems with basically no C experience".
Actually, it's Mac on the desktop, Linux on the server.
If the hiring managers at these companies see a resume with just ".NET/Winforms/WPF/ASP.NET", they perceive a negative signal.
Run, don't walk, from doomed companies like that.
"Programmers who used Java or C# (when interviewing with us) go on to pass interviews with companies at half the rate of programmers who use Ruby or JavaScript. (The C# pass rate is actually much lower than the Java pass rate, but the C# numbers are not yet significant by themselves.)"
http://blog.triplebyte.com/who-y-combinator-companies-want
One reason I, and others like me have looked down on .NET developers, is that a large number of them aren't any good. I've meet brilliant .NET developer, some of the most talented developers I know are .NET developers, but the crappiest developers I know are .NET developers as well.
Some developers are completely ignorant in respect to computers, the Internet, algorithms and new technology in general, and they are almost exclusively working on Windows and by extension .NET. These are developers that can make code work, but take Visual Studio away from them and they cease to be developers.
It's by no means fair, because as I said, some of the best developers I know are .NET developers. It's just that I've never see anyone working on Linux/Unix be completely ignorant other languages, tools and platforms.
Ha, during my brief stint at a windows-shop after graduating, I did meet a few who couldn't get their heads around the concept of having a build happen without someone clicking a green triangle button in VS.
I wont argue about it, our experiences differ, and that's cool :)
Bear in mind, a lot of .Net developers don't even know it's possible to compile their projects outside of Visual Studio. Msbuild, Nant, csc.exe, "what are those?"
"Bear in mind, a lot of .Net developers don't even know it's possible to compile their projects outside of Visual Studio. Msbuild, Nant, csc.exe, "what are those?" There's probably plenty of java developers like that as well.
I've never seen Team Foundation Server in a .NET shop. It's either been SVN, Git or Perforce. That being said I think it's very individual, but many small companies won't pay for TFS, they barely want to pay for Visual Studio Professional/Enterprise edition
Now that the OS is no longer an issue, why isn't C# seeing more startup usage? Just look what StackOverflow does with it.[2] Startups shouldn't be judging developers for knowing it, they should be looking at it themselves.
[1]: http://www.ageofascent.com/asp-net-core-exeeds-1-15-million-... [2]: http://highscalability.com/blog/2014/7/21/stackoverflow-upda...
Now .Net is now also open source it would seem that the only proprietary part to the stack is Windows itself, and shortly .Net is going to be running on any platform.
Coming from a Mono background, this was very weird to me.
Very true. This used to be a point of contention where I work, but was easily fixed by having an automated process for getting our lawyers to approve OSS code (with a Nuget or Github URL). We still have to do it on a per-project basis (not per-license), but we're using lots of OSS code now and I've made a little headway on open-sourcing some of our own stuff.
These days OSS advocacy isn't that hard, especially with the hard facts demonstrated by CoreCLR.
It wasn't until I started college, where I had to use Linux to get my assignments done, etc. that my mind got stretched open. In three months I couldn't believe I survived in Windows for that long.
As an employer, the fact that someone has only ever developed in Windows and also uses Windows at home, tells me that at best they can appreciate unix and unix philosophy, but that it's unlikely they could build tools that do the right thing and play well in a unix environment, no matter how many years of experience they've had building tools.
But not only that, unix goes deeper and teaches you about how to do things inside your program, even if that part never talks to other programs. Things like do the dumb thing first; or when you have nothing to say, say nothing (e.g. `ls` prints nothing if no files found), etc. It's about mindset and values and those are almost always dictated by the environment. Also values cannot be looked up on stackoverflow and copy/pasted in 5 minutes. They take a long time to sink in and I can understand why an employer would want to skip that cost when hiring.
I had to really use it when I started to do automated builds, and since then it opened my mind on the value of command line and above all the unix philosophy, which I really consider as super important now.
If I had to hire, I'd be relunctant to hire someone with Windows-only experience, not because I think the stack is bad, but because it's unlikely this person adhere to the Unix philosophy and is able to write scripts for small tasks, and automate important tasks with scripts.
Also Windows teaches you values that are not appreciated by UNIX wizards: http://www.joelonsoftware.com/articles/Biculturalism.html
"Unix culture values code which is useful to other programmers, while Windows culture values code which is useful to non-programmers." (really: read the whole article!)
Joel, the author of the article you linked to, states the core value of Windows as being "useful to non-programmers" basing it on "By contrast, Windows was created with one goal only: to sell as many copies as conceivable at a profit". The former does not follow from the latter.
Microsoft didn't need to rely on usefulness to anyone to sell many copies, and they didn't. As for why Linux isn't non-programmer friendly, I beg to differ. Android is a prime example and the argument as to why it's not doing well on desktop, as Linus Torvalds puts it, is because no one ships Linux on their desktops. Microsoft has a lot to do with that. When and if they ever do, Aunt Marge will be as happy using Linux without even knowing it's Linux (does the average non-programmer know that Android is Linux?)
Unless she wants to print something... [1]
[1] http://www.catb.org/esr/writings/cups-horror.html
"1. Make sure the printer is turned on. 2. Connect the printer to your system... 3. A message will appear when the system is finished installing the printer..."
https://help.ubuntu.com/stable/ubuntu-help/printing-setup.ht...
There's still Linux underneath -- it's not stock Ubuntu, not by a long shot -- but it's Linux.
I'm pretty firmly in the Unix camp on this. 'I can't program' should be as rare as 'I can't read.'
What makes programming so special that it needs to be different here?
You might as well write, 'reading exists so most people don't need to read,' which would be equivalently true.
> What makes programming so special that it needs to be different here?
Because directing computers to perform work is as fundamental a skill in the modern world as is reading. Yes, there are people nowadays who cannot read, and there are some few jobs for them. But there aren't many, and it's not a good place to be.
Programming is not a specialised skill: it is a general skill with applicability in almost every field of human endeavour.
To some degree, it's true. Many of my colleagues never touched node.js til Microsoft started using it. Or Linux til Azure supported it. Or functional programming til F#, or git etc.
Java developers seem more comfortable searching online and piecing together a solution from oracle, apache common, other 3rd parties. It feels like they're better at critically inspecting packages for performance, applicability, adoption since they don't have a mother corp creating or blessing every product. nuget has helped a lot of .NET devs come out of their cave and explore the great unknown that is open source.
Hopefully Microsoft's recent reinvention of itself changes both this perception of .NET devs and whatever reality is behind it.
Couldn't there also be the reason that before Microsoft started to become active in Node.js the Windows support for it was really bad (bad Windows support is a typical problem of lots of open source projects; I mean: I could understand it if OS X (at least the same degree proprietary) support were similarly bad, but this is usually not the case).
Transitioning to Node+TS from .Net is fairly straightforward (setting aside the completely new tooling, building, open source package resources, etc), and you get microservices + much better performance with minimal friction.
Granted, large-scale systems of the Node variety are a world's difference from .Net, but that is not insurmountable.
The appeal is more than simply improving compatibility -- the whole microservices movement had been happening beneath Microsoft's noses, and this is their response to it. It is nothing short of impressive how they have expanded the .Net stack in order to remain current.
After all these years, I still am mystified by the whole technology/stack religion that pervades software engineering. I come from a mechanical engineering background. There's many ideologies on how to solve mechanical problems, but I would never hear "oh I see you have AutoCAD on your resume...we are looking for more of a life-cycle-engineering type of engineer" during an interview. A discussion like that would not even make sense.
The whole .NET/LAMP/XAMPP/GemStone/whatever solution stack you use does not define who you are.
I still consider myself a Mechanical Engineer who happens to be in the software engineering field who happens to choose .NET to solve problems since I'm highly productive on that platform.
I think it's less common now than it used to be but back in their heyday Java devs looked down hard on .NET devs. I think it's because MS visual IDEs, going all the way back to vb6, made a lot of people think they were professional developers just because they could create a basic crud program with a functional GUI very easily. This ended up promoting a huge amount of unusually bad code/coders to production environments and with that the bad rap .NET devs get to this day. The perception is that developers outside of the MS ecosystem usually have to be a little bit more erudite in the way they went about learning their programming language of choice.
I have strong experience in the .NET ecosystem and good experience with nix platforms and commonly related technologies (including Java and Ruby). When I interviewed for a part time freelance gig with a company on Upwork, they were concerned about my nix experience. They wanted to make sure that since they were a .NET shop, that I wouldn't try to get them to use any non traditional Windows based technologies.
I told them that I'm not partial one way or the other - I just like to use the best tool for the job regardless of where it's hosted. I did end up working for them for a short period of time, but it didn't work out long term.
While a company might pride itself in hiring generalists and "we do a bit of everything", very often they're just looking for someone to fill a specific position for a very specific need. Those needs might change in 3 months, (and then they'll be glad you're a generalist), but they're hiring someone to fill the gap NOW. This is especially true for startups, who have limited funding, believe in "move fast" mantras, are afraid of hiring someone that might need to be fired, and are afraid to take time for ramp up.
So in other words: The startups present plain lies in their job requirements and complain that the people that submit an application don't fit what they really want.
IMHO the easiest solution would simply to be honest...
I shouldn't have to make the window smaller in order to be able to read the authors post. If people find the formatting too frustrating, it's their problem as they want to convey a message to me, not the other way around.
That's what Firebug is for. :)
Personnaly I use that bookmarlet that help greatly for such pages (found it on a thread here on HN) :
javascript:(function(){var a = document.getElementsByTagName('body')[0];a.style.maxWidth=630+"px";a.style.margin="auto";a.style.padding="0 15px";})()
No, the essay is not about skills but about trendy pedigree. The examples of "pedigree" being defined by being at trendy company such as Google/Facebook/Apple instead of a stodgy one like Microsoft. Or the "pedigree" is graduate of top-10 university instead of a 2nd-tier one.
One possible solution to outsmart the flawed thinking about pedigree is a "Moneyball" approach that ignores schools or past employers.
Now back to scraping up some Python and coming up with a good project to throw on GitHub to show "Yes, I are engineer. Here is me saying 'shibboleth'."
I have done a bit of hiring and it was very hard to walk the line between effective use of my time and being open to people with all kinds of experience. (It was a junior position and I talked to some very junior candidates.)
But it is always important to remember that there is a human being on both sides of the table.
The reason I ask is that I've always been nervous about applying for jobs when I don't have every skill listed on the ad.
The advice I've been given is usually something like "Apply anyway. The job advert is a wish list, not a minimum."
But I'm still terrified of an interviewer opening my CV and asking how the hell I slipped through the screening process. Or even worse, being too polite to be so blunt and awkwardly going through the motions of an interview.
It would be awesome to get the perspective of an interviewer.
Generally few people are really good. And their spread out unpredictably across the landscape, so you have to just interview lots of people to find them.
I definitely wasted time interviewing underqualified people. But I wasted time interviewing some overqualified people too (because of salary/location expectations that should have been communicated up front). Actually, all of interviewing feels like wasted time (you have this burning need, and you want to fill it yesterday, or better yet a month ago, and yet you have to go through this process and learn about all these strangers, while the building feels like it is on fire).
Note that I said feels like wasted time, not is wasted time. It's a bit like learning a new programming language--you end up going down lots of blind alleys before you find the way you really want to go.
(All we could afford was non textbook candidates, and out of 3 hires, 2 worked out.)
As far as walking the line, as I got more comfortable interviewing, I always worked off a rubric, and set things up so that I could ease out of a phone interview early if it was clear that they didn't live up to their resume. Ended up doing the same thing with the in person interviews as well. Definitely screened by resume.
> I've always been nervous about applying for jobs when I don't have every skill listed on the ad.
This is a hard problem because some institutions write wish lists in their job reqs, and some write hard and fast requirements. And you don't know before applying. (And sometimes the goal posts in the organization move when their "requirements" meet the labor market.)
Personally, I'd apply if you have half of the requirements and feel like you can speak to the way you learn.
If you're interested in the company, I'd also take the extra step and do some work around it, whether that's writing a pain letter ( http://www.forbes.com/sites/lizryan/2015/03/01/how-to-write-... ) or writing a simple client against someone's external API or creeping^Hscanning LinkedIn, Twitter and Github profiles and finding out about the team and company.
Good luck!
Well that's your own fault as the job advertiser, and when I say "you", I mean almost all companies that advertise jobs. You almost never state the salaries to be paid, so tons of peoples' time gets wasted by pointless interviewing which gets followed up with insultingly low salary offers.
If you're a cheap-ass and want to pay a pathetic salary, you should state this in your job ad, so that non-deadwood people don't bother to apply to your job.
>This is a hard problem because some institutions write wish lists in their job reqs, and some write hard and fast requirements.
It's not that hard to tell the difference. When the word "required" is used, that sounds like a requirement to me. When a separate list is preceded by "nice to have", "plusses", etc., those are obviously skills that the company would like to have in a candidate, but are not hard-and-fast requirements. If the company is so stupid they can't write a simple job advertisement this way, and they use the word "requirements" or "required" when they really meant "nice to have", then they don't deserve any employees at all.
Honestly, I wish every job posting included the following: - salary range (and an honest one too, not one where they post a mediocre low and a great high, but then never actually offer the high number to anyone and just offer the low number by default) - work location - sometimes it's not that easy to figure out where a company's office is located, or they have multiple locations. The address is important, because it determines my commute time. - office environment - is it open-plan, cubicles, offices, shared offices, etc. Some photos would be good. - computing environment - do you use Windows (7, 8, 10), MacOSX, Linux (Debian, Ubuntu, RHEL, etc.)? A combination? (RH in a VM for development, Windows for email/Office). What version control do you use? (git, SVN, or (ugh) ClearCase) - standard benefits package: insurance company and regular single-guy premium, number of days off/year, etc. - a fairly detailed explanation of the actual work involved in this position: what technologies you'll likely use, what the project is, etc. - number of people in team, how team works together (Scrum/Agile, waterfall, etc.)
If companies would just post all this info with their job requisitions, it'd save everyone a lot of time. I see posting filled with paragraphs and paragraphs of flowery crap about how wonderful their "collaborative team environment" is or their corporate philosophy or whatever, but the things I listed above are what are important to me in a job and what will determine if I'm happy in that job. Spare me the flowery prose about how wonderful your company is; I'll make that determination on my own.
When I buy a car, the person selling the car sets the price. I can take it or leave it.
When I rent a house, the landlord sets the price. I can take it or leave it.
When I'm selling my labor as an employee, why am I not the person setting the price that the company takes or leaves?
I'll tell you why, because the first party to state a number in any negotiation is at a disadvantage, because the counter party suddenly has more information.
Now, there's a valid case that the employer/employee relationship is asymmetrical enough as it is (one employer -> many employees) that the company should give up that negotiating point, but if I ran a company, I'd want to justify that. (There's also a case to be made that, especially with knowledge work, the employee has an asymmetrical advantage because they know how hard they are working, and it's hard for the employer to know.)
That said, when I enter into a new engagement to sell my labor, aka an interview, I do my best to make sure they want to buy my time before I set a price. It's negotiation.
Edit: I love the parent comment even though we disagree, upvoted.
That's exactly why I think the employer should give up that negotiating point.
The other reason is that employers are constantly whining about how they don't have enough engineers, can't find qualified people, etc., and then lobbying Congress to do something about it. Employees don't have this kind of political power.
Finally, I wouldn't mind if negotiation were simply eliminated with job salaries. You don't negotiate with the cashier at Walmart about how much you're going to pay for some vegetables or a TV. The price is the price, take it or leave it. It'd be better if everything were that way, so that consumers could compare things more accurately. There are many nations where the posted price is not the actual price, and haggling is expected and normal, even on something as mundane as groceries. Without exception, these nations are backwards and economic disasters. There's a reason for that.
That's a big claim that you make very authoritatively. You should back it up, or change your wording to better express that you're making a hypothesis without much evidence.
I guess others can provide more data points that points in this direction but I'd also appreciate counterexamples.
What solipsism is objecting to ("big claim"/"hypothesis") is the statement "There's a reason for that", which implies that there's a causal relationship between the prevalence of haggling and countries being "backwards and economic disasters" (for which there's been no evidence provided).
The candidate can show the ability to do whatever work the company may require, but if that work does not increase revenues in some way, it will not be able to keep the worker employed indefinitely. Obviously, there's a lot of room for speculation here.
The worker has a general idea of the average amount that many other companies might expect to value the work of similar workers. So the prospective employer has to signal that it can monetize the work more effectively than the median company to attract better than the median quality of candidate.
If your company is building yet another CRUD business app, you do not need above-median skills, nor could you afford them. If your company is building a new, Wall-Street-killing trading platform, you need the 99th percentile of skilled workers, and should therefore be offering 99th percentile pay, because the work will eventually be worth billions of dollars.
The candidate knows how much their labor is worth on the open market. If the prospective employer does not know how much the open position's work will be worth to the company, it really shouldn't be trying to fill it until it does know. If you want to reach the higher-quality candidates, you have to send a clear signal that they will not be rejected for wanting too much money, which happens all too often with companies that need to pinch their pennies or extend their runway.
There are companies out there that will hang up the phone if you say $100k. And there are also companies out there that will struggle to hold their poker face at being offered such a great discount on an employee. You won't necessarily be able to determine which is which before you apply.
When the company does not say up front, it is implicitly saying "we will pay you exactly what you are worth, as determined by negotiation, with no predetermined limits." If they wait until halfway through the second phone screen to bring it up, and then say, "that's more than we can pay", they are wasting the candidates' time.
That is why the company should lead with their salary maximum.
The analogy is not a fixed price on fungible goods in commerce. The candidate has a unique artwork, to be sold at auction. The auction house would very much like to establish that potential bidders have at least enough money on hand to meet the prospective employee's reserve price before giving any of them paddles, especially when the bidding procedure can last several weeks per bid. The candidate does not want the reserve to be known, as they would prefer to get a higher price. Likewise, the prospective employers do not want their maximum bids to be known to their competition. But as they can only complete the purchase by making the highest bid anyway, their wishes do not matter one little bit. You have no business bidding on a Van Gogh painting with only $5k in your pocket, looking for something nice to hang up in a hotel room.
The employer is the one that makes the offer. They are selling the pile of cash, and the employee either buys it with their labor, or leaves the offer on the table.
I'm the Grishnakh who used to be an orc captain but was stepped on by an Ent.
This is exactly what I look for when I interview for a new job. It's inclusive, shows humility and a willingness to learn through others' experience. Any other attitude belies an employer that's arrogant at best, and at worst nurtures a narcissistic blame culture.
Of course there is. At a basic level, that's what hiring is.
With this now-popular attitude that "1 bad hire is worse then 100 good ones" or something like that, how could it be anything else?
Imagine the pressure that puts on the hiring teams.
(Or at least, it's so obviously right that it can't possibly be the "now-popular attitude" you mean.)
I'll keep the Eeyore person that self selects tasks and issues that are of low complexity (say, 2 on a 5 scale) than the self confident idiot who keeps asking for 4/5 stories when they're really only good at 3/5 on a good day.
That jerk is creating 5/5 stories that I have to burn myself out on (they are either notably quiet or loudly in denial when this happens). I don't care how much project management or the marketing guys like him, even an empty desk would be better. At least an empty desk is predictable.
Most companies demonstrate this with H1 contractor hiring. They usually don't bother with the cool kids club screening in those situations. One of the smartest people I ever worked with had a degree in Chemical Engineering from some mid-tier university in India that I never heard of. That guy would never get hired as a FTE at that company, because he didn't drink and didn't have the cultural "fit" nonsense.
Various things may point one way or another for this, but it is a mistake to assume [insert working at a particular company] is an indication that someone has to have the skills, as well as to assume someone not having [insert pet qualification] is an indication that someone does not have these skills.
Sadly, there is a severe lack of this skill applied in our profession, and it is probably the costliest common mistake I see.
i.e., "a customer reports his website is running too slow. describe how you would identify and solve the problem."
it's a good sign when they start asking you follow-up questions, like "is it load balanced? is there a database?". it's a bad sign when they say, "just restart the server".
IMO Its a good exercise for problem-solving, and plumbs experience and terminology. I'm not so sure you learn anything about the subject's actual programming skills?
in my experience it's the other things that will make or break an employee, like whether or not they have an actual work ethic, or is a closet drug addict, or gets too drunk and touches women inappropriately at company events.
these are things you can't test for in an interview or background check, and i find it strange that nobody ever mentions this kind of stuff because personal problems are the most common kind we run into. it's rare to hire someone totally incompetent if you yourself have extensive experience in the work you're hiring them for.
[1] super-anecdotal self-selected data points from hiring and conversations
http://chimera.labs.oreilly.com/books/1230000000545
But if anyone thinks that either of these questions is testing "critical thinking skills", or "problem solving", then I would like to hear in what way. Both of those seem to me to be pretty much archetypal "verbatim-recall questions".
Experience and exposure and education and ability to brute-force recall all of the above is valuable. But it's pretty much the exact opposite of what beachstartup said (s)he was testing, and there is zero "problem solving" in the "what happens when you hit return in a browser" question.
I'm a little bewildered how anyone could confuse these diametrically opposed aptitudes.
But I'd just like to protest, my answer was not 'brute-force recall'. It was simple experience. See, I've written code at all of those levels. None of it was booklearning.
I don't honestly care if it was booklearning or not, and I don't see what it has to do with my kvetch. I'm happy to believe you that it was learned from experience.
What does "brute-force recall" mean to you? To me it means that you are only repeating things that you knew before the question was asked, as opposed to dynamically generating new knowledge during the time that you answer. Whether you originally got that knowledge from books, or from experience, or from Mr Spock doing a mind meld, it's still memory, as distinct from problem-solving or critical thinking or perhaps more generically we might name "wit" as the counterpart of memory.
Again, I'm absolutely not knocking this form of knowledge; memory without wit is perhaps inflexible, but wit without memory is impotent. Memory is a good thing. Memory makes up the much greater half of expertise; this is why seniors get paid more than juniors (would you rather hire an IQ180 noob who knows nothing about the problem, or an IQ120 worker with 20 years of relevant experience?).
But I'm getting pedantically wound up about this minor nit: both you and beachstartup gave examples of interview questions that are tests of memory, and framed them as tests of problem-solving. If problem-solving is the thing you want to test, those are terrible interview questions for that particular purpose.
I guess that's why I get hired by sarcastic people a lot.
Thank you for bringing this up. No matter how good or bad a candidate is, that person is your social equal and deserves basic respect.
I feel strongly about this ever since the humiliation I faced at AirBnb,
https://news.ycombinator.com/item?id=11291155
This could happen to anyone.
It was for a UI Engineer position. I did very well on all of my technical coding challenges, with the exception of an algorithm question, which I still managed to complete once the interviewer pointed me in the right direction.
I was later told that while everyone really liked my culture fit for the company one of the interviewers with whom I sailed through the challenge thought I did mediocre, and the algo question asked said I "really struggled". It was pretty devastating but I just chocked it up to me needing to dig in and study harder.
I've not done any validation studies on the answer, but it's certainly the question that has led to the best conversation.
I've looked at going in the other direction - onto .NET. There's a lot to like about the framework. But I can take a job on the JVM and be paid like the dev with 7 years' experience that I am, or I can take a job doing .NET and get paid like a fresh grad, despite the two systems being about as similar as it gets.
And I've watched plenty of people in suits be hired at trendy startups. Maybe the bar will be a little hire, but it's not an instant firing the way wearing a t-shirt to many companies would be. A lot of tech companies really are better at this kind of thing than other companies; there is always room for improvement but there's also room to celebrate the things we do get right. Stop listening to DHH.
I eventually turned them down in favour of another offer.
Specifically, if it doesn't say AWS in the first sentence, you're doing it wrong.
And here is the rub. There are certainly many undervalued gems among UnknownCos and UnknownDevs but also many abysmally bad workplaces and programmers. So you either have some inside knowledge about them (a referral, an acquaintance working at UnknownCo), have some magic method for separating the gems (like tptacek claims to possess) or it is just too risky to consider them.
It is amazing to me that almost nobody does this, but: almost nobody does this. They have programmers write code on a whiteboard, or on some whiteboard-coding site; they have them do programming puzzles ("solve Towers of Hanoi non-recursively"), they have them talk about code, or, more likely, computer science trivia. They'll have them "pair off" with one of their own programmers and "fix a bug". They'll have them work as a 1099 for a month to see if they're any good.
In reality, most companies are trying to hire on trendiness; they want people from the right schools and/or the right cohort of companies. They're aggressively courting friends and colleagues of their existing team, and the special people get very different interviews than everyone else. The actual technical evaluation is mostly a facade.
Maybe this is an US thing. I changed jobs last year and nearly every single recruitment process involved exactly that, after a remote interview them giving me a small project worth 2-5 hours of work and then going over what I produced one week later. This was for companies in central and northern Europe.
The last "shouldn't take you more than two hours" exercise that I was given involved jumping through hoops to get set up on Instagrams API, only to discover that I was in a sandboxed mode, and needed my account approved before i could get anything more than metadata out). I didn't even get started coding, so I am not sure what exactly the test was meant to achieve.
There may exists engineers obviously awesome enough for that to be feasible, and great for them (but they are probably also obviously awesome enough to not have to go through coding tests, so it's a moot point) and even if I could perhaps (judging by certain recruiter-emails) scrape by as one of them, I certainly couldn't five years ago.
Back then, if I'd had to be good enough on paper alone to warrant not just being put through the recruitment process, but to be paid for it was well, I am not convinced I'd have been considered (and yes, I did a take-home test, and I aced it and it made up for my near-total lack of on-paper qualities).
Of course, companies shouldn't waste their applicants time with needlessly extensive tests, but there certainly exists no 'principle' by which you have a claim to be reimbursed for spending a few hours on an application.
I think that the same rules should apply for programming jobs. Just look at my resume and my publicly available code (that is linked from my resume). If you decide I am good enough to interview me, pay a reasonable hourly rate. This would stop the abusive practice of giving big problems to solve in our free time.
This is a sound-bite, not something that holds up to scrutiny.
If you decide not to interview with possibly great places based on this, you're essentially saying that all future expected gain isn't worth some set hourly rate for 2-8 hours of your time.
Also, what's your free time worth? For me, sometimes it's worthless, and sometimes I feel like I'd sell my soul for 10 minutes to myself.
If all it required was an hour phone call and a small project, I'd totally do it for the right company.
I'm too well-paid and busy to do interviews.
Companies that don't hire using objective at-home tests hire instead with grueling on-site interviews that knock out an entire business day (most of them last a whole business day, some recent interviews peers have gone on have taken multiple business days, and all of them at the very least kill the day for anything else). The latter is obviously worse than the former; I don't even see how any other argument could be colorable.
What I'm beginning to think is that this kind of pushback comes mostly from developers who are well-connected, and so they never experience the grind that less well-connected but equally-capable developers do with interviews.
Yes: if you're at a point in your career where you can get a job in any of 6-7 different companies just by raising your hand, saying "I'm available", and having a 30 minute conversation with the VP/Engineering who you worked with 2 jobs ago, everything is a waste of time. I am not here to tell you that you should make things harder for yourself.
The problem is in the hands of TrendCo, they can be used crudely to find the trendy hire who has the exact same ideas about engineering as the hiring person. Because giving the test costs TrendCo nothing, they are happy to throw people at it until they randomly find someone who is exactly what they are looking for.
Anecdotally, I and 2 people I later befriended applied for the same role. We each spent 4 hours on the task, all 3 of us strong coders who made a solution that would be suitable for any startup, all 3 taking different approaches based on our styles. We were all rejected, because none of the 3 of us hit upon the exact approach the company was hoping for, but didn't ask for. There was no opportunity to ask for this feedback either. And it took them nearly a month to bother looking at my code (even after I called).
Since then, I won't take these kind of tests unless I have reason to believe they are being given in good faith as a way to determine if a programmer is capable, not as a way to find their perfect ideal of a programmer.
I have the strong impression that a typical SFBA tech hiring manager thinks it's crazy to give candidates cheat sheets for interviews, and that helping candidates with technical evaluations decreases rigor. THE EXACT OPPOSITE THING IS TRUE. Evaluating technical ability under unrealistic pressure and with unrealistic restrictions confounds the results of the evaluation.
Of course, you have to design tests that are valid predictors for candidates who have received tips and assistance and practice and resources. That sounds hard! But it isn't. The best predictor for a candidate's ability to do the kind of work you really do is, simply, the kind of work you really do. Not problems from a book, not trivia questions, not one algorithm poorly implemented on a shared coding site and a Skype call, not whatever bug is at the top of the bug tracker today, but a sample assignment given to a real member of your team, the same one, for every candidate, graded the same way.
Regardless of whether you agree with me about that, I think we can all stipulate that if work-sample technical evaluations work (and: they do), most of what companies try to evaluate in on-site interviews is stupid. No part of working effectively with a team requires timed recall of how to implement a stable quicksort, or reversing a doubly linked list at a whiteboard.
At the very least, using work sample tests allows you to build an on-site interview process that honestly engages with "team fit" (or whatever your X-factor is).
My guess, though, is that when more teams adopt work samples and then go through the motions of trying to design a pure team-fit interview, they're going to realize --- once they don't have "implement Bellman-Ford on this whiteboard" to fall back on --- how unequipped they always were to evaluate team-fit in the first place.
The ridiculous whiteboard coding of puzzles probably stems from laziness or inability to implement what you're suggesting. I know that personally, if someone asked me to developed a work sample evaluation for my job, it would take me many hours to come up with something, and frankly I even once complete we would have no way of knowing if it is actually a good predictor of whether or not someone is the right employee.
I'm religious about this topic for a reason. :)
No, I attribute the turnover to the recruiting mechanism. We found great people who were sorely mispriced by the market, and we took advantage of that to create a win-win scenario: people without the resume to get a similar job at a competing firm got an extremely impactful resume bullet and a good-paying job, and we got people who genuinely wanted to be on our team and weren't applying as a once-a-year lateral job-hopping gamble.
(I have no problem with people job-hopping, by the way, but every employer is trying to minimize their exposure to that.)
Really my comment was just to help demystify why this sort of thing doesn't happen in many companies based on my own observations.
My last job search wasn't typical (I thought of starting a consultancy, so didn't search for a job per se), but one before that showed to me that it's exactly what people do. A company that was looking for a guy to write mobile SDKs asked me to build an Android app with embedded webview and animate html stuff with JS based on gyro movement. A slot game company asked me to build a minimalistic slot game from scratch (thanks to them, I have a clean minimalistic and complete game on github now). Another game company asked me to build a small endless shooter — and I ended up being the only candidate who moved texture offsets instead of actually moving game objects to infinity.
Each of those tasks took from 4 to 8 hours, and 2 of those got me an offer. And of course, I used the same method when I consulted others on hiring decisions or hired people myself. So, based on personal experience, companies do that, and it works.
For the the gigs that asked you to do these problems: did you also get interviewed with a standard programming interview? If you had to guess, between 1% and 100%, how much of the weight of your technical evaluation do you feel was on the sample challenges you did at home, versus Q&A and whiteboard coding on-site (or on the phone)?
Oh, what a terrible tragedy, to give candidates consistent evaluations that are actually comparable between each other... /s
I get the point you're presenting, but at the end of the day it still boils down to "we can't use tests because then we'd have to be held accountable for objectivity, we prefer instead a system that lacks any kind of rigor such that any result may not be effectively challenged, officially or otherwise".
1) HR (presumably taking direction from in house counsel) takes the position that it will be difficult to distinguish between a work sample test and an IQ test
2) We are a large organization with very broad roles. The Performance Team hiring for a Senior Software Engineer will probably want a different work sample than the Analytics Team...
Let's not dignify that argument. I absolutely believe you that your company has allowed HR to sabotage your hiring process, and that sucks. But let's not pretend HR is right to do it.
There's probably a solid argument for giving every candidate for the same role the same work sample test; otherwise you might naturally want to randomize some parameters or choose from a bank (if you think "cheating" is likely).
If you or anyone you know is interested I'm a software developer and spend a lot of my time on cloud architectures/containers/multi tenancy optimizations but just generally enjoy solving business problems with technology. In a past life I cofounded a startup that didn't turn out to be viable after going through an incubator (not YC). I have a resume, LinkedIn, Github etc.
With standardized interviews and challenges, our whole hiring pipeline became entirely mechanical. We could send our a challenge and its instructions in 2 minutes, and evaluate the response the next day (or week, or whatever) later in less than 5 minutes. 7 minutes, to produce a technical evaluation that crushed a competing battery of tech interviews by several senior staff members that took 4-5 hours to do.
The biggest complaint we'd been getting from candidates before work samples was that our process took too long. Our goal became to get the entire process done under two weeks (from its worst point, a month or two earlier, of 1.5 months, when someone finally posted an anonymous complaint to Glassdoor about us).
After iterating a couple times, we could reliably go from first contact to hire/no hire, with a motivated candidates (ie: one who would work with us to schedule the interview process aggressively) inside of a single week.
Also, see: https://news.ycombinator.com/item?id=11328090
The process I'm advocating for is far better for candidates.
What do you do to ameliorate this concern?
I am spending a lot of time these days talking to people interviewing in the valley, and what I'm seeing is that the norm candidates are subjected to is 7+ hours of 6-7 on-site interviews. Candidates have to go through all the interviews, even if the first interview has effectively ejected them from the process.
Compared to that horrid process, I don't believe I have to justify anything about my process.
But, if you read downthread, you'll see that we in fact did a lot to ameliorate the (bogus, I think) concern that we were incentivized to soak up hopeless effort from lots of people.
Think of the design world:
Potential client "A" asks multiple desperate artists to work on spec in hopes that they will get the commission.
Potential client "B" call you up and talks to you, sends you some napkin sketches and generally engages with you for an hour before asking you to do a design.
Both clients want you to do a design (test) but one clearly doesn't have any skin in the game. Assuming you're a decent designer, which client do you respond to?
Back when things were simpler, we had a multiple guess questionnaire that did the similar. For onsites, we then looked for evidence of rigor and thoroughness, the ability to estimate how much communication was required, had they deployed real systems?
You understand that it sounds like you "fixed" hiring, and so we're all sorta skeptical, right? If you could bottle that, there's your billion.
Announcing Starfighter https://news.ycombinator.com/item?id=9173939
There isn't enough feedback when someone has a bad idea on hiring. People will very quickly tell you if your code sucks though (this is a good thing), which might be the kind of feedback needed to get hiring changed.
I think it's pretty dumb to do that, though, because most software developers can't take a month off of work from their current job to see if they're a fit for your company, and none of them will put their health insurance in jeopardy to do that.
I also think it's pretty silly to design a process that deliberately demands a month of time to make a decision that could be made effectively in a week.
Its not usually that hard for a contractor to take the time off; they're on their own time already.
we were going to get together in a room anyways.
* Our in-person interviews were shorter than typical in-person interviews because they weren't tasked with fully teching candidates out.
* Because they didn't try to tech candidates out, they weren't as stressful, and so were less draining and unpleasant.
* Because our in-person interviews were entirely scripted (the interviewers had very little latitude with what they could ask and how they could ask it --- which they hated, by the way), they were easy for everyone to deliver.
* Before candidates arrived to their interview, they already knew (because we told them!) that they were likely to receive an offer from us based on their performance on the work-sample tests.
I understand why people resist the idea of coding challenges, given:
* They're not going to get feedback for weeks, months, or maybe ever
* The challenge is going to be graded pass-fail, or whimsically, without rigor or consistency
* They're going to have to do the exact same grueling bullshit draining dehumanizing programmer interview anyways
* They're not going to see the challenges coming, or, for that matter, know exactly what happens next after the challenges are done
That process is super common, even at companies that ostensibly do challenges. It sucks. I agree, no company can really get away with this in the long term.
But those are also chickenshit problems. Switching from unstructured interviews to work-samples is hard: you have to change your mindset on how to qualify candidates, and there's a leap of faith involved. But getting candidates feedback, telling them what to expect with your process, keeping a schedule, and having processes in place to be consistent aren't hard problems. They are table-stakes common sense business execution, and if your team can't handle that right now, your team is mismanaged.
We had a grading rubric for the challenge that was based on the kinds of things people found in the application. We evaluated performance on the challenge on a 1-5 score; depending on how you did on other challenges, a 3 would keep you in the game, and a 4-5 probably assured an in-person interview.
Could I have a copy of that script?
The candidate shares their screen with you, so you can watch as they solve the problem in their own dev environment. You can understand how they approach problems (quick and dirty, slow and methodical, lots of rewriting, etc), and you can ask questions at the end. You get a good sense for how they work as an engineer even before having to bring them onsite.
This seems to resolve the time asymmetry of take-home tests as well -- the interviewer spends as much time watching as the candidate spends working.
The only downside I can see is that you have to design your problems to take about an hour instead of the 2-5 hours you could imagine for a take-home test. But, you can break them up into multiple rounds, and give additional exercises to the candidates who do well on the first one, for no more total time cost than a collection of onsite interviews.
For what it's worth, I've done this at my startup and hired a great developer, and got very positive feedback about the process from the candidates I didn't end up hiring.
My ideal interview format would involve a work sample test, followed by a code review of said work sample, and also a reverse code review (candidate is given some code to review). As an added bonus, all of this can easily be done over email without wasting too much of anyone's time, especially compared to an all day in-person interview with lots of whiteboard time.
My issue with this approach is fourfold:
1. Most companies have no idea how to structure a problem that is both informative to them and also not abusive to the candidates time.
2. Companies generally do this right after the recruiter phone screen, which most likely doesn't give the candidate enough information to decide if the next steps are worth their time.
3. Most companies still do a whole suite of normal tech screens after you work on a take home problem.
4. If you're actively looking, getting a bunch of these over a short period of time is likely. I know during my full time search, more than 50% of companies had a take home test right after the recruiter screen. Most of these were 4-8 hours of work each, due within the week.
A lot of startups structure it more like hazing or a barrier to entry than an evaluation criteria. I have some fun (read: horrifying) anecdotes from my recent search that illustrate the problems above, but I don't think any of my points are surprising.
A nice alternative would have been to simply have one or two projects completed that are straightforward to evaluate and walk companies through them, letting them ask me questions.
Does the work sample test offset all or most of the unstructured tech evaluation the company would otherwise do?
If it does, that means they have a work-sample test rubric they believe in, and they're hiring confidently. If it doesn't, they don't believe in what they're doing, and the programming challenges they're assigning can thus reasonably be seen as more hoop-jumping.
In the latter case, it's up to you to decide whether a prospective job is worth extra hoop-jumping. Some teams are worth it!
For example one company gave a problem with five parts, with the final part being solve longest path on a bipartite weighted graph (which is quite a hard and time consuming problem). After that, the next step was a phone technical screen, then an on-site with 4-5 more interviews, most being white-boarding. It was basically hazing instead of an evaluation criteria.
An alternative is my last job, which had a take home test that took about 6 hours, but that was the whole technical part of the process. Being on the other side reviewing them, the problem absolutely gave enough information.
I totally get there's a right way to do it, but like most interviewing trends, companies seem to just be adding this as a step instead of revamping their process.
Anyway, my larger point is that what I've been seeing interviewing is that these tests are becoming much more common at US startups without companies removing/reducing the rest of their technical evaluation process, nor really structuring the problems to be a good signal.
In an ideal world where companies do take home tests right, I think its a great solution. But what I've been seeing more often than not doesn't support that, making it hard to support.
I'm really curious what you've been seeing at Starfighter. Are partnering companies still going on to do a full technical interview? Or does Starfighter largely replace their normal technical evaluation?
Ignoring the fun of the challenges themselves (which probably isn't entirely fair), the latter makes it very compelling for a candidate. The former does not.
I'm actually fine with that! We make no pretense of having designed a screening process that is appropriate for every job. What I'm less fine with is the fact that the norm, even for abbreviated tech-outs, is 7-8 hours of on-site whiteboard interview.
Why? What's the point of doing anything at all with the hipsters? They're irrelevant.
> we greybeards can learn from the greenies
Of course! But there are fresh engineers and there are trendy hipstors. They've got nothing in common besides their age.
As an interviewer what I'm looking for in a candidate is someone who really has enthusiasm and passion and wants to work for me. It's less important how they look on paper, I want to know how much they want to work with us.
Please forward all jobs to me, as I am happy to take their money.
I think code schools are effectively training programs for this kind of work at the companies that use them as hiring pools. I would be surprised if these companies didn't influence the schools' curricula in some way. If they aren't doing this explicitly, they should, and they should absorb some of the cost that is currently being levied against the students. Right now, we're at this weird point where students are paying for their own training at these 3rd party facilities that more or less kind of guarantee them maybe a job at this list of very specific companies but no guarantee... Something feels a bit sleazy about it. I don't know how transferrable the education you received at a code school will be once you leave the company that hired you from it.
I think the field of software engineering/programming/whatever has broadened so much that you have to have some distinguishing, domain-specific feature to get a job somewhere--the distinguishing feature of the 'trendy' programmers is usually the tech stack alignment. Maybe general knowledge of writing good, maintainable software is moot in the face of an efficiently trainable workforce, short-lived code, and a diaspora of tech stacks.
What do you think those indian programmers were doing for the past decade?
I have a computer for that! Seriously, that's one of the things a computer excels at. This is what is so nice about a language with strong dynamic typing: it makes writing the sort of code which writes glue code reasonably easy.
I've worked on the Avon AU website and we had a few hundred tasks like that. It's why (to link back to my current pet peeve) I'm upset that my relatives are unwilling to learn a tiny bit of web design because "it's too hard". There is a market for people who ONLY know how to do this. (There were two people in the company I was working for and my team only got access to them one hour every week - they were that busy.)
There a lot of people who can do this work in the UK. Mostly they don't get paid very much at all.
The mass offshoring effort in the US through the 00s was exactly this. The problem that many companies discovered is that you really get what you paid for. If you spec something out to a 'T'[1], you'd get exactly what you ask for - warts and all. If you don't provide enough detail to do that, you get to go back-and-forth until you do. And if you want anyone to troubleshoot a mildly complex issue... well, good luck. Maybe one in ten of the people who wrote the code from your spec have that ability.
Some equilibrium has returned, but not before the damage was done - causing a lot of unfortunate misconceptions about the abilities or lack thereof for entire demographics of people.
> code school
For the most part, these are an attempt to create the same thing without the offshoring - 'teaching code' of that sort has been relatively common in offshore markets I've worked with in past jobs. I don't think that's their intention, but it does appear to be the end result.
[1] To the point where you're more or less pseudo-coding the solution
The problem (at least as I imagine it) was that this is inefficient when the designs need to change and one person gets a really soft easy job and the others get a lot of detectable grunt work.
Now we have the opposite problem - the "architect" title is kind of despised by people who know what it means, and everybody designs - but often those designs are at odds with each other, and usually too entwined with ego to come to compromises that make different sections of the code work well together.
There is a complex balance between finding the right level of top-down design and order and using all the assets of the team to make sure things are good and stable, and in particular, maintainable to folks who are going to be new to the code.
S/he must be good because s/he worked for X known company.
It's a pervasive bias, especially in tech where certain brands are lionised to the point of nearly becoming sacred. Brand association alone will get many a person through an assessment process with sometimes with the complete abandonment of any semblance of due diligence.
Remember the Scott Thompson scandal? Basic stuff like lying on your resume did not stop Yahoo! from making a pedigree hire. Must be good because PayPal.
We have to all work very hard to educate ourselves that we are all inherently susceptible to this bias.
My "real" job is, of course, startups. I save for a while, then work on various startup projects. I'm learning a lot.
So now that my latest startup project is coming to a close, I'm thinking of where to go next. Instead of hands-on teaching, I'm seriously considering getting back to coding. Sit down, make something happen, look at a job well done.
The problem here is this: all I know how to do is make solutions happen for people in a dozen or so different technologies. I haven't spent time trying to keep up with the cool kids. C++? Sure. STL? Not so much. All the basic web tech (HTML, CSS, Javascript, etc)? Sure. Angular/Meteor/etc)? Nope. F# and OCAML? Love me some functional programming. Haskell/Erlang/etc? Nope. SQL Server, MySQL, some Oracle? Yep. NoSQL, Cassandra, Mongo? Not really. Once I knew enough to get the work done, well, I just got the work done.
There's a difference between coding to get things done and spending time with toolkits and frameworks because they're popular in the market. Back when I was a senior programmer, one of the most important things I did was try to guess what the cool kids would be doing in 3 years -- then study that and get some experience. This paid off over and over again. As somebody who just wants to make things happen, that's not a priority.
This leads me to my second observation, from sitting on the other side of the table looking for developers and working on staffing models. The dirty secret of the tech industry is that nobody has any idea how many developers they actually need. There's so much variability in teams, and you can break the same work down so many ways....there's a lot of risk. (Yes, there are several heuristics you can use. Insert long discussion here about how they're only heuristics.)
So at the end of the day, you have a lot of companies that want to be trend-setters chasing after what all the companies think are the cool kids -- the trend-setting hires. I remember sitting down with a SV CEO a while back talking about his 100-person shop. Everybody in the place had some cool-kid story attached to them. The place was a mess, but it was a trendy mess.
At times, I am not convinced that these companies would do much better with some kind of "sweep the street" approach to hiring, vacuuming up a huge number at a time and taking them through some structured filtering/training process. I've even thought through how such a model would work. Haven't found anybody willing to experiment with this yet, though :)
As arbitrary as the system is, I'm not sure its any better or worse than any other system. And the simple fact of the matter is that buzzword-based, trendy hiring has been with us for decades. I doubt its going anywhere soon.
Didn't IBM and a few other big iron shops do this in the 50s/60s with secretaries? iirc, they could apply to be programmers and would get trained.
Where does this come from? I actually see a contractor as someone who had experienced way more "war stories" than the guy who has been sitting in the same chair for 10/20 years. As a contractor, you are exposed to more technologies, more business sectors, different working cultures.
Breadth of experience counts and you can't get that without having 'been around'.
On the other hand, if you're hiring a contractor who has had lots of very short contracts, that should raise a warning flag.
Quite simply tho, why would any good contractor want to go permie? the attraction for me is simple... I get paid twice what I would otherwise get in a permie position.
Its not necessarily the length, but the lack of extensions that is a warning sign. Most projects do not last a short time so a lack of extensions indicates a problem.
I am really biased towards short, "solvable" projects :)
Large companies with huge teams of full-time employed software programmers will often hire contractors to fill gaps. These contractors are typically contractors-in-name-only: they work under exactly the same conditions as full-time employees but with a worse tax situation, without access to benefits, and without eligibility to receive equity or cash bonuses. They are often contracted through intermediaries who take a large cut. These contractors can be fired more easily than their full-time employed colleagues, and they may often work on time-limited contracts that cannot be renewed. (They often do not count against a manager's allotted "head count.")
These contractors are typically in this position, because cannot get hired as full-time employees. They often jump between contracting jobs until someone gives them a chance or until they manage to get a client to "convert" them to full-time.
Staffing firms are in on this. If a recruiter sends you to interview for a contract role at some large company, it means they don't think you could get a job as a full-time employee. Hiring managers also know this. If they see you've only ever worked as a contractor, then they will assume you don't have what it takes to get a job as a full-time employee.
(This is not right, and this is not fair.)
We also still have a very very strong consultant labor force making 2-3x what W2 full-time employees can pull in. These consultants generally work through smaller consulting firms that take smaller cuts for the placement/handling billing and invoicing.
Perm - Mid level benefits + Pay (maybe options in a startup)
Contractor - Individual with their own Ltd company, pays less tax and much higher take home pay but without any benefits.
Consultant - On-site via a supplier on a framework of some kind, however, often a permanent employee of the supplier with the supplier cashing in the margin.
At least 50% of the tech workforce in companies I work with or where peers are at in London are made up of contractors, especially in Banking.
It's also my experience that you get what you pay for, contractors in the whole tend to have a much wider breadth of knowledge from various sectors and hit the ground running whereas I don't tend to see the same appetite from Permanent employees (in most cases!).
I've worked for Fortune 500 companies around here. The senior full time employees have been working at the same place forever, so their skills are often outdated. They get paid a lot less, but they are often fine with that, because the place gives them the one thing they want: status. Changing jobs means you might not get that status. In comparison, the top contractors get far better pay, have worked in more than one or two places in their career, and are the guys you want to hire.
It's probably different in the bay, where big tech companies have little trouble paying 200K+ compensation packages, but around here, just contractors do.
Why do the contractors get paid more? Because they can get paid without talking to HR, or meeting any pay bands. Last year, I worked with other three contractors, whose names anyone in the Scala community would recognize. 200-300K a year range. The best full timer they had (which just quit, after being told how silly he had been by being full time), made 110K.
Being well known means that switching to work for TrendyCo isn't difficult though.
I took the job a year ago with the hope its name recognition would be helpful in the future but I had no idea there was such a stigma around contracting. I'm starting to look around again, so I guess I'll see how it effects me.
Then both of us were disappointed when none of the startups were interested. The auction period came and went. I had zero offers to chat on the phone despite dozens of views. She was nice enough to give me another auction round and I went for it. Only a half dozen new views on my profile that time but at least I got one phone interview out of it. The talent advocate was a bit confused by the whole thing and couldn't understand why most of the startups didn't even want to speak to me. She did offer to personally reach out to some of the startups on my behalf but I knew what happened so I politely bowed out of the auction.
So I guess I have this stigma now and I know it's only going to get tougher the older I get. I want to fix this and hopefully move to a full-time product development role before it is too late. Should I quit my job and go back to school? Join a coding bootcamp or "hacker community"? Continue working as a contractor and keep applying to startups on the side?
Graduates and junior developers will burn themselves to hell and back trying to impress their employer because they don't know any better. That includes people who have never worked for a proper business (i.e. not a VC backed startup).
As for me, after co was acquired, I was a FTE for one day, with great benefits. But, the lawyers wouldn't clarify a claus in the FTE contract that would exempt my IP. Was I assigning it or excluding it? Their answer was "either". Before that, I was working for 4 days per week for the startup and 1 day per week on my own projects (at 4/5ths the pay).
I know plenty of indy developers that are absolutely brilliant. Sometimes they take on side projects as contractors.
Many contractors are really installers, and are great at bootstrapping a product or service. But... they know little or nothing about the actual running of the thing they setup. They don't get how to integrate their product's magic with your ITSM system, or what metrics to monitor, etc.
On the developer side, I've seen more than my share of consultants who are high-priests of whatever methodology/language/framework religion they preach, but have a hard time delivering value.
Or it could mean, someone that a company took on with a day-rate because they needed a warm body, but didn't want to actually hire them either, in case someone better came along.
Or anything in between.
Recruiters are often paid a commission for every one of their successful hires and that commission is often split between an immediate payment and a payment (or payments) when the hire hits specific milestones (6mo, 1 yr, etc). Recruiters don't like trying to fit contractors into non-contract roles because they're worried about the contractor leaving before the recruiter's remaining commission is paid. If that happens, the recruiter puts in just as much work and gets paid less. They'd rather discard those resumes that they consider to be riskier and focus all their time on people with a history of staying at least 2 years in every one of their jobs.
A company founded by Stanford CS students will focus on ivy league CS students; friends of mine have a pretty successful consulting company and none of them has a formal CS background, but years of experience delivering complex software; they focus on guys that can deliver, regardless of background. Some people never went to MIT, but have a deeply ingrained wish that they would have - by surrounding themselves with MIT grads, they suddenly generate the wanted association.
But yes, I agree with everything you're saying.
The schools are Brown University, Columbia University, Cornell University, Dartmouth College, Harvard University, the University of Pennsylvania, Princeton University, and Yale University
Rice, Texas A&M, and Texas at Austin are also ignored pretty often, but Texans can be offended on their own behalf without my help.
Could you clarify what you meant here? Was it that 1. those who surround themselves with MIT grads discover an ingrained wish that they would have gone to MIT, or 2. that they satisfy a pre-existing wish to have gone to MIT by instead surrounding themselves with MIT grads? In the case of (2), are these effects tangible as they might expect?
Disclaimer: I'm living in Germany and nearly exclusively interviewed in Germany so far. There's nothing comparable to the top US schools here, so school reputation is probably much less important than in the US.
There is something comparable: https://en.wikipedia.org/wiki/Studienstiftung: 'it is often referred to as "Germany's secret elite university"'.
I suspect that the reason why, is that so few engineering teams do pair programming full-time, complete with daily-or-more rotations.
Pairing gives you the ability to spin somebody up rapidly enough to see how well they do on real code, and at the same time get a good read on personal fit from multiple team members.
Pivotal is shockingly good at this. You start with an hour-long pairing exercise over the phone. If that goes well, you come in, sign an NDA, and pair on two different projects, with a block for lunch in the middle.
That's a grand total of ten hours of screening time.
This process isn't fool-proof, mind you. But it does do a good job of answering the most important question: Do I want to show up for work, tomorrow, and start working with this person?
Perhaps just as importantly, it gives the candidate enough information to answer that same question for themselves.
Nothing tells you whether or not you want to work somewhere, like actually working there.
source: been there, asked for feedback after received just a generic "No good luck with you career" and no response for my email..
That's worth possibly negotiating the amount of time or staging earlier parts with less impact.
I wouldn't say no to an interview that is going to burn a day, but I also wouldn't go to one without a pretty good feeling that I was likely to accept an offer if it came.
I mostly think of interviews as at least as much of a chance for me to evaluate them as the other way around (even the way they choose to interview tells me a lot).
There is no reason that you can't have a mature interaction with a company where you both agree to invest some time and effort in a process that could benefit both of you. If it looks like a bad risk to you, don't go. If you are doing a competent job of this, you should know what an interview process looks like before you agree to the interview. If there are aspect of it you aren't sure about, you should ask about them. If their reasoning doesn't convince you - respectfully decline the interview.
The most valuable thing about an interview process is an exchange of information. Thinking about it too much as a time-for-money trade off can miss this point. Of course, if you can find a more time efficient way to exchange the same information, that's good all around.
It's one of the reasons we try to do two interviews and ideally, remember to tell the interviewee to ask questions.
It was a gigantic waste of time. Some whiteboarding would have been adequate; it would have been better, even, without all the weird keystroke errors and unwritten expectations on the codebase.
While I have great appreciation for problem solving and human interaction, pairing on a non-customized computer, on a random code base, with someone you met 5 minutes ago is absolutely the wrong way to go about interviewing.
I've done work sample tests: they take a lot of time (time is money), and I don't really have enough invested in this company to want to work for free. I'd much rather do a work-sample after the onsite - let's at least determine if we are comfortable around each other before I start investing hours of my after work life into this thing.
Pivotal Labs and Pivotal Cloud Foundry teams default to 100% pairing.
What you experienced is basically the actual job. It's perfectly OK that you didn't like it, lots of people don't want to work that way once they've tried it.
But it wouldn't make sense to find potential pair programmers by not pair programming.
However candidates for Labs will see stuff our clients consider commercially sensitive (sometimes their mere existence is commercially sensitive), sometimes candidates for Cloud Foundry will see stuff that is commercially sensitive for Pivotal.
Mind you, I did a round of interviews a few years ago and everyone had an NDA at the door. I read them and none of them were silly, so I signed them.
Arrogant absurd process with no basis or evidence in reality.
You either drink the kool-aid and march in line or you are "not with the program"
Someone who will donate ten hours to an interview is someone that is "malleable" enough to be told how to think.
Do you sell t-shirts? I would like to buy one.
In fairness, though, most people who decide to take an offer have self-selected. Malleability might be one reason. Another could openness to new experiences.
I unless you need like a PhD who is the top expert in X (and you're willing to pay any price) .. it just seems like a bad bargain
"You have a STEM (Science, Technology, Engineering, Math) Degree from a top tier school."
I wonder how much longer positions with requirements like that go unfilled compared to more open-minded ones.
Anti-Windows bias doesn't really feel like an example of 'pedigree' to me, though.
I can't imagine programming on Windows. I can't even imagine using the OS. I moved away from Windows ~a decade ago and haven't looked back - it seems to be getting worse every year (the business model for W10 appears to be surveillance?).
Anyone care to chime in? What's the appeal of Windows in this day and age? To me it really feels like 'big companies use it so their programmers do'.
Remember a good softie is flexible... that includes getting experienced on all OSs, dont limit yourself... Windows isn't all that bad (and ignore all the silly surveillance scare stories).
Good software should be platform-independent, good software engineers should also be platform-independent.
I did try to use Linux a few times in the period between 2007 and 2010 but I never found a desktop environment I liked enough. The file browsers and music players always left much to be desired.
I can't say much about how the programming compares as I stick to the command line mostly but I do prefer the thought of using the Win32 API over whatever might, might be available on Linux. Do I choose GTK and its copious unique types (even for integers) or do I force myself to learn the abomination that is C++ to use Qt? What audio subsystem do I use from the dozen or so that is around?
I guess it's that I don't do GUI programming. I mostly produce software that does things directly (rather than enabling others to do things).
I fundamentally have very little use for a GUI unless I were producing software for someone else to use (e.g. QuickBooks or something).
I think that's probably the barrier in both directions. GUI users don't usually see eye to eye with terminal users. It's vi-vs-emacs all over again. :P
- IO Completion Ports (IOCP): https://speakerdeck.com/trent/pyparallel-how-we-removed-the-... (to quote slide 40: "What works well on UNIX isn't performant on Windows[;] What works well on Windows isn't possible on UNIX").
- native support for fibers (CreateFiber etc.)
- binary compatibility for GUI applications over decades (try to get to run an application that was linked against GTK+ 1.x under a current GNU/Linux system)
- I personally prefer the Visual Studio debugger by far over gdb (but YMMV)
- there is exactly one way to write GUI applications against (WinAPI) - all other libraries as MFC, WTL are just wrappers for it. Try writing an X11 app against XLib or xcb and you will find out why Windows is better in this point.
- the same holds for other GUI functionality as clipboard and drag & drop (OK, admitted, it is a PITA under Windows, but far worse under GNU/Linux/X11)
- When developing GUI applications under Windows vs. say Gtk+ oder Qt under Linux: If there is some functionality, which is very low level (say, support for multiple mice): Under Windows for this there is Raw Input and under X11 there is XInput2. While the Raw Input feels integrated quite well into the style of the whole WinAPI, using XInput2 when developing using Qt oder GTK+ feels really foreign and I always fear that I will break something. In other words: When developing for Windows the APIs often look much more homogenous than under GNU/Linux where I personally feel that there are different libraries with different styles (but you might feel differently)
- I find the MSDN documentation much more helpful than man pages, but this might be my personal preference, at least I feel that when under Windows something is documented it is nearly always documented really well, while the quality of documentation varies a lot under GNU/Linux and is (for things that change more often) often outdated
- Also I consider it as a bad idea that many Linux devs consider code as documentation if by default most "user-centered" GNU/Linux distributions will not install by default the source code to any installed package.
- I personally prefer the slightly "overengineered" style of the Windows API instead of having to hack something (sometimes ugly) together if the API will not provide what I need; but this is again a matter of preference.
Are the usual GNU/Linux shells still better than Powershell (being better than cmd.exe is trivial ;-) )? I'm really interested in a serious evalution from both Windows and UNIX nerds.
it also comes down to explorer vs anything else. I'm a huge fan of NT, but everything else is kind of mediocre. using someone else's windows computer recently I had the awesome experience of running an installer, being told I needed to install the ".NET 2.0 runtime", so I go to the control panel and select "remove programs" then select "add programs." why is add programs behind a button that says remove programs?!
the criticisms of the technology are skin deep but when you're using the system, you're interacting primarily with the skin, so...
You don't argue over which email server you use, you just setup Exchange.
You don't argue over nginx, apache, etc just use IIS.
It's also configured quite well out of the box, where as Linux you spend several days getting it all configured to perfection.
When you just want to focus on the business problem at hand, I find it brilliant. Where as in other stacks you get caught up in technology, for technologies sake.
I find you can go from 0 to release a lot faster.
Uhm, no. Most distros comes with sane defaults, perfection is something you work hard with to achieve on both Windows and Linux. Counter-Example: how to run get max performance out of 10Gbps Ethernet on Windows.
This being said, there are lots of choices in actual applications that may or may not be available on other platforms in the same way.
Ideally, I'd run a Linux host and Windows guest. For a long list of reasons, it's the other way 'round.
Also, don't embrace the upgrade death march with Windows and life gets better. Keep full-install media of The One That Works.
The first one is hiring. Supposedly everyone knows windows, great hiring pool. I donno if I believe that anymore, but in the old days there was certainly no shortage of MCSE to hire. It doesn't matter if the UI for the OS and office software change completely every couple years because "everyone knows windows" so training costs only exist for alternative OS or alternative office software. When that linux genius quits he's irreplaceable, isn't he? That's a great position to be in if you're that guy (me), but business people hate that. To some extent this is a young person vs old person problem because college campuses (campii?) are owned by apple, not MS. MS is just to run the dorm xbox, that's all. This is strategic planning on the part of decision makers.
The second is financial embrace and extend. Once you got one windows server or a couple desktops, inevitable licensing agreements make the marginal delta of "another windows box" extremely cheap (maybe zero) vs the measurable costs of mac etc. BSA / etc audits will make your life a living hell unless you participate in this scheme. This is bean counting on the part of the decision makers.
The third is interoperability. Unless you're the worlds most boring company you'll be doing something weird and under the first topic above, everything weird has by default windows clients or drivers or applications. There will be a windows client for an eprom programmer or I2C driver. There might be alternatives but it will work under windows. Then see the topics above. You will need windows boxes... you just will. This is pragmatism on the part of the decision makers.
The fourth is CYA. Like decades ago, "nobody ever got fired for buying IBM" today "nobody ever got fired for buying MS". You could get fired for buying a mac and it doesn't work, or installing linux on a server that crashes, but no quality of service, including zero, is low enough to get fired for buying microsoft. No matter how badly the system gets powned or how much stuff gets stolen, you can't get fired if you bought MS products. Just doesn't happen. If you can afford it, and you like being employed, the decision seems clear from a risk management perspective. Cowardice on the part of the decision makers.
The fifth is support. Business people think we get support by calling a script reader in India who tells use to wipe, reinstall, and reboot, and furthermore that is worth money and worthy of making procurement decisions. In the real world we know we use google for support and non-MS stuff googles better. But business people like a risk management of a nice security blanket of telephone support from a dude with a nice looking certificate. Its not actually useful of course, but business people don't understand it. Business people think computer support is like medical support and you call 911 and get fixed up, but 911 converted to computer support would be a pretty funny standup comic routine. Essentially this is plain old ignorance on part of the decision makers.
To me my stereotype - if you're in a corporate world and want developers that like users and spend a lot of time on complicated business problems - you're likely to see lots of "windows developers".
If you want some to write apps with lots of technical complexity and simple business logic, you're better off with "unix developers".
Not stuck on the CLI and text terminals culture. The Windows developer community knows its way around basch, Technet scripts and Powershell, but we rather use nice comfy GUI tools.
C++ (moving away from C), .NET languages, COM and nowadays WinRT offer programming paradigms that follow Xerox PARC ideas and drive forward developer experience.
Those kind of developer experiences being shown by Bret Victor.
I could say the same about Mac OS X developer experience.
For almost a decade I was a dedicated *BSD and GNU/Linux user as well, but they seem to be stuck being just yet another UNIX clone without any consistent plan for anything outside C and POSIX APIs.
See, those of us who use Unix & free software see that as a benefit, just as the literate find the written word to offer advantages over picture books.
With a keyboard, I am able to enter hundreds of discrete inputs: with a mouse or touchscreen I have one 2D input and a few buttons. With a keyboard I am able to have a conversation with my computer and my data; with a mouse I point and click, which isn't much different from pointing and grunting in human conversation.
Your answer is a typical example of UNIX CLI users that need to express themselves as being more intelligent than GUI users, while forgetting that some us do have enough CLI experience and decided to grew out of it.
I can use macros and key + mouse combos in FPS style across many GUI applications and if I ever need a CLI, Powershell or Terminal (Mac OS X) are just a click away.
I've worked at startups and enterprise environments, and what has always remained constant at every Microsoft/Enterprise company is the troves of obese, unhealthy, arthritic middle-managers that can barely use a computer anymore because they got lazy and succumbed to using GUIs to get their basic work done.
Now, they are stuck on MS because any foreign GUI elicits a sudden "NOPE!" from them. They are constantly unhealthy because none of them have standing desks. They don't have standing desks because mouse use is extremely non-intuitive in such setups and in many cases dangerous [2].
By surrendering to the mouse and the GUI, my older co-workers are low-quality producers, exceedingly lazy, and otherwise slowly dying.
My console emulator has looked the same for the last ten years. I can SSH into any UNIX system and it's familiar to me. Innovation hasn't slowed me down at all.
[1] http://www.nytimes.com/health/guides/disease/carpal-tunnel-s...
[2] http://www.workwhilewalking.com/avoiding-carpal-tunnel-neck-...
I could say the same for the co-workers from a very well known fortune 500 I worked for. They were all using HP-UX.
> My console emulator has looked the same for the last ten years. Innovation hasn't slowed me down at all.
Yep that says it all. Hardly the example of what innovation means.
It appears you fundamentally misunderstood my point. Though innovation has occurred on my Linux system (and on my MS system) without fail for years, I haven't hard to learn bizarre new mouse movements and locations of menu items. Rather than slow me down, I can begin taking ADVANTAGE of innovations right away because they aren't implemented on CLI interfaces in a detestably-arbitrary manner.
Also, I don't get your first point. If people got unhealthy and unemployable due to something OTHER than the mouse and GUI usage, then so what? That doesn't negate my point at all. It simply shows that yes, more than one cause exists for obesity and brain rot.
It's been shown through years and years of clinical study that the injuries received at the modern office have to do with the movements associated with mouse usage. Keyboard use is easy to adapt safely to the modern healthy workplace (standing desks, padded surfaces for wrists and feet, etc.) Mouse use, on the other hand, barely works correctly for the seated and unhealthy worker, and works even less properly for the worker trying to make healthy changes.
Mouse use is a problem. Keyboard use is not.
Tell that to the piano, keyboard players, Emacs users and typists suffering from RSI.
Don't worry; if the overfinancing bubble bursts, or even deflates gently, people with salaries and get-it-done tech experience from outside the Silicon Valley reality distortion field will once again have an unfair advantage.