Sounds like academia and technical training have been conflated in some places.

In academia, writing a algorithm manually is a no-brainer. In industry it's done all the time (including the academic process of new-hire analysis).

In technical training whence code monkeys are churned out, writing an implementation of a software program manually is senseless. You should be using the machines you're being trained to operate.

I had a test which required instantiating a bunch of hereditary classes. When I figured, I don't have enough time to finish writing the test, I wrote the following in my test solutions: "I see no point in replicating boilerplate code, in here I just copy-paste boiler-plate for ABC". It was a gamble I took just because I didn't have time. Luckily the exam checker agreed and inserted a big fat smiley, and gave me a 100%. Of course, I took care to write all the algorithmic code.

Regarding interviews, I regularly program in ~5 different languages, and know ~5 more, which I use less often. I don't remember the order of the parameters in JavaScript's setTimeout, and I don't always remember how to initialize std::const_iterator in C++, but it's enough that I get the syntax 50% right, and tell the interviewer that I can Google the rest. You'd be surprised, honesty works.

Regarding working without IDEs, I don't think that working without IDEs is a good decision for CS students. My CS intro courses were in Java. Java is not designed to be written by hand. It is over-expressive specifically with the intent that it can be auto-generated and refactored and analysed with an IDE. Whoever writes Java by hand is masochistic. As someone who came into university with programming experience, I found the experience appalling. Most of these professors forget that the first code that they wrote by hand 30 years ago was in BASIC (a language specifically designed to be concise [and thereby ambiguous] ). I find it horrifying to meet the schmuks today who come to work writing Object Oriented code without an IDE just because their hipster university instructors told them to use Emacs/Vims. I view it as gross professional negligence. Sort of like building a house without one of these: https://en.wikipedia.org/wiki/Spirit_level

Sorry, but writing code by hand is just stupid and utterly pointless.

If you're asked to code something on paper in an interview, it will most likely be pseudo code. If they berate you about syntax, tell them you're looking for a job as a programmer not a compiler and walk away. If an interviewer can't tell immediately whether a candidate knows language X, a written bit of code won't help.

Ditto for remembering the parameters for API methods. We have google now, so we can focus on the problem, not the language and hey before Google? We had books!

READING code, on the other hand is a far more important skill. "What's wrong with this code" or "how can we improve this" are very useful questions.

And as for the "design it up front and don't refactor" argument... really? If 50 years of programming have taught us nothing else, it's taught us that people are terrible at designing upfront. Prototype, fail fast, iterate. This isn't new thinking.

Now, you should absolutely be able to describe an algorithm or program structure by hand (or better yet on a whiteboard), but expecting anything working is just a monumental waste of time.

If you're asked to code something on paper in an interview, it will most likely be pseudo code. If they berate you about syntax, tell them you're looking for a job as a programmer not a compiler and walk away.

You might walk away from a lot of interviews, on that basis.

I'll give some leeway around not remembering the precise names/arguments of library functions, and so forth. But if I even get a hint that you can't write syntactically-correct code on demand... That's a pretty big red flag.

If you don't know where the ampersand goes during the interview, how am I to be sure you'll know where it's missing in a code review?

Hmm... Well, I'm not in university and haven't yet reached a point where I've had an interview for a software development position, but I really don't think the concept of hand-writing code for exams is very intuitive. There are other ways to prevent cheating and encourage students to remember proper syntax. For instance, students are to use school-provided computers without internet access or IDEs and type code in Notepad under supervision. This would be much easier for the instructors as well, because they can just copy-paste and compile the code in their IDE of choice...

I do understand the reasoning behind it, however. I do feel that a lot of programmers rely too heavily upon IDEs for code-completion, error-checking, and debugging. For a long time, I was one of those people. One day, I decided to download MinGW and use Notepad + the command line to compile my C++ code. I was amazed by how much I learned in the process of weaning myself from Codeblocks for a while. I did the same for HTML5/JavaScript and MXML/ActionScript3. Just Notepad. Whenever I made a mistake that caused a bug in the program (most often, I left out a comma or semicolon where I needed one), I manually went through each line of code to see if I could uncover the cause of the error. And I learned a valuable skill. Debugging; without having to rely upon my IDE to tell me which line I messed up and why. As a result of this experiment, I've become far more meticulous when I write code, making fewer syntactical errors than I had beforehand.

In short, I agree with Bregma in that students should be tested on their ability to write production code. On a computer, as it's more commonly done these days (I use pen and paper for diagrams, flowcharts, and other forms of graphical prototyping ).

If you're asked to code something on paper in an interview, it will most likely be pseudo code. If they berate you about syntax, tell them you're looking for a job as a programmer not a compiler and walk away.

You might walk away from a lot of interviews, on that basis.

I'll give some leeway around not remembering the precise names/arguments of library functions, and so forth. But if I even get a hint that you can't write syntactically-correct code on demand... That's a pretty big red flag.

If you don't know where the ampersand goes during the interview, how am I to be sure you'll know where it's missing in a code review?

In over 15 years and 4 countries of work as a professional programmer, I've never had to walk away from an interview for that reason, and honestly I don't even think I've ever been asked about syntax in an interview.
It's just expected that you know it to a reasonable degree. The fact that you've had a job in the first place is usually enough to show that you can work in a language to a competent level.

Of far more importance than language syntax is program structure, design, experience with libraries/technologies, etc.

You should never walk away from an interview. Especially if you are a university Grad. Some interviewers do not spend a lot of time preparing interviews for new hires. It's not they're day job to interview people. Your technical interview is usually not carried out by a recruiter, but rather by a "Coder" like you. Sometimes they just download some quiz from Google. That does not mean that they will be bad team mates or that the job is going to be bad.

I manually went through each line of code to see if I could uncover the cause of the error. And I learned a valuable skill. Debugging; without having to rely upon my IDE to tell me which line I messed up and why. As a result of this experiment, I've become far more meticulous when I write code, making fewer syntactical errors than I had beforehand.

How is this (which I'd catagorize as de-linting), an important skill? Does it raise your productivity in any way? Why not use a javascript lint analyzer instead? Have you tried using a good javascript IDE like webstorm?

I remember a defining moment in my career: People were writing a complex compression algorithm on an embedded chip with a subset of C. They were using notepad because the chip did not have an IDE or a debugger. So you "couldn't use an IDE"... When we did switch to an IDE with an integrated debugger we were able to re-write within 2 days what the previous team could not write in a week. All because they were using "old school" tools on an "old school" system. Later, we did re-optimize the code footprint via assembly list files, but we did as much work as we possibly could on a PC in Visual C++.

Since then, I have come to view this as professional negligence. Wasting one month of development (and shipping bugs to customers) in order to be "old school" is counter productive.

I started programming before IDEs were any good, It was a terrible waste of time. Why would anyone want to go back to it?

How is this (which I'd catagorize as de-linting), an important skill? Does it raise your productivity in any way? Why not use a javascript lint analyzer instead? Have you tried using a good javascript IDE like webstorm?

I remember a defining moment in my career: People were writing a complex compression algorithm on an embedded chip with a subset of C. They were using notepad because the chip did not have an IDE or a debugger. So you "couldn't use an IDE"... When we did switch to an IDE with an integrated debugger we were able to re-write within 2 days what the previous team could not write in a week. All because they were using "old school" tools on an "old school" system. Later, we did re-optimize the code footprint via assembly list files, but we did as much work as we possibly could on a PC in Visual C++.

Since then, I have come to view this as professional negligence. Wasting one month of development (and shipping bugs to customers) in order to be "old school" is counter productive.

I started programming before IDEs were any good, It was a terrible waste of time. Why would anyone want to go back to it?

As this forum doesn't have upvoting i've given you my own make-shift THUMB-UP X 3

The Old-school thing is another clear example (as stated in my earlier reply) which shows that paper code-test can be counter productive in addition to being utterly senseless

Ditto for remembering the parameters for API methods. We have google now, so we can focus on the problem, not the language and hey before Google?

And this also

The fact that you've had a job in the first place is usually enough to show that you can work in a language to a competent level.

You're not applying for junior positions, though. Sure, I'm generally not going to ask a senior engineer who looks like they know what they are doing about syntax, and if they demonstrate obvious skill/knowledge, they can push back on low-level details without issue.

But for engineers applying to their first or second job out of university? I certainly will. A large percentage of candidates at this level fail extremely basic proficiency tests: can they write a syntactically valid function? Can they write a recursive function? Do they know how a HashMap works?

Which is to say, I think you are right, but that it's also terrible advice for someone in university - if they walk out of an interview over something as trivial as being asked to write syntactically correct code, they aren't likely to get hired again, any time soon.

Which is to say, I think you are right, but that it's also terrible advice for someone in university - if they walk out of an interview over something as trivial as being asked to write syntactically correct code, they aren't likely to get hired again, any time soon.

Fair point about the first/junior positions. It's been a good few years since I've dealt with that level from either side of the interview desk.

I still think that asking a candidate to write code by hand is a suboptimal way of assessing their ability though. Reading code? Absolutely vital, and a great way to filter out candidates ("tell me what's wrong with this" or "how would you improve this").

But more and more I am convinced that the only way to assess someone's ability is to get them to execute a real task, preferably in a real code base (NDAs, etc) over a few hours. You should sit with them for the first hour to familiarise them with the task and then leave them to it. If they use google, who cares? They'll use google every day in real life, In fact, being able to efficiently get answers on the web is a key programming skill these days (as is being able to differentiate good from bad solutions). Then get them to present the solution to the team. Make them defend their decisions, etc.

It's a costly way of hiring, but far less costly than hiring the wrong candidate.