Hacker News Reader

Comment by curveship | Hacker News Reader

As someone who has recently been hiring .NET engineers, I have to admit that this inspires mixed feelings. On the one hand, I can see huge power from combining AI and search with the structured context of programming. On the other hand, a disappointing number of the people we interviewed weren't software engineers, they were IntelliSync engineers. We'd give them a problem, and their first instinct was to hit a period and start hunting through the method options that IntelliSync gave them to see if one got them closer to their goal. Instead of stepping back and thinking about the problem generally, they'd try to solve it by stringing together IntelliSync suggestions, like stepping stones across a pond.

View on HN

It's Intellisense. I might have a chip on my shoulder but if you were competent and really were hiring .net programmers you should know that? Especially if you're going to take the mickey.

You get those types no matter what role they hide in. Today I spent an hour with a candidate that looked really promising on paper dodge every question and switch from being "mainly backend" to "mainly frontend" when they couldn't tell me the difference between an interface and an abstract class....

Hah! Yes, I am (or pretend to be) competent, just not when writing HN comments ;). Thanks for the daily serving of humble pie.

I do wonder if there's something about .NET and a business environment that encourages this kind of behavior. When the organization's values are in their business rather than mentoring programmers, when they tell their programmers to "just get it done," you end up with IntelliSyn...Sense programmers? I've worked in various different programmer ecosystems, and I've never seen this pattern so strongly. There are of course excellent .NET programmers, I don't mean to say otherwise. And I got the feeling that several of the people we interviewed had basic talent, they'd just been trained, intentionally or not, towards this kind of behavior.

We started putting VS in front of candidates precisely to deal with the kind of fuzziness you mention. We started with whiteboarding code, but a lot of candidates would have a wrong design, then add a line of pseudo-code that they claimed magically made it work. By having them write actual code, it forced them to be explicit and to deal with unexpected outcomes.

> We'd give them a problem, and their first instinct was to hit a period and start hunting through the method options that IntelliSync gave them to see if one got them closer to their goal.

I use dynamic languages and have never touched an IDE, but I still do this.

If I find out I need some feature provided by libfoo to accomplish a task, then, before I even look up the libfoo docs, I try this, or an equivalent:

    require 'libfoo'

    LibFoo.constants

    (LibFoo::Foo.new.methods - Object.methods).sort.grep /bar/

what language is this ?

Ruby, as entered into an irb session: http://i.imgur.com/58ceKcR.png

> We'd give them a problem, and their first instinct was to hit a period and start hunting through the method options that IntelliSync gave them to see if one got them closer to their goal.

IntelliSense is like GPS for programming. When driving, do you prefer to plan your trip using a map or use the GPS instead? I guess there are still people in the former camp, but most younger people are in the latter.

> Instead of stepping back and thinking about the problem generally, they'd try to solve it by stringing together IntelliSync suggestions, like stepping stones across a pond.

And are they less efficient for diving in right away and using their tools vs. waterfall planning up-front?

Kids these days...

But that's just the issue: IntelliSense isn't a GPS. Tell a GPS what your goal is and it will give you an explicit list of instructions to achieve it. IntelliSense can only tell you what your available next steps are. It's really more like a map -- give it your location (i.e. a type), and it will tell you what roads lead on from there (the type's methods). It won't, because it can't, tell you how to string those choices together into a solution. A GPS does, but not IntelliSense.

Don't get me wrong, I love IntelliSense. It digests a huge amount of information for you without forcing you to switch context, like having to look up library documentation or how a particular module was written. But it's only part of the puzzle. What I was seeing in our candidates was that they'd come to rely too heavily on IntelliSense and forgotten how to design. You need both.

GPS works with a small vision scope; i.e. "turn left in 100 meters." IntelliSense (and all other forms of code completion) is quite similar in the field of vision (small), but you are right that it differs in that the goal is not known by the system. Its not like a map because you don't see everything, just a focused little bit.

> What I was seeing in our candidates was that they'd come to rely too heavily on IntelliSense and forgotten how to design. You need both.

I think kids these days have evolved different ways of working given the tools they grew up with. IntelliSense (and code completion) wasn't even a thing before 1997, and many of us developed our core programming habits before that. The question is: are we biased against the process we are observing because it is so unlike our own, and are they arriving at the correct answer as or more efficiently than we would with older ways of doing it?

Design is quite orthogonal to API selection; if they aren't designing, then they should be succeeding on the problem UNLESS you gave them one that required little or no design; like writing some basic boilerplate code. You didn't specify if the candidates were failing on outcomes or not.

In business it doesn't matter how you reach a goal. It's not about clean code, it's about getting fast, working results to a specific problem.

That really depends on your business. If you make an operating system, for instance, clean code is probably in your best interest.

Ever see early versions of Linux? As Richard Gabriel says, worse is often better...

Now aircraft control systems or MRI machines...you probably want very clean code.

Reply on news.ycombinator.com