Do you think that being able to implement a linked list is a fundamental programming skill? Because if an advanced programmer is lost her ability to relate with novices ("my boss can't even implement a fucking linked list") I'd say that'd be a bad thing. In my humble estimation, experts tend to be bad teachers because they have lost touch with the frames of novices. The best teachers are ones who have most recently m…
Depends on the position. I have worked, recently, on codebases where that kind of thing was absolutely a core skill and we asked people to write linked list code in the interview process. We were also doing manually-managed core OS and display manager code for a mobile operating system.
In my current job writing server-side Java and Ruby on Rails code, I wouldn't dream of asking that question. It would be pointless.
I don't really understand this mentality. Is is really that hard to get rid of the charlatans that slip through after the fact? Just monitor them fairly closely (but secretly) for a couple of weeks. Have some sort of object measure of performance for that time period. If they don't pass muster, get rid of them. This seems like a better method than spending 6 months to fill a couple of positions.
Training and getting someone up to speed for a few weeks, then getting rid of them (if it doesn't work out) wastes more time and money than spending several months to fill the position with the right person. Laying people off for performance is hard to quantify, not to mention I certainly wouldn't want to be working for a company who is secretly monitoring new hires' performance.
Amen. Someone in my orgzn was let go very recently. I'm not in mgmt so only had a peripheral view of what transpired, but the orgzn I'm in is very loose and generally hires strong candidates with very high success rate. We don't have a lot of time to spend monitoring performance closely; we expect people to work independently and deliver in a non-sweatshop environment. Once a problematic situation is recognized, it sucks up a lot of time, energy, and karma (heavy HR involvement, PIP programs set up, tracked, etc.), and of course we have tasks which the individual was expected to be completing; now not so much. Also, the months spent bringing up to speed someone who will now never contribute to the team, time and teammate energy which could have been expended on a better candidate. The net cost has been huge. I remember there were some doubts about this individual at interview time (and our interview process is nowhere near as severe as what is described to take place at Google, etc.), and these were ignored (there were "extenuating circumstanced"). I'm reminded of a quote from Ronin "Whenever there is any doubt, there is no doubt." Even though from a fictional source, it's good advice. Also: "no exceptions".
I disagree. If you know what a binary search tree or linked list is, you should be able to code them. If you can't do something this simple, how can you be expected to actually solve a problem that you can't just look up the answer too?
I'll agree with this on one condition: don't hold syntax errors against me. I interviewed for a position about eight months ago. I was rusty with my C (had been doing more java and python around that time), and put "int i = 0" in a for loop on a white board and seemingly had it counted against me. This kind of thing, along with things like missed semicolons, should be ignored by interviewers. Not only is it a simple…
Assuming you mean for (int i = 0; ; ) {} that is legal syntax. Perhaps I'm dull, but what is the error?
If I found this article by a potential applicant, I'd be much less likely to hire them. Besides the obvious red flag of the sentiment why should I have to code at a programming interview , the knowledge that they have been rejected by many other companies would make me worry.
If the job is to code on whiteboard: definitely don't hire.
I believe that /this/ is short sighted. I do interviews, I care less about the right answer than I do about the problem solving approach. I interview electrical engineers and I make them do simple transistor problems. If someone gave up and said that they couldn't do it without some sort of SPICE program, I'd cut the interview pretty short. But if the fundamentals are there, even if they don't remember something stup…
My point is that a person's inability to code on a whiteboard has little to do with the value they can provide to the business. Some people just aren't good at it, and why should they be penalized for it? There are other ways to get programmers to write code in an interview, and a simple "Do you prefer to code on the whiteboard or on a computer?" can resolve this. It's not as though that's a huge burden on the busine…
I've been doing a lot of interviewing recently. When people struggle with a white board problem, I give them a laptop to code on. I have yet to find someone who struggled at the white board, but did fine on the laptop. Maybe they exist, but I tend to think there's a high correlation between white board performance and laptop performance.
I don't really understand this mentality. Is is really that hard to get rid of the charlatans that slip through after the fact? Just monitor them fairly closely (but secretly) for a couple of weeks. Have some sort of object measure of performance for that time period. If they don't pass muster, get rid of them. This seems like a better method than spending 6 months to fill a couple of positions.
Training and getting someone up to speed for a few weeks, then getting rid of them (if it doesn't work out) wastes more time and money than spending several months to fill the position with the right person. Laying people off for performance is hard to quantify, not to mention I certainly wouldn't want to be working for a company who is secretly monitoring new hires' performance.
Some organizations openly set out the first few weeks or the first month or two as a probationary period for new hires, but you're right about the cost effectiveness to some extent. A six month recruiting process might cost a few hours or days every so often from a few employees, but won't add up to even a single month's pay for a bad employee. Add in a cultural practice of risk-averse hiring (don't hire any B or C players) tilts the scales even further.
That said, I can imagine some cases where opportunity cost and being more concerned about getting good employees than immediately weeding out potentially bad employees would lend one to the probationary thing.
This is why I don't ask candidates to code. I ask them to describe concepts, articulate trade-offs, and/or walk me through their process of solving a real problem (usually something I've just solved so that I'm intimately familiar with the space).
Do you think that being able to implement a linked list is a fundamental programming skill? Because if an advanced programmer is lost her ability to relate with novices ("my boss can't even implement a fucking linked list") I'd say that'd be a bad thing. In my humble estimation, experts tend to be bad teachers because they have lost touch with the frames of novices. The best teachers are ones who have most recently m…
It's a pretty damn fundamental skill; even so fundamental that I'm not sure if it even deserves a specific name.
As a linked list is nothing else but pointers and blocks of memory that are the nodes, and setting the pointers of nodes to point to other nodes. This is something any programmer worth his salt would soon deduce on his own even if he, for some mysterious reason, didn't know linked lists.
Many probably have in their younger days. And when they finally read about linked lists they go "ha, what I have written actually has a name". If you just merely keep doing allocations of similar structs or objects that you want to stash some place, you're implementing a singly linked list the minute you think of a "next" member in your struct.
Like so many complaints about coding in interviews, this is talking about coding for a bad interviewer. Listening to both sides of the argument I've come to the following conclusion. Just as the unthinking mantra is now "90% of applicants for programming jobs can't program," equally often we hear "99% of interviewers can't interview."
Interviewing is a two way street, and programming jobs require more than just programming wizardry. You will need to work with a team, you will need to communicate with management, and you will need to understand people who aren't programmers.
I'll agree with this on one condition: don't hold syntax errors against me. I interviewed for a position about eight months ago. I was rusty with my C (had been doing more java and python around that time), and put "int i = 0" in a for loop on a white board and seemingly had it counted against me. This kind of thing, along with things like missed semicolons, should be ignored by interviewers. Not only is it a simple…
Assuming you mean for (int i = 0; ; ) {} that is legal syntax. Perhaps I'm dull, but what is the error?
I think the point was that in C(89) you need to declare all variables at the beginning of the scope block.