15 ms·
> There are just too many crappy "senior" developers out there. In what ways do you find them crappy?
by mkagenius 10y ago
> There are just too many crappy "senior" developers out there.
In what ways do you find them crappy?
- cerrelio 10y agoI'd like to know too. I'm a senior dev with 10+ years of experience. I don't do interviews that require a coding portion. It's a little insulting to me. I know what a binary search tree is. I've never written one outside of college, because they're already implemented in the tools I use. I'm not going to waste my company's time doing freshman-year exercises. If I need to know a specific structure or algorithm, I have books filled with hundreds of them. I know how to use a book's index. I just assume any company that makes you code during the interview for senior positions is looking for a code robot. My skills have advanced beyond that point. I don't want to go back there.
- garysieling 10y agoDoes that mean you're looking for management type positions? It's been a while since I've interviewed, but I always thought at least a little bit of coding in an interview was good, because you know the company weeds out people who are lying about being programmers.
- cerrelio 10y agoNo, for development positions. If a recruiter can't weed out posers before a manager/developer talks to them, that recruiter should be dehired. To get jobs at my current and previous company, I just talked to the lead developer for 3+ hours. No coding necessary. I was quizzed on design patterns and given architecture problems, which I find more appropriate than FizzBuzz. Also, my alumni association is very useful for job hunts. I'll never go back to cold-calling or responding to LinkedIn solicitations again. I chat with an alumnus over coffee for a few hours, and twice it's resulted in job offers without the need for a formal interview.
- garysieling 10y agoThat makes sense. I think if I was looking now I'd probably call people I used to work with rather than bother with interviewing. The failure rate on FizzBuzz type tests is really high though, and it should take 30-60 minutes (which would save you the 3 hour discussion on the failure mode). Of course, if you were going to interview at a bunch of places, it would be better if you only had to do that test once. Recently it also seems like more people are over-prepared to interview than ever before. At the entry level code academies prep people really well to appear more "senior", and other people are studying the "Cracking the Coding Interview" book. The challenge for the interviewer is determining if the person has memorized a bunch of interview sequences or if they understand the material they are talking about. I'm inclined to think some form of programming with discussion in the interview is still a good signal, if it's like what you'd actually be doing.
- Orion1021 10y agoHow do you utilize your alumni association? Do you look for people from your alma mater working at a company or contact the actual association?
- garysieling 10y agoI don't know what the other commenter is doing, but if I was in that position, I'd find a linkedin or Facebook group for my school, find people in the area, and contact them directly to get together with me for lunch or coffee, and ask them for for career advice. The alumni association for my school also has local meetups in many cities, so that would be a good avenue as well. A lot of places offer recruitment bonuses, so I suspect that if you contact someone and there are openings, they would be willing to help.
- ng12 10y agoThat's a terrible attitude. If you can't be bothered to complete a coding exercise just so I can verify your skills what happens when you have to do something on the job you consider beneath you?
- cerrelio 10y agoYup. Not worth my time.
- toomuchtodo 10y agoNot a terrible attitude at all. Its unacceptable for a corporation to maximize its efficiency while frowning on a potential candidate doing the same. Level the playing field. It's a seller's market (tech workers are still very much in demand).
- mhluongo 10y agoThe problem is you're trying to verify the wrong skills.
- eropple 10y agoIt's always so very strange that, as a consultant, I am never asked to perform the kinds of jump-through-hoops stuff that hiring candidates are, despite often having more access to their systems than those candidates will if hired. Maybe it's because the whole thing is nonsensical power plays on the part of hiring managers when candidates don't realize that it's a seller's market and they don't have to play the game.
- bumbledraven 10y ago> It's always so very strange that, as a consultant, I am never asked to perform the kinds of jump-through-hoops stuff that hiring candidates are, That's not strange at all. It's much easier to "fire" a consultant than an employee.
- eropple 10y agoAt-will employment, dude. Termination at most companies below the size where bureaucracy sprouts (where most of my business comes from) is a pretty trivial "you're out." Rather, it's a recognition that we are business partners and the relationship must be collaborative and in good faith, with a much different dynamic than employer/employee.
- adekok 10y ago> I'm a senior dev with 10+ years of experience. I don't do interviews that require a coding portion. It's a little insulting to me. I've interviewed multiple people with such experience who knew next to nothing about C. char *p; *p = 'c'; Q: What happens here? A: The character 'c' is assigned to the location pointed to by 'p'. Q: What does 'p' point to? A: Memory Q: Can you be more specific? A: To dynamically allocated memory. By the compiler. <sigh> Get out. The conversations are a bit longer that that, but that's the short summary. Some people can operate in a corporate environment, but have literally no idea how to use the language they've "programmed" in for 10 years. I say "programmed" because I have no idea what they're doing, but it isn't using the language they claim to be using.
- exBarrelSpoiler 10y agoSounds like corporations should either: 1. Lower their standards and admit that many, many coding positions are API gluing and tinkering with libraries to fulfill business requirements, and not actually about engineering. Software is in a state where you can be a non-engineer and still write performant code, or at least satisfactory work, thanks to the other people who actually write those libraries. Entire successful products, even companies, have been launched on less-than-optimal code. OR 2. Actually spend time cultivating their engineers, and allow them to gain access to deeper understanding of CS, by giving them the chance to work on non-trivial problems. Maybe stronger standards need to be built into the industry as a whole, engineers should be encouraged to take a regular coding challenge outside of work, to ensure that they still remember their fundamentals. Or at the very least, they should be assigned work by the companies that is more than API gluing. Either way, it seems unfair to place the entire blame of a candidate who has 10 years of actual development experience for having the wrong type of experience. I'm sorry, but that wrong type of experience could still make deadlines, launch products, and bring value to companies. Either be open and transparent about your industry requirements, and give engineers a chance to live up to them, or accept that technology has advanced to a point where people can "program" for 10 years without knowing- or remembering- the fundamentals. And at the end of the day, isn't that the abstraction and convenience we're pushing for? Also remember that there's a difference between a developer who's been working on say Rails apps ten years, and one who's been working on compilers or embedded code. As far as the examples you brought up: did those candidates actually develop in C for ten years?
- jdavis703 10y agoThere's lot of senior people out there who work in "doer" type roles that can't design, code, write tests, etc despite that being their role. As long as charlatans exist I think every company should expect some demonstration of ability, because talk is just talk (unless they're hiring for a sales-type role).
- johan_larson 10y agoI understand that coding interviews are frustrating. Believe me, I've been there. There should be some other way. But you are closing some very weighty doors by refusing to do coding interviews. Google requires them. Amazon requires them. Microsoft required them back in the day, and still may. Those are some mighty tempting opportunities to say no to, over a point of pride.
- cerrelio 10y agoGoogle contacts me every three months. I keep turning them down, because in addition to their coding tests, they require days of interviews. I'm a working professional. I don't want to take days off to go through a useless process. To any Google recruiters/employees: If you want senior engineers, please don't treat them like college grads, diploma fresh-in-hand. I'm building shit all day, I don't want to cram for a battery of interviews.
- eropple 10y agoThis is where I'm at, too--like, I'd love to entertain the idea of working for Google, but I work for a living. Right now, taking two days out of my work schedule means I'm out an opportunity cost of somewhere around two thousand dollars at my standard rates. The "honor" of interviewing at Google is not worth that.
- Rapzid 10y agoSame here. LinkedIn, Facebook, and Google will all reach out and then toss you into their standard interview process for people coming to them looking for a job. Can't be taking time off work for everyone who contacts me; particularly when there is no specific position/salary on the table or even any indication of real interest.
- rimantas 10y agoPeople still find Amazon and Google attractive?
- johan_larson 10y ago
- raverbashing 10y agoI kind of understand why people ask coding questions. I've seen people with "ample experience" that can barely code a hello world. Or have major vices and bad habits (like creating constants like HELLO_MSG="Hello World" - typical of old people writing Python/JS/etc). Just don't ask me to code a FizzBuzz, that will just p. me off
- brianwawok 10y agoString constants actually have a place in Java or many languages. Just because you don't understand doesn't make the writer old. (Not even sure what that means, some hip way to reject people that know how to code under the guise of age)
- raverbashing 10y agoOh I know they have a role in some languages, I know it's "old" because that's how it is written in C, for example, and I'm not rejecting them for being old, I am rejecting them because they can't adapt to the coding styles of specific languages
- iopuy 10y agoWe interviewed someone with this exact same attitude. He actually said "I've moved past doing these exercises in an interview" and refused to answer the question. Basically we just sat there for the rest of the interview. Afterwards I talked with my colleague about it. Is his mentality that the questions are so easy they are a joke to him? His skills are so far beyond whatever simple questions we are asking him to solve that it is insulting? Does he think that by giving us that answer we will believe he is superior? I cannot fathom going into a development interview and then refusing to answer "simple" questions on development. More than likely THIS person just was looking for an escape before getting called out on his bullshit.
- tedmiston 10y agoIt's not about being superior but questions like this at an upper level interview are a waste of everyone's time. Some startups insist on asking devs with 3, 5, 10 years of experience the same CS 101 interview questions as someone just out of college.
- thedufer 10y agoAnd yet, there are devs with that much experience that can't program their way out of a cardboard box. What do you prefer to do with them?
- tedmiston 10y agoI don't have a one-size-fits-all solution. The Peter principle is one thing to think about. Another is finding those developers roles that suit them better. Maybe that's some other aspect of the software pipeline like QA or testing or internal tools. Perhaps someone with more experience interviewing and hiring (or not hiring) in this category can provide a better suggestion.
- thedufer 10y agoI mean, I wasn't _really_ looking for a suggestion. I interview them and tell them we're not interested. Which seems like the right thing to do in this situation. This idea of hiring everyone with experience and hoping you have a job for them doesn't seem terribly sustainable. > Another is finding those developers roles that suit them better. Maybe that's some other aspect of the software pipeline like QA or testing or internal tools. I'm used to QA and testing being done by developers. This results in a lot of high-quality automated tests, which are much cheaper than testing the same thing manually every few days. Internal tools is where I would want my best developers, I would think. Dragging down the productivity of the entire department by having bad internal tooling is pretty worst-case.
- markbnj 10y agoI understand your attitude a bit. I have 25 years of experience, and I admit to harboring a little bit of frustration when all that is just shoveled to the side and they start treating me like I have to prove I know what programming is. If someone were interviewing a doctor for a position at a practice the candidate would probably be just a little miffed to be asked whatever passes for basic knowledge questions in that profession. Of course physicians have all sorts of certifications and licensing and ongoing recertifications, and its much, much harder to get into that profession so outright posers are rare. So for that reason I don't actually mind proving I can do the work. But I do strongly dislike whiteboard style "do this in five minutes or you're not good enough" interviews. My current company asked me to do a take home project and workalong day. Both were fun and both were compensated and it ended up with an offer, so it's all good.
- shshhdhs 10y agoDoctors prove the prerequisites via their board exams. Coders have no proof of prerequisite knowledge.
- nickpsecurity 10y agoMany have Github's, FOSS contributions, and such with their code in them that can be reviewed. How serious the project was to them will vary. However, I would ask that they tell me which they put real effort into and how. I'd look at it to verify. That's a start as it tell me directly how they code supporting real-world work.
- user5994461 10y agoDo you take it bad when an exercise is to print numbers from 1 to 10 (inclusive)? :D Then repeat, with a function to print numbers from 1 to n (given as argument).
- dudul 10y agoI have a coding session when I interview a candidate. A very simple problem they have to work on with a junior dev we have on staff. The goal is not to get the answer, it's to work efficiently with the less experienced dev. I'm sure you know how to write a for loop or a singleton, but guess what? If you are a senior I care about how you interact with somebody who does not know these things. A 10+ year of XP developer has to be passed being a code monkey and be focusing on carrying the team, not just fire up an IDE and piss out some code.
- cerrelio 10y agoI would go on an interview like this. You actually see the candidate in their role, and not just their mundane ability to vomit up a BFS implementation or some such. You see their interpersonal skills (must have) and their ability to get others to complete things.
- MrQuincle 10y agoCool, that's a nice strategy. And in that case you don't even need to make the problem simple at all! What I also always try to do is give context: "You're now writing a seemingly ad-hoc double for-loop in which you assign some function to each pixel. What you should look up is a Hilbert space." I don't know how to test for that though. :-D
- mindfulgeek 10y agoYes! This makes sense.
- meshko 10y agowait, but what is it that you do? If you are getting hired to write code, you should be ok demonstrating that you can code in the interview. If you are interviewing for an architect position, or a manager, I guess. Whether a not coding architect/manager is a good idea is another question (I personally think that the answer is no, any good sr person will have to do _something_ hands on, up to the C level).
- deleted 10y ago[deleted]
- hyperpape 10y ago5 years experience with JavaScript, can't tell you what "var" does. This is not a hypothetical example.
- cerrelio 10y agoI don't know either. It's something with scope probably. However, disqualifying someone who doesn't know a concept that can be explained in 30 seconds is short-sighted. Here's an analogy for that: You can drive a car, right? Okay. Do you know what a transmission is and how it works? You don't?! Sorry, I can't let you drive my car.
- tene 10y agoThat doesn't seem remotely like the same analogy to me. If we're talking about analogies, a much more accurate analogy, in my mind, would be "You can drive a car, right? What do you use this lever here on the steering wheel for? You don't have any idea? What about this lever here between the seats? No idea about that one either? Sorry, I don't believe you're competent to drive a car."
- hyperpape 10y agoAgreed. I was just about to make analogy of pointing to the parking brake and asking "what's this?". Also, depending on the role (most people here write both Java and JavaScript), we're fine with "I'm not sure, but I always use it", or something vague about global variables.
- cerrelio 10y agoThe point is that using "vocabulary" tests to determine programming ability is nonsense. You can still write useful JS without knowing what the hell "var" does. And if you discovered that person doesn't know what it does, then it's trivial to correct.
- nadam 10y agoYou say that you can write useful programs in a language for 5 years without knowing how to declare local variables? Wow. Yes, I wrote useful programs using only global variables in C64 Basic when I was 12 years old, but it was much worse code than I write now.
- tene 10y agoI've been trying to hire sysadmins for my team recently, and sit next to someone trying to hire senior engineers for our infrastructure team. Candidates for my team first get screened by recruiters, then have a couple of phone calls with HR and the hiring manager, and then if they sound good are sent to me for a technical screen. I give them a fairly simple scenario with extremely clear symptoms, and all I'm looking for is very basic problem-solving skills. I want to see the candidate come up with a theory about the problem, then try to prove or disprove it, or any attempt to narrow down the problem space. The majority of candidates, even those claiming two decades of linux sysadmin experience, appear to have basically zero troubleshooting skills, just keep repeating cargo-culted "restart things" rituals, repeatedly keep checking things that are already ruled out by the symptoms and all their previous steps, and sometimes get angry and defensive when I claim that their "solution" wouldn't fix the problem, or claim that they'd see certain behaviour in the scenario. I would not trust these people to find their way out of a wet paper bag without a "runbook" containing that exact scenario, down to the color of paper and precise moisture level. This problem is not exclusive to senior engineers. Even trying to actually hire someone just to follow directions is very hard. A while back, we wanted to hire a contractor to do a few hundred hardware upgrades in our data center, along with a few other tasks, all very repetitive and well-documented, so I printed out our documentation for adding a new server to our asset database, set up a copy of our asset database on a spare laptop, and brought it in to the interviews I did with those candidates along with a server, and my entire interview was just "Follow these written directions, exactly as written; this is literally one of the tasks we want to hire you to do." Only one candidate out of five was able to complete it successfully, and all the others just had an endless string of questions that were clearly answered right in the document. For example, the document would say "asset_serial: this number should be on a sticker on back of machine.", and they'd apparently just skip over it, get to a later part that wants a serial number, and ask "Where's the serial number? I don't know what to enter here." They somehow didn't start reading any more closely after forty five minutes of me saying "That's answered in the document; please read it more carefully." repeatedly. My colleague who's been trying to hire for a senior engineering position has been doing one-hour phone screens with an extremely simple text processing programming challenge, "Given text like this with numbers like that, give me this aggregate summary of the numbers", to be solved in any way you like, with any resources you like. Almost all candidates, including those who claim multiple decades of programming experience, fail to get anything that works. Every candidate we've had so far who chose to write a solution in C++ hasn't even produced a program that compiles successfully. Just to make sure we're not completely miscalibrated, we've had engineers already employed here try it, and they universally got a working solution in about ten minutes or less. When you're trying to hire, the vast majority of applicants will be terrible, because nobody wants to hire the terrible people, so they vomit applications across every company they can possibly find, and continue to do so for long periods of time, where the high-quality engineers usually find a job through professional networking without ever trying to come in through the front door, or very quickly get and accept offers and so are on the job market for a very short time.
- jwatte 10y agoA typical "crappy senior dev": Able to talk for hours about design patterns, but not able to print the sum of four integers when given thirty minutes, an editor, and a compiler for their favorite language. A "senior dev" whose qualifications are only recommending Cisco hardware (for others to manage) and HP blade servers (for others to manage) is not what I'm looking for.
- mavelikara 10y ago> In what ways do you find them crappy? Not the OP, but I can narrate an incident here. When we were hiring for my team, we had candidates do a small coding assignment. It was expected to take 2-4 hours of work, was for a toy problem which was a simplified form of something we used in production, and contained no puzzles or "a-ha!" insights. We got a submission from a candidate who has been in the industry since 1994. The candidate had used a static variable when a member variable was the right thing to do. The class (in Java) looked something like this: class Foo { static Map map = new HashMap(); void addStuff(String key, Object stuff) { map.put(key, stuff); } int getSize() { return map.size(); } } Now, he had a test to go with it that looked like: void testFooInit() { Foo foo = new Foo(); assertEquals(3, foo.getSize()); } The value 3 was chosen, apparently, such that the JUnit runner from Maven would have the test pass! But the tests would fail randomly when run from within IntelliJ. So look at this way - the candidate had long years of experience, had an impressive resume, did code that superficially looked OK, knew enough to write tests and package a Maven project. Yet, that non-sensical test indicated that he had missed the point about unit testing completely. I am sure that the candidate is a productive employee at his current position. He might have written such bugs into his codebase, identified it in production, would have valiantly debugged and fixed the issue, and would have gotten kudos from his management. -- Having said that, I agree with the sentiment here that HackerRank questions are complete waste of time! It seems that the only employees HackerRank can attract to build a question bank are fresh CS grads, and they make up problems which they are aware of - TopCoder-style, array/dynamic programing/regular expressions/counting problems. These questions come up as irritating when a seasoned programer is trying to find a job.
- mkagenius 10y ago> knew enough to write tests and package a Maven project. thats enough for me to not call him "crappy" ...perhaps i would call him "ok"
- __derek__ 10y agoHow so? Given the status quo bias, writing meaningless tests is worse than writing none at all. It gives the illusion that something is well-tested and may even lead people to write code in order to accomodate the test. That causes real damage on a team. Being able to cargo-cult to provide the illusion of competency should get no credit.