Over the past several months about 4 out of 10 companies that interviewed me actually required me to complete several HackerRank challenges because I did not have a HackerRank score. The fact that I have worked for several industry leading companies, and had 20+ years of development experience was irrelevant without that score. As a sr. dev manager, I found this to be an odd requirement.
I'm totally okay with that. I was fresh out of school and was working at a small consulting company that required us to go work with some larger companies and lots of "senior" devs - 10+ years of experience all of them - I'd say 50-60% of them could not code fizz-buzz.
There was one meeting with two devs, both of whom had worked as programmers for over 10 years at this company and we were looking at code one of them wrote. The code looped over a string's chars to check for a single char's existence, and there were 26 IF statements: one for each alpha character. I had to explain to these two about the "contains" method. 10 years of programming experience each. And I had to show them the "contains" method... Since then "X years of programming" doesn't mean a thing to me.
How are people that can't do fizzbuzz able to function in a programming job? The thing you describe should lead them to struggle with virtually anything. I used to do front line interviews, and it was rare even then for people like that to make it to me. I've mostly worked for large, successful tech companies. I don't see someone like that getting a job, and definitely not being able to hang around for a long time.
I assumed they got by without doing much work. I was there mostly to fill budget. This company had a policy that projects had to meet budget. Their window was 2% under budget or 5% over budget or they would get in trouble (or maybe the budget was less next time or whatever).
As far as I could tell they would just try and get lost in process as much as possible and not do any work. I just went with the flow, I wasn't trying to make waves. Also, I was only working with those two in particular for two months. Did almost nothing. Took a week to get approval to add a column in a DB. I could have written all the code that eventually went into production in 5 minutes without red tape, and that included testing.
In the contracting world, I get one of these people every year or so. They jump onto projects often, are discovered, given warnings and improvement plans, and usually find another project before they're actually fired.
Their big asset is that they can be billed at high rates but only get paid minimally themselves, allowing the contractor to pocket large profits. The bean counters love to hire them, and just expect the good developers to carry the dead weight.
Not to appear to be misogynistic, but 3 out 4 of these, at least in my experience, are women. Usually they can coast far longer than most men because there is always one easily manipulated male dev on the team who gets suckered into helping her do all her work. I was that dev once early in my career.
But it makes sense for contracting firms. People get billed no matter whether they do (or can do) anything. The ability to execute is not part of the job.
Because 'writing code that somehow works from business perspective' and 'writing well-designed, readable, maintainable and optimized code' are two different things.
I have similar situation when Team and Tech leads in our company write shitty and unmaintainable code. But they've spent N years in the company and became leads because of that.
This is a good lesson though: at the end of the day, revenue is the only thing that matters. The CEO doesn't care if you are looping through strings using if loops or string.contains() or whatever, because he knows that what keeps the company in business is whether the contracts get signed, which they often do as long as the product works reasonably well and satisfies customer requirements.
This isn't to say artisanship is unimportant, but that it's not the most important thing.
You're right, but it misses what's really happening: it's a trade off between short-term and long-term productivity. Essentially, writing bad but working code quickly today means technical debt, bugs, and taking longer to add features later.
Decent developers can avoid this trade off, and write decent code in the first place in about the same time. The trouble is, the CEO typically can't tell the difference. Even long term, it's hard to identify if something is taking long because the team is rewriting crappy code or undoing shortcuts, or the task is just difficult.
"The thing you describe should lead them to struggle with virtually anything"
... And now you know how Comcast help pages describe settings that do not exist, and why RiteAid calls me "Nancy Brown" when I log in and on and on.
A bureaucratic IT department in a company that doesn't sell software as their main product usually does not have the meta ability to rock software development.
Presumably in their preferred language, or with acceptable pseudocode?
I find that baffling, and I am self-taught and a very mediocre programmer. I'd barely even call myself a programmer as I've historically spent more time designing. I can't think of how they might be stumped by it?
Is it true even of programmers with experience/age on their side, likely to have encountered loads of real world challenges? I've gone back to read about it a couple of times since first hearing of it - swear I must be missing something?
Is it possible that they're both unfamiliar with the language/environment? I doubt I could write a working fizzbuzz in go, and it's been so long since I've written C that I'm genuinely not sure if I remember how to write a working program.
That's what I've always been asked to do, and what I always ask to do. I don't want someone stumbling over "is it toLowerCase() or toLower()?" while they're thinking.
I've read that same stat elsewhere, so thanks for the confirmation. Maybe these people are nervous? Sometimes your mind goes blank when you go into an interview, so I'm interested in knowing how far they actually get when solving the challenge.
I assume that most of them fail to get the logic right. Yes, even those the logic might seem to be trivial, a lot would fail to either get even the pseudocode correct. Many others would fail to translate it correctly into code (even in their preferred language).
I found that OP's key phrase is senior dev "manager".
Senior dev are required to have these skills brushed out for a technical interview, however 80% of dev manager don't program at work anymore. Asking them for this kind of skills that are not going to be required in the actual job is a bit odd to me too.
HackerRank must have genius salespeople. I can see the whole pitch unfolding on the back of my mind: how it saves valuable interview time, ensures skillset validation, follows best industry practices and only improves as new candidates flow through the system, because BIG DATA.
Toss in a slide crammed with logos for top technical companies who've signed up for a free trial and never touched it again, and you've got a killer pitch for hiring managers at smaller shops who honestly can't hire tech folk to save their own skin.
> Toss in a slide crammed with logos for top technical companies who've signed up for a free trial and never touched it again
However, those top technical companies are the same ones who report manipulated video views, manipulated user base numbers, actively renege on promises after major acquisitions, and generally show the way to these smaller companies.
The overarching philosophy underlying growth hacking and conversion optimization today is: Lie and let lie.
The end user is the poor sucker, so perhaps it sort of cancels out? It is amazing how many smart people work for companies which are super manipulative under the pretext of working on "hard problems". One would wish the hard problems were becoming tractable because of human ingenuity. Unfortunately, it turns out most of the time it is just a consequence of finding more data points from newer sources of data, and most of the ingenuity is simply going towards trickery which allows even more data collection.
Was it in lieu of a phone screen? A lot of companies do that now, and it's generally done for the same reasons as a phone screen. My company doesn't do this, but we do phone screens for every developer, no matter how much experience they have. There are just too many crappy "senior" developers out there.
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.
I 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.
Many 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.
We 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.
Last year a large well-known company contacted me, unsolicited, and said they were interested in hiring a Django committer (which I am), and asking me to apply to work for them. Then they put me in the "prove you can write basic code" phone screen bucket, and I walked away. If they're going to waste my time and the screener's time on something they already know -- given why they're reaching out to me -- then I'm going to reasonably conclude they're not a company worth working for.
Would you then label me as unable to code and "looking for an escape"? Or is it possible there's just more to the story than you happen to know? Because that is not the only example I have of this kind of thing.
That sounds like a serious miscommunication between the person who originally reached out to you, and the person doing the interviewing.
I've interviewed several candidates, and sometimes there's been a time crunch, and I didn't do more than read their resume and do a quick google search to make sure they haven't recently escaped from a federal penitentiary or something. Perhaps your interviewers didn't know your prior qualifications, or that you were meant to have been fast-tracked past the "has a pulse" section of the interview?
It's likely that a serious mistake by the candidate leads the company to end the interview process. Why then should I, as the candidate, not apply the same standard to them?
You're basically asking someone with a PhD in math to do a long division by hand. It's irrelevant and honestly, they may not even remember how.
While I still answer stupid whiteboard questions (though I'm not happy about it), I'll flat out refuse long winded ones or interviews where it's all they do. It's nice to weed out who cheated in their finals in CS, but it's pointless in testing if a Principal Engineer really is there.
At upper levels, there's no one size fit all. You look at the person's resume and you tailor something around it. You won't have nearly enough applicant at that level for it to be a burden, and it's exactly how director/VP/exec positions are filled.
For mid range and low Sr positions, sure, do whatever.
> You're basically asking someone with a PhD in math to do a long division by hand
More like someone with an online PhD in Math that isn't easy to verify. What it boils down to is "I worked at these companies in this role. Believe me".
I think people get mixed up with management and technical tracks: Lot's of "senior devs" have coasted for years playing office politics and lost touch with actual development, I suspect those are the ones who get offended and would rather talk about the more abstract/higher level topics which may or may not be relevant to their expected duties, if they are being hired as as senior developer.
> More like someone with an online PhD in Math that isn't easy to verify. What it boils down to is "I worked at these companies in this role. Believe me".
All human relations including work place relations are impossible without trust. Asking the equivalent of "what is 2 + 2?" is a sign of distrust and a good reason to decline the job.
They can still pass the interview that doesn't mean what's written in the resume is true. You got to trust them or find other ways to find out if the resume is honest.
I have seen developers who are good at answering interview questions because they trained for that specifically.
It'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.
RIGHT. This is exactly why these tests are given. In Deliberate Practice, these people are called experienced non-experts.
Ten years of bad programming may make you experienced, but it doesn't make you good.
I would question the big-picture awareness of any competent developer who refused this section of an interview. How senior can you really be if you don't recognize why this section of the interview is being given?
I think we are discussing two different cases. I was referring to the dev that recognizes why it's given but philosophically disagrees with this approach of the company's interview process.
(By the way I'm a huge fan of your app and have used it every week for years.)
I cannot agree with you more. It is unfortunate that experience is often taken as synonymous with years alone and skill or knowledge gained or a lack thereof is ignored.
Better opportunities meaning they don't have a coding verification step for senior engineers and so some of your peers don't actually know how to code (permanently or just for awhile before they get outed and fired)? That sounds like a worse opportunity.
I have worked with good technical managers and know of good sales engineers that might not pass a coding verification test like this. I don't think it's right for every role. But that test doesn't directly correlate with the responsibilities of their job. I'm a big fan of contracted simple projects to test someone's skills beyond interview questions.
That's irrelevant. Obviously asking people who aren't expected to program to program in an interview is silly, we're talking about asking people who would be hired for a programming role to program.
I've never met a great architect that didn't also understand how to code. It's hard for me to imagine being unable to structure code and design solutions at a micro level but had a good intuition for structuring code and designing solutions at the macro level.
The biggest recurring issue in any production-quality programming is the handling of edge cases. (Most frequent source of production issues is config management, but let's keep that out of the scope here.)
I would expect a really good design to consider the expected edge cases up-front, and take them into account. The goal cannot be a dogmatic "eliminate all edge cases" approach - because that can only become a self-defeating exercise in frustration. Instead the edge cases should become easier to detect and, as much as possible, not cascade. Debugging a subtle concurrency related timing issue or race condition is bad enough. Debugging the cascading failure and data loss due to a chain of them is a morale destroyer.
Understanding where these edge cases can crop up is important. Even more so, understanding why they appear, and how to address them, is the mark of a really good senior engineer.
For that reason I expect a senior to be able to still program. Senior engineers may not spend their time glazing at their editor, but I do expect any senior to spend plenty of their time with both code review and mentoring.
I really don't get the attitude that its insulting to ask for someone to show you some programming. You wouldn't hire a musician without seeing them play. I have interviewed plenty of expert non-beginning programmers who couldn't do shit. You can't find that out without asking them to code something. There are tons of people from large companies in my town who cannot do anything. I also worked at some of the large companies and ran into them.
How would you identify these people if you don't ask for programming problems.
Nobody's saying you can't test their ability to program. You can ask questions about programming without having them solve some problem from freshman data structures class. You can ask them how they do their current job, and ask for specifics about code they've written. You can ask them to review pieces of code to see how they would improve or change them. You can ask them for a code sample, and then have them walk you through it to be sure they understand it as well. There are many other less insulting options that still give you the chance to "hear the musician play." As an analogy, you probably wouldn't hire Wynton Marsalis and ask him to play "Happy Birthday" in an interview. You would probably ask for some samples of his music, or links to videos of him playing, etc.
Thanks for responding. So what is insulting about specifically asking for coding? It is not that different than asking someone to look at code at the interview and asking for comments. We do both things at my company. I am not persuaded by the famous musician example, think of someone trying out that you haven't seen play. Someone famous who is active and say not recently suffered an accident is in a different category.
We interviewed some experienced people who did terrible in the in-person interview. So we tried giving experienced people a pre-interview question, that maybe took a couple of hours of focused effort. The idea was the people who couldn't do it great during that instant could sit down in their preferred environment and code something up and take their time.Some people did better with this. I personally hate pre-interview questions, so I argued against it but we still tried it.
I find the code review of bad code too easy, not persuasive. Is it a bad idea for a service to hand out ids that are memory locations of runtime structures, and take them back? Obviously, but a surprising number of people don't see that, including experienced people.
My theory is that the state of technology is that people are able to use APIs, libraries, and Stack Overflow code to muddle through most business requirements. And if that's true, perhaps the standards of an engineer have shifted? If those people actually did work at those companies for those many years, surely they did something of business value?
Or maybe the questions being asked in technical interviews are no longer germane to the actual day to day experience of coding?
I'm not saying you should necessarily hire those people, but perhaps all of those articles that go "Why can't our programmers program???" should stop pearl-clutching and actually try to figure out why that is.
I've interviewed probably dozens of people who couldn't code, but never worked with one. I've had plenty of bad coworkers, but all of them could write code to a degree where they would pass basic coding interview.
I assume there is just a large population of people who can't do anything at all, and they just migrate from one company to another, coasting there w/o doing anything for a couple of years, because firing is hard. I keep remembering this story i heard from a co-worker. He worked at a giant laptop repair shop. There was a guy there who didn't know how to fix anything. He stayed for a year or so, and then finally was let go. They found dozens of spare parts in his drawers -- he would just order random parts from the warehouse to imitate work, and leave them in his desk.
This is part of the unspoken dues that corporations pay to the society, creating this hidden safety net for people who are just not good at what they do, or perhaps just can't do anything. It is both good and terrible. I am glad that this safety net exists, but it is really disparaging to these people. I wish society had a better way of helping them.
I prefer to not conflate "computer science" with "software development." The majority of the problems with tech interviews in the Valley stem from an overabundance of CS grads who mistakenly believe that their academic trivia quiz questions have much value for developing software people use.
Very few programming jobs actually require the more mathy end of CS. If you want an analogy with physical science and engineering, the the algorithms-and-data-stuctures interview is like giving a candidate for a satellite engineering job an interview laden with mid to upper level undergrad physics questions. It's just nonsense.
> Very few programming jobs actually require the more mathy end of CS
I disagree. I'm a lowly web dev who is not in Silicon Valley, but I do know the practical benefits of applying the right data structures and algorithms, even though I don't apply this knowledge every single day.
Yes, nested for loops and a hash table will "solve" almost any problem and you can push the release out the door, but how much will that sloppiness cost the employer/customer in hardware and the maintainer and users in time?
> how much will that sloppiness cost the employer/customer in hardware and the maintainer and users in time?
Next to nothing in almost every case.
In fact that hash table is probably overkill most of the time. Unless you're dealing with keys that have a costly comparison, a large number of key value pairs, or a large number of lookups (for some context-specific value of "large") the most naive and "inelegant" of solutions you could imagine, an unsorted array of key value pairs, is sufficient most of the time. So in fact what you call a "sloppy" solution is probably, and quite by accident, far more powerful an algorithm than the problem truly calls for.
Understanding complexity analysis is useful when the domain has performance demands or constraints that make it necessary. "Lowly" web dev is almost never one of those domains.
A directed graph to represent arbitrary user-defined element-event relationships between fields that triggered changes in values depending on one or more events on other fields. Since the events could repeatedly cascade, skipping transient states drastically improved the performance.
I also avoid using exponential complexity all the time.
What you describe is far more often a CS guy looking for a way to apply his CS education instead of asking whether he's identified the correct problem, and frequently that's because, having only an academic CS background, it doesn't occur to him there might be a more serious underlying problem that has a better solution.
I don't know if it was your intention, but you're almost sounding like a CS education is a handicap to solving problems- this is at odds with my experience (I was an embedded developer before I earned my degree)
How do you know? Because they failed your whiteboard test? That doesn't necessarily tell you anything about what they can do with a real workstation and realistic deadlines, unless you've empirically evaluated its effectiveness (including hiring some people who failed it).
This isn't very scientific, but I feel pretty confident about not hiring the people I described. Frankly, I have no interest in working with someone who can't come up with the syntax to define a function in the language of their choice. This is a real thing I have seen from people with significant experience on their resume.
There are candidates who are more on the line, and those I'm less confident about rejecting. But we can't just hire the hundreds of applicants per position we see, and I haven't come across a filtering strategy that isn't obviously worse than what we do now (which, to be clear, is the candidate's choice between whiteboarding and coding in an editor).
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.
I 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.
> Another is finding those developers roles that suit them better. Maybe that's some other aspect of the software pipeline like QA or testing ...
As a QA professional, I regret greatly that HN's rules restrain me from giving your post the appropriately pithy response it deserves.
QA is not your dumping ground for failed devs; we do not want them either. If they couldn't hack it as a SDE, they are certainly not going to be able to hack it as a SDET either.
Hi, I think perhaps you're reading into the non-exhaustive list of example alternatives to traditional developer roles more than intended.
I don't see anything in my comment to suggest that "QA is dumping ground for failed devs", nor was that my intention.
In fact, I wouldn't label anyone a "failed dev". Rather, the idea behind my post was to find a role that better fits that person's skill set and experience. My apologies if this was unclear.
Is this true, or is it true that there are devs with a lot of experience who can't program during an interview? An interview is an artificial environment.
But those are easily recognized: looking at their github, past jobs, portfolio and calling a few references? I would not invite seniors who do not have a clear past and if they do I do not require the kind of interview discussed here. Also most seniors are referrals anyway... Still do not see the point of these weird interviews I read about here, also not for juniors.
He probably would have been a good employee. He doesn't put up with bullshit. If you've been doing development (especially at larger companies) for years, you understand that coding is the least important part. That's the part you focus on after you deflect all the stupid bullshit from managers/product managers/ops. Senior members of the team should be able to influence others to get behind them and make good use of time. Coding is incidental.
Not to do the questions is impolite, but personally I'll politely decline for the position afterwards. A company where I would like to work should have interviews that are creative and fun, preferably challenging rather than boring.
That's fine, but are you looking for the answer, or the formal mathematical proof that 2 + 2 = 4?
How would a mathematician feel if you asked them to write the proof for it? They would probably feel insulted too.
In this day and age there is no need to prove that 2 + 2 = 4 (because it has already been proven), just like there is no need to implement a binary search tree (because the vast majority of tools already have). If your job will involve developing such tools, fine, but that's not the vast majority of dev jobs.
Does 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.
No, 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.
That 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.
I 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.
That'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?
I'm willing to spend about as much time doing coding exercises as the company has spent on me. This attitude developed after a couple companies asked me to do exercises, which I completed, and then they never responded to me. They didn't even acknowledge they had received my answer until I pestered them, at which time they confirmed they had received my solution, but had chosen to go with somebody else.
If you want me to spend a few hours performing a coding exercise, I'd be happy to, as long as I first get a few hours of interview time to ask you questions about your company and determine if it's a place I'd like to work. You're, of course, welcome to ask me questions about myself during that interview time as well.
I do hate pre-interview coding questions. But that company that is interviewing you is going to spend a lot of time. We have 2 people come to each interview, and we have about 6 hours including lunch between interviews with people here. So assume 1/2 hour prep before hand, 1/2 hour after writing it up, 6 slots x 2 people 2 x hours = 24 hours invested in an interview.
I have had a few people refuse to do interview questions in my life. Both times they were principal level devs who knew execs at the companies. Both times they failed after a few wasted years. That's not true of all of them, but I'm a principal dev, and I mostly work on architecture and planning, but I don't hire people to my role if they can't code.
As someone who administers coding exercises to candidates where I work, I can only say that I respond promptly when a candidate says they've completed the exercise if only to let them know I received it. I also encourage them to ask any questions they have and respond promptly to them if they do.
The exercise is valuable to us in our decision making process, which is why we request that candidates do it.
It's disappointing to hear that basic professionalism isn't as common as it should be - but don't blame the exercise for that. Perhaps instead, breathe a sigh of relief that you won't have to work with people who do not value your time.
Yes, blame the exercise for that, because the exercise is fundamentally and inescapably is an attempt to assert a level of power over candidates; instead of studying their Github or just talking to them hiring managers demand that they take on the time-and-effort risk of qualifying themselves to the hirer. Which is really stupid in a seller's market, BTW. But, even past that stupidity, it makes it tenable, in the mind of the evaluator, to blow off the candidate because they have, by accepting it, signaled that they will put up with at least a decent amount of shit coming down the pipe towards them without serious complaint.
It's fundamentally dehumanizing hoop-jumping, which creates predictable results, and we should be better than that.
I've been on both sides of the table. When I did these exercises I found them uncomfortable , but less so than the rest of the interview process.
I've never read into it the way that you and many others are. I consider it as a means of quantifying ability. You don't have time pressure, you don't have an interviewer standing over your shoulder whiteboarding with you.
I view those as positives - because while I can do those things fine in day to day work, I do horribly at them an interview.
That said it's clear that our experiences with this have been very different.
I can do either; I'm a very good talker and a very good programmer, and I'm pretty good on a white board too. But, fundamentally, this is a refusal on the part of the company to invest time in the process (while expecting the candidate to invest hours of their time). You are not operating as either business partners or equals; it's a power play. And that's not humane (and it's stupid besides in a seller's market).
I'm good at these tests. That doesn't mean that doing them is economically wise.
It is valuable to you sure, but as a candidate it takes a lot of time. At least with interviews the company is investing an equal amount of time, and I get to learn something about the company. The coding exercise doesn't tell me anything about your company. You are losing out on candidates who don't want to jump through hoops of a coding exercise.
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, 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.
At-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.
Legally it is pretty trivial. Respectfully though, just looking at it from that angle misses a lot.
- The person you've hired has made friends. You might like them personally. Firing them will have repercussions for your team's morale.
- Onboarding is a good bit more hassle than interviewing. Just like how it's cheaper to find bugs in dev rather than in prod, filtering during phone interviews is cheaper than in on-site interviews is cheaper than post hiring.
- Constantly hiring people, discovering they are incompetent and then firing them has implications for your own ability to lead and develop a team. So maybe now I look like the type of team lead who codes fine, but just isn't cut out to deal with the people side of things.
- In a small team environment, every team member has to be able to move the needle for the project individually. If I only have 3 engineers and 1 is bad, can I afford to pair half of my good engineers with the one who is struggling?
I'd much prefer to work at a company with a strong filter out front that then invests in the people it hires. Much better to say "Gee, Joe is mostly a wonderful employee but not great with skillX, let's see if we can pair with a Sr to work on that during the next project cycle" than have constant churn.
> I'd much prefer to work at a company with a strong filter out front that then invests in the people it hires.
But then you leave anyway, because leaving is how you get paid, and the company is out those resources.
Unless an employer literally always pay top-of-market, there is a severe disincentive for companies to invest in you. (A non-trivial part of why I went into consulting--my rates allow me to invest in myself.)
I think you think I have a problem with interviews; I don't. I have a problem with interviews that require the candidate to pay all the freight. Candidates have less time and fewer resources than an employer. Hitting them with some stupid code exercise that they can never reuse just to be considered for inclusion into your august freaking house is disrespectful and awful, I think.
Certainly its cheaper to find problems early. But its also possible to retrain; to create policies that enable progress regardless of the individual skills; to shift duties to match strengths etc.
Its not always possible to hire stellar teams (by definition half of all teams are below average). Still work can get done. Look at Pair Programming, look at Agile. Efforts to create a process where predictable work gets done regardless.
honestly? i think i have enough references to go past that. also, if you think i'm good enough, pay me a day of work and gimme some real world problems.
i don't remember the last time i had to write bubble sort or a binary tree by hand. but i do remember when i had to deal with salesforce api errors and how to deal with them. or even, how to deal with rabbitmq retries compared to thrift methods.
Thise two are not comparable: you are asking me, a senior with 25 years of coding and team building/lead experience to do a bunch of demeaning tasks for free that tell you nothing about my skills in a real life situation. While on the other hand you gave me a contract and I feel part of the company and the team which makes me want to perform whatever. Very different.
It's a balancing act, right? After being a hiring manager for 5 years I've learned that what a candidate says about themselves means jack-all. You could be a genuinely great hire or some guy who spent 25 years banging their head against the wall going from one failed project to another and your elevator pitch will be roughly the same.
Trust but verify. I'm sure some companies overdo it but if you're going to be touching code in any capacity I want to do the best I can to verify your abilities in a reasonable amount of time. A 1-hour coding exercise fits that criteria pretty well.
Hiring someone with that much (or even half that much) experience shouldn't include a coding exercise. If it does, the results should contribute ~5%-10% weight to the final decision. Seniors'/leads' skills diverge from engineering over time. You shouldn't even be coding as a lead. You direct the coding of juniors. When I interview those upper levels, I talk more about design and how they work with other departments (ops, product, UI) to get things done; how they overcome people and process problems.
I know several leads who can write great code, but they can't lead a project to completion for the life of them. And if you discover that during the interview, you have to determine whether it was genuinely their lack of competence or because of poor management. Personally, I'd rather spend that hour allotted to coding digging more deeply into their non-coding skills.
If the leaders of programmers can't code, then they can't evaluate them, and can't help them grow very well, and can't pass on the experience of developers over time.
It's crucial for first level leads to be able to code.
If writing some code is that much of a pain why am I hiring you in an engineering role at all? This seems like a terminology problem more than anything.
Then your senior rung is probably unpromotable and will become useless; you're just paying a premium on entry level skills. Architects don't code; they care about broader, higher level things. So it's natural that seniors move away from coding to those more abstract tasks over time. Your juniors should be generating most of the code. If I had a lead/senior who wrote most of a system's code, I would be alarmed. He's not distributing the work (and knowledge of the codebase) and doesn't seem to understand his role.
Where my opinion differs from yours manifests itself in industry in the practice of separating "technical leadership" from "people leadership." Your architects (and leads) should be people managers. They should have authority in how their subordinates' time is spent. They should be able to resolve disagreements, both technical and interpersonal, among engineers. A "technical leader" designing large systems/platforms to be built by a team that's led by a "people manager" is pointless. I mean, who wants to design something without the authority to execute that design? That's a toothless fluff position.
It would depend on the coding exercise; you cannot just have a 30min chat about a relevant practical example? I'm not sure I have met someone who can bullshit his/her way verbally out of a random practical coding issue which I can just describe in a few minutes and they can talk with me about. But that's not some 'pen down a tree balancing algo with the following time/space constraints'. Which you might not have been talking about anyway but which the OP was about.
I 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.
Cool, 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
I 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.
I 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.
Google 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.
This 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.
Same 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.
There'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).
wait, 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).
> 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.
Mmm. Be careful --- I've been programming in C for years, including frickin' K&R C, and I'd probably say something like A here (although instead of 'memory' I'd probably have said 'it points at whatever you set it to, what do you mean?').
The reasoning is: the code as written makes no sense; therefore it's incomplete. Obviously, then, it's not intended to be read literally, and is just an abbreviated portion of the real code. The first line just declares p as a pointer. The second line dereferences the pointer. The pointer assignment has been elided for brevity and is not relevant to this question.
That's an expectation impedance mismatch. I'm expecting you to want a high level description of how pointers work. You're expecting me to provide a blow-by-blow machine level breakdown of the instructions involved.
(Also, the blank line enforced by HN between paragraphs really doesn't help here.)
This reminds me of the Google phone screen article that went around recently where the recruiter was reading off a sheet of answers and failed the candidate because the candidate gave answers which were too technically nuanced to fit what the answer sheet said. And is also why these kinds of things are a terrible fit for recruiting experienced-to-senior-level people.
I am developing a rule of thumb for this: the more pointedly in-depth your technical question is, the more likely you produce false negatives through obfuscation of intent. The grandparent's "what does this mean" question suffers particularly from being in-depth without stating it. Every CS student who learns C gets the high level treatment of pointers. But in many cases, their class does not proceed on to examine what this looks like in assembly code, except in a separate course devoted to ASM or compilers where it might be mentioned obliquely that such a representation exists. That is a relevant skill, but you have to ask for it. An easier way to get there is to ask how a C compiler turns a pointer assignment into executable binary, working backwards from the output. There are now degrees of success, since the candidate gets to discuss how compilers work if they're really engaged. But a basic answer can still capture the essence.
> The reasoning is: the code as written makes no sense; therefore it's incomplete. Obviously, then, it's not intended to be read literally, and is just an abbreviated portion of the real code. The first line just declares p as a pointer. The second line dereferences the pointer. The pointer assignment has been elided for brevity and is not relevant to this question.
No. The pointer assignment has been elided to see if anyone clues in that the pointer is, in fact, uninitialized.
The correct answer is "the pointer is uninitialized. Writing to it will result in undefined behavior, possibly even a SEGV."
I concur. Not to mention, this code wouldn't pass the automatic static analysis we use for all commits to our repository, so it literally would never come up as is. We turn on "warnings are errors" and turn on most warnings. I literally wouldn't think this code could compile (or at least get committed) as written, so would assume there was stuff missing for the sake of brevity.
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?
>>and admit that many, many coding positions are API gluing and tinkering with libraries to fulfill business requirements, and not actually about engineering
Sounds like the True Scotsman Fallacy.
Why isn't tinkering with libraries and glueing code "actual engineering"?
Do you think engineers of other professions invent everything from scratch? Or are they given a set of tools, materials and requirements and figure out how to accomplish the task?
People can put anything they want on their resume. I got a resume once where a person said they were working at company X from 1995 to 1999. I knew it was false because they sat next to me at company Y in 1997 for three weeks before disappearing, they didn't even call to say they were quitting. Who knows what would have happened on the company X reference check if we had bothered to get that far.
By the way, half the startups I worked at went under or were acquihired by companies which did three more mergers, so who knows if my HR records exist. Most references I know of are chats with someone claiming to be an ex-manager or colleague.
The phone screen questions I ask, and the initial in-person technical questions I ask have a very low bar. Over half the people I talk to can answer them. I ask them because I have seen multiple people with seemingly perfect resumes who are unable to answer simple questions.
Speaking of references, I don't understand people who are fine giving three references, but are bothered by technical questions. For me it's the opposite. I'd rather not call three ex-bosses, make sure I have their current contact info, and ask for a favor that I can use them as a reference for a job I might not even get. Asking a technical question of me that I may or may not know is much less of a hassle.
Hehe, I once had a manager, who was also a programmer, asking me about the difference between new and malloc. He wasn't testing me, I was working at the company. His question was something like "Isn't it that if you use new you get virtual memory but with malloc you don't get virtual memory?"
...be aware that in Windows, there are two main ways to allocate memory: HeapAlloc(), which comes from your process heap and is equivalent to Posix malloc(), and VirtualAlloc(), which comes from the kernel and is the equivalent to allocating anonymous pages with mmap(). (Windows malloc() usually wraps HeapAlloc().)
So he's not necessarily completely wrong. If he's used to a system where the default C++ allocator uses VirtualAlloc() but malloc() still uses HeapAlloc(), then referring to memory allocated from VirtualAlloc() as 'virtual memory' makes sense, in a specialist weird-windows-terminology kind of way.
('Virtual memory', here, having nothing to do with virtual memory in the Linux sense.)
In Windows (as in most OS:es), any memory you allocate in user space is virtual, end of story.
Ok, not really end of story (I just said that because it's mostly true). You can allocate physical memory from user space but that is for very specific purposes and your general purpose CRT allocator (whereas new or malloc) will not be doing that.
Also (last I looked) the MSVC CRT "new" uses malloc.
Well, he had somehow managed to write an awful lot of C++. Most of the code base at that company was in old school C++ (huge monolithic classes). Since he was one of the founders I can only assume C++ was his main language.
The code snippet shows a bug, p is an uninitialized pointer. The behavior is undefined. Theoretically it could point to some valid memory, but saying that it points to dynamically allocated memory definitely implies a misunderstanding.
Which is why I would disagree with this example. I suspect the interviewee's answer was due to a misunderstanding rather than a lack of knowledge. For example, change the first line to:
char *p = ...;
Now, the implication is not that p is uninitialized, but that it's not important what its value is, which is likely what the interviewee thought. As for dynamically allocated memory, that's what pointers are used for the vast majority of the time, right?
I would react to stories like this with skepticism, whether told by the interviewee or interviewer, especially when accompanied with a pretentious attitude ("Get out"), because the most fallible part is likely to be human communication.
That's a very gracious interpretation I think. The snippet illustrates a kind of trivial bug (uninitialized variables) that should really jump out at anyone who is used to writing C code. (And I think it's clearly C code, and not pseudo-C code.)
In fact, it will generate a compiler warning (with -Wall).
The conversation (which OP said was condensed) clearly demonstrates that the interviewee does not understand that the pointer is uninitialized.
To suggest that the interviewee confused it with
char *p = ...;
*p = 'c';
makes no sense, because he said the memory was dynamically allocated 'by the compiler'.
Also it would still matter what ... is here.
For example if it was a constant initializer like "string", then the memory would be statically allocated and write-protected.
If on the other hand it was a call like malloc(1), then you would expect some error checking to see if malloc failed.
As I responded to another commenter, the purpose of "char * p" might simply be to indicate the type of p, not necessarily to indicate that it is uninitialized. If you wanted to indicate the type of p, what would you write instead?
Regarding pointers, though, you have a point that char * is commonly used for statically allocated strings. I concede that it's fair to criticize the interviewee for saying the memory was dynamically allocated (by the compiler??), though I don't know if that rises to the level of "Get out."
To be fair, this is an absolutely essential thing to be a stickler about in C. It's a dangerous language, and placement of semicolons and recognition of unititialized variables should be burned deep into the psyche of an experienced C developer.
This is why people advocate for alternatives like Rust where the compiler can be precise on your behalf. But as long as C is still in use, its practitioners need to be exceptionally pedantic with their code.
That is true, but my point is that in the context of an interview, the purpose of "char *p;" might simply be to indicate the type of p, but not necessarily to indicate that it is uninitialized. It's hard to know what the interviewee thought without asking them.
Though it might be a good thing to say "well, p is uninitialized," it might also come across as obnoxious if that wasn't what the interviewer intended. So it comes down to guessing which response the interviewer is looking for.
I do not know how to convince you as others have failed, but I really believe that trying to understand the correct understanding about the memory allocation was the essence of these questions.
The final answer that the memory was dynamically allocated by the compiler is as wrong as it can be.
If I saw this code then my first reaction was that this code probably will produce a segmentation fault in the best case scenario. Well, that was after I verified that this is not some pointer usage question, as I am not an experienced C developer.
> I would react to stories like this with skepticism, whether told by the interviewee or interviewer, especially when accompanied with a pretentious attitude ("Get out"),
Do you know how to read? Apparently not. I said explicitly that he conversations are a bit longer that that.
My comment was described as a short summary to illustrate a point. Instead of taking it at face value, you've read all kinds of nefarious emotions into it, and read magical interpretations into the technical portion, too.
p contains whatever happens to be on the stack at the position assigned to it by the compiler. Basically that means that p could point anywhere, so by assigning a char 'c' to a "random" address the best thing that could happen is a GPF/segfault. Most likely you'll spend weeks looking for a multitude of weird bugs that seemingly appear at different places out of nowhere, only happens sometimes and never in debug builds.
This answer explains the real issue. The problem is the question is asking the person to find the bug in the code, but the way it's asked is in a way that would make someone feel like a freshman in college.
I would say that an experienced C developer would blurt out that there is a bug in this code as an first reaction.
Bugs like these are one reason why we can not have the nice things on Earth, and an experienced C developer should notice them even when not looking for a bug.
Well, that is at least my impression, as I am not a one, it is just based on my experience with the language.
It could point anywhere, but the question here was where it does point to.
And that's a remarkably unsuited question for a coding interview as it's going to depend on which compiler you use, which flags you have set, and whether the declaration is inside the same function as the reference. The C FAQ (when there was such a thing) used to contain a whole section on things like this.
As a conversation starter it could perhaps be useful, if you can phrase it suitably. My own experience is that trick questions posed as if they had a singular answer will do strange things to nervous people. It's just doesn't tell you much.
If I had this question dropped at me, my hunch would be that the interviewer had a slightly inflated idea of their own knowledge of the language and would likely not take kindly to being taken down. That might well colour my take on the answer. It's not always rewarding to argue minutiae.
I'm not a developer and I think the question makes sense. I would have given a similar response to what amag wrote, although I would have skipped this bit: "Most likely you'll spend weeks looking for a multitude of weird bugs that seemingly appear at different places out of nowhere, only happens sometimes and never in debug builds."
It's pretty clearly a conversation starter and there are lots of valid ways to answer the question.
> If I had this question dropped at me, my hunch would be that the interviewer had a slightly inflated idea of their own knowledge of the language and would likely not take kindly to being taken down. That might well colour my take on the answer.
If the interviewer responds poorly to this kind of answer then I don't want to work there anyway. Also, this kind of answer is not "taking down" anyone.
> but the question here was where it does point to.
No, the question was "what happens here" and the obvious answer is "you write 'a' to an undefined location, likely segfaulting". Since the candidate failed to spot this a hint was given hoping that the candidate would realize that the pointer didn't point at a valid location.
I don't understand your comment. He says he thinks the coding portion is nonsense and your reply is you have discussions about C code snippets. The two things are very different. What you are describing isn't a coding exercise.
> I probably would have gotten the question wrong too and just saying "Get out" is kind of harsh.
If you can't do that, you don't understand pointers. If you don't understand pointers, you're going to write really buggy code.
I've never told someone to leave an interview early. That's a bit unprofessional in my view. But I certainly wouldn't hire a C programmer who doesn't understand pointers.
p doesn't point to anything[0]. You have declared a pointer to char but not given it any memory to point to. It is uninitialised.
*p = 'c';
So what are you dereferencing here? You can't dereference something you haven't initialised.
[0] well it might point to something, it is up to the compiler as it is UB.
Edit: btw if you could not answer this very simple problem please do not advertise yourself as a C programmer as you are not yet. Learn C and then advertise yourself as a C programmer.
Yeah, one more thing. C and C++ type languages where you have to manage memory allocation are a different kind of intellectual challenge than languages like java or python. It takes a certain amount of try and failure and intellectual carefulness to get the ability to write trustworthy code. Just keep going at it. And be careful not to call yourself an expert c programmer, even after you get basic fluency. That's usually a sign that someone is not a great programmer in my experience :-)
Get out would be rude. If you interview a lot of people who say they are programmers, you get people who can't do anything sometimes. It is frustrating perhaps but that's no reasonable way to treat people.
Back to the question. In C or C++ the pointer is pointing to a memory location. If you don't set it to something (ie no malloc, or assignment, then it is uninitialized and you can't use what it points to. It is essentially a random number. Looking at a random memory location "(* p)" could likely crash your program, but it won't be anything useful that you should use. So when you say "* p" = 'c'; you say overwrite the memory location (which is randomly chosen) with the ascii code for the character 'c'.
Side note - the surprising markup language here doesn't let you use asterisk p directly, you have to put a space in I just discovered.
I 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
String 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)
Oh 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
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:
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.
In C, variables defined in the file scope with static keyword, i.e. defined outside functions will be visible only within that file. Any attempt to access them from other files will result in unresolved symbol at link time.
I made exact same error when tried to write C code after years of coding in Java. I knew C, but my knowledge was blurry. Despite that, I finished project in time with excellent recommendations. I am senior after all.
You are right - the 'static' itself is a mistake, but not a terrible one.
But when the line:
Foo foo = new Foo();
is followed up with:
assertEquals(
if one types in anything other than -1, 0, Integer.MAX_VALUE, Integer.MIN_VALUE etc, big blaring warning alarms should go off in a senior developer's head. Even after it is typed in, when you read through the code it should have stood out to you.
How 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.
This was a hypothetical test scenario, it just proves he knows those stuff and we do not need to teach those to him. Perhaps he is weak in logically deciding what exactly needs to be tested but writing good tests doesn't come easy either. Many can fail in that given time constraint and other management pressure.
> Perhaps he is weak in logically deciding what exactly
> needs to be tested but writing good tests doesn't come
> easy either.
True, but we were looking for "senior" engineers. In that role, the candidate is expected to have a taste for these things, do code reviews, and even help junior engineers acquire that taste.
> Many can fail in that given time constraint and other
> management pressure.
I forgot to mention it, but this was a take-home assignment. So there really was no time constraint or interview pressure.
I 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.
That 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."
Agreed. 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.
The 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.
You 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.
You can. Global variables work like any other type of variable. If you don't like that style, that's a matter of opinion. Some people don't like Hemingway's terseness, and others don't like Faulkner's run-on stream of consciousness. However, they wrote things that "worked" and were "useful" to others (their publishers, their culture, the Nobel committee).
At the end of the day, your software has to save or earn money. The salesmen and business heads don't care how pretty your code is, or if the people who developed it knew the language spec inside and out.
Again, disqualifying someone who can "do" something but in a way you don't find palatable is the core reason why hiring engineers is such a clusterfuck.
The problem is that people who write Javascript for a living, who do not use 'var' are usually the people that do not even know what the difference between global and local variables are, and why global variables are dangerous.
I have seen code that used global variables with the same name in totally unrelated different functions (the author probably thought these are local variables), and of course as one function called the other there was a bug because of it.
Also, even if it were subjective whether to use local variables is good or not (this is not subjective I think, but there are other things that are really subjective), a team cannot hire someone who writes code totally differently than them. Even if a guy is brilliant but cannot fit into a team or into a codebase that needs to be developed together, then it is not wise to hire him.
Of course I have seen companies who hire based on extremely tricky questions on certain programming languages, or when they only ask algorithmization, as if on a programming contest. These extremes are not very good in my opinion. Where I work we ask a little bit of everything, and we also work on real-world code with the candiadate together for a few days, before deciding.
> At the end of the day, your software has to save or earn money. The salesmen and business heads don't care how pretty your code is
You're right, they don't care, but maybe they should. Pretty is one thing but maintainability is another.
Global variables is one (out of many) thing(s) that decreases the maintainability of your code. It will make it more difficult to change something because other unrelated things will break. It will mess with your unit tests. It will mess with your head.
All in all, bad coding styles (like the use of global variables), while quick in the beginning, will eventually grind your feature spouting code-monkey machine to a halt. Then the salesmen and business heads will care, and by then it will be too late.
So, it's not just about taste. The number of whitespaces used for indentation is about taste. Good coding styles are not.
I don't disagree. But scope is something that's easily taught. And the term "maintainability" is subjective. Your team decides what's maintainable. So showing someone the door because they aren't aware of your version of "maintainable" is silly.
You can play this language-game all day with your candidates (and yourself), but it's largely a waste of time. I'd take someone who can "do" things, is willing to make mistakes, and willing to learn over someone who thinks "good coding styles" are set in stone and stubbornly adheres to them.
True, but this is not expected for an experienced mid-level/senior role. I would expect a senior developer to not only know the language but know the potential pitfalls.
> And the term "maintainability" is subjective.
Nothing subjective about the downsides of polluting the global scope; it shouldn't take a genius to figure out how this could lead to hard-to-debug bugs. Interviewers are interested in differentiating between candidates who have this knowledge and those who do not, so the answers to these seemingly "low-level" questions are surprisingly enlightening.
Yes, scope is very easy to learn, which is why it's so damning when you encounter someone who claims multiple years of experience with Javascript, and doesn't understand the most-basic fundamentals of scoping.
Its a very good analogy a lot of these "coding tests" are the equivalent of asking for a truck driver role "explain the difference between constant wear and constant pressure" in designing a clutch.
I'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.
How about interns? The people who would do a job like that well have zero interest in it, and besides you're probably not paying enough to offer a compelling reason to jump ship. After all, why should you? It's a menial task that will bore most intelligent people.
I'm not quite sure which part you're reply to, but my best guess is the bit about trying to hire a contractor to do hardware upgrades. In that case, we were basically looking for interns; we were bringing people in who had relatively little experience. The guy we ended up hiring had no professional experience, and was looking to quit his job as a high school math teacher. He's worked out fantastically.
If you're talking about the sysadmin position, we've mostly given up on bringing in anyone who knows the difference between their ass and an RST packet, and we're going to try hiring interns to train.
If you're talking about the senior software engineering position, maybe you're suggesting that experienced software engineers are unwilling to go through a one-hour technical phone screen involving writing code? Maybe that's true; I don't know much about the earlier stages of that hiring effort.
After reading your comments here on sysadmin hiring and hearing similar stories elsewhere, I'm wondering if these problems are possibly compounded by other issues, too. One of them might be the rise of the "full stack" engineer. In other words, a lot of the pure sysadmin guys might be retiring now or moving into upper management, and there isn't enough young blood getting into sysadmin (cough DevOps cough) anymore. Maybe millennial-age young programmers are finding NodeJS, React, or anything new and shiny more appealing as a career path?
Not at all. The phone screen I'm talking about is using https://coderpad.io/ which is an online shared programming environment. No white board involved, just a text editor and compiler, and whatever references, online information, or anything else you want to use.
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.
It is disheartening seeing how many "Senior" Software Engineers with over a decade of experience fail to implement `bool isNumber(const char*)` that works for positive/negative integers and decimals.
And these people somehow get past the filtering that our recruiters (large social network headquartered in the Bay Area) are supposed to perform.
Honestly exactly for this reason, I've been feeling a lot less passionate about conducting interviews than I did when I started my current job.
Most senior software engineers with over a decade of experience never implement bool isNumber(const char *) for positive/negative integers and decimals. It is rare to need this and, if you do, either use a library or find it on Stack Overflow, in a book, or some other source. Implementing it is unnecessarily reinventing the wheel. One thing senior software engineers learn or should learn is not to reinvent the wheel.
This is one of the problems with these types of questions, including the CS 101 type questions that often make up purported coding tests during hiring. In most cases, they do not test what practicing software engineers actually do.
The point of the question is to see if a candidate can glue a loop,an if statement and a bit of arithmetic together, on the spot. Failing to come up with an answer to such a question is generally symptomatic of lack of problem solving skills.
I disagree. If you can't code IsNumber at least for plain integers you shouldn't be touching code. Then work up to negative/decimal
Yes, for a lot of problems you should go for stack overflow or a book. But this is a simple problem. SO won't have the solutions to all of your problems
As another commenter noted, for negative/decimal it is not so simple. That is why a highly experienced software engineer would look for an existing, fully debugged implementation rather than spend substantial time making sure all the corner cases are handled.
In the context of an interview, it is highly likely a highly experienced software engineer will miss some of the corner cases. The exception would mostly be someone who has specifically studied and drilled on implementing isNumber(char * string) or specifically works in implementing these kind of functions which is rare. As I said there are libraries with these today.
You are missing the point. The goal is to show you can do simple coding and design. The particular example is not necessarily something you'd do explicitly. It's like writing fizzbuzz.
Whenever I see absurd stuff like that, I wonder if the companies are really worth working for. What's your opinion? Do they feel worthwhile despite the silliness of the hiring process?
Do they typically require that during the interview process or before? I recently had a company ask for me to opelte a challenge that would have taken about 10-15 hours, before so much as a phone screen.
You go after these companies because they grant prestige and you want to accomplish a certain level in your career by being employed by nationally or globally top company. If you aren't competitive in the least and just don't see the appeal, then it shouldn't be forced because you will be miserable and not succeed.
> The fact that I have worked for several industry leading companies, and had 20+ years of development experience was irrelevant without that score.
This pretty much sums up what I hate about technical interviews that require a white board. You could have a solid resume, good references that can speak to your technical skill, and a discussion about your previous projects could demonstrate technical aptitude.
However, because you can't solve a problem that took people weeks to figure out in an artificial, stressful, and contrived situation, companies won't look at you.
> [...] required me to complete several HackerRank challenges because I did not have a HackerRank score.
I have no problem with this since most of the time it is just 2-3 coding problems. What irritates me is when HR people and even some developers ask me about my contributions to projects hosted on websites like BitBucket or GitHub. I usually tell them that all my public contributions are on personal projects with no relevancy [1] because the interesting contributions are protected by NDAs [2] and I cannot disclose any significant details about any of the projects that I have developed for obvious reasons. Some people consider your GitHub account as your "Resume 2.0".
No more ridiculous than women listing height requirements in their dating profiles, asking about height, and filtering out people with too low a number -- even though they don't actually care, it's not actually a requirement they have[1], it's just one they list and filter against at the online stage, despite not actually caring.
By don't actually care, I mean that when they meet those men in different settings they don't care about height, when very short men decline to mention their height or match with women despite not meeting stated "requirements" it isn't an issue, and indeed some men lie outright about their heigth but women get over it and enter happy relationsihps with them once they actually meet.
In many contexts stated requirements or the hoops applicants have to jump through don't match actual requirements. Fundraising would be another one. VC's don't invest in companies that actually meet whatever requirements the VC's list on their web sites regarding what kind of opportunities they're looking for.
In short, people are lousy at stating their requirements and sabotage processes. For my woman example, the same woman will complain that no good men are available, while having an irrelevant filter in their dating profile: then, when they meet someone nice in real life, they're happy. It does not occur to them that the person they have met does not meet their stated requirements.
That post is titled "Should a girl go on a date, even if the guy doesn't meet the requirements for dating?"
When that person actually meets someone in bible study (say), I doubt very much that the person will meet all of her requirements.
Rather than "Should a girl go on a date, even if the guy doesn't meet the requirements for dating" we might be reading a Quora post about "Should HR still interview a candidate, even if the guy doesn't meet the HackerRank requirements?"
Those requirements are irrelevant and just weed out qualified people. (And the answer is, yes, they still should.)
[1] Example: Tom Cruise is officially 1.7m (which could be inflated, celebrities often pad by a little bit) which is 5'6.9". That is lower than many women's stated requirements, but those requirements are not actual requirements and I doubt he had any trouble dating women he literally didn't meet the requirements of at the time. The requirements aren't real, they're fake and invented, made-up. Not true.
-
EDIT: I absolutely stand by this comment, even though it is being edited to -1 and will likely end at -4. I completely stand behind every word. Lest you think I'm speaking with a bitter tone, I'm not. I'm average height or slightly above, no issues for me or disqualification due to it. I was using it as an example of a "number" that is a requirement, only it's not.
I don't see what relation a person's dating requirements - completely arbitrary requirements for achieving their personal happiness without any requirement for regard to social norms, standards, or economic well-being - has any bearing one what practices are acceptable for hiring people. As such, one is subject to regulation and the other is not. And for the same reason, your analogy is entirely inappropriate for reasoning about how hiring parties should behave.
The hiring manager needs you to do that for typical corporate CYA reasons. If you turn out to be a great hire, it's all good. But if not, then the hiring manager can say, "he was top 10% (or 5%, or 1%) at HackerRank, blame it on them", as opposed to, "I incorrectly evaluated his competency/fit/experience/motivation/etc." It's for the manager to have someone to point a finger at, if necessary. Simple as that. Some HR depts may have instituted the policy, same thing just larger scope.
Then flat out refuse. I just landed an amazing gig by writing a relevant blog post with code included. Else they could rely on some of your github code.
I like computers. I did when I was 17 & I still do now. But, as a young developer now, I'm quiet scared of the industry as a whole. The direction it's heading towards. I don't know the right answers but there is quiet a lot of things on part of the hiring process & what's considered as value in the software industry, that feels wrong.
Let me get specific.
1. Competitive programming is great. But why hold it in direct proportion to ability to build products?
2. What happens 10 years from now. I know the 'keep up with the latest' drill. I'll definitely be doing it & I quiet like it. But why is the trend unreasonably favouring fresh graduates and quiet unjust to the seniors. Shouldn't it be the other way around? I don't despise the freshers. I'm quiet a fresher myself, but it still concerns me.
3. Why are things changing so fast in the first place? Don't get me wrong. I'm looking at the JS ecosystem. I like diversification. It's good. In our industry diversification helps better than anything else. They eventually converge back. JS is yet to reach that state, but still it concerns me the way the Javascript ecosystem is diversifying.
We've got an awful lot of things to set right in the industry. Hiring process is definitely something that needs attention.
I personally find short-term paid contracting as a part of the hiring process, much much healthy than whiteboard coding & website ranks.
I share your thoughts and I think it's many reasons things are the way they are. Main reason being money.
Young programmers are cheaper and easier to boss around.
Quantifying programmer skill is an easy sell, albeit flawed, "look at the score, we should hire or ignore!". Because hiring programmers you don't know is very difficult. This score can also serve as a way of lowering pay.
I think we all want to work with new and cool stuff, so this is pushed as a selling point to get you working for pizza and beer. The pay is not good but you can work with <insert latest shit> here.
How your company looks is important if you want VC money. Better keep your look young and vibrant. This also serves to attract other young cheap workers.
> Competitive programming is great. But why hold it in direct proportion to ability to build products?
Because it's quick to test how good someone is at competitive programming, it's easy to grade everyone consistenty, and it (somewhat) correlates with actual programming ability.
Compare it to other interview techniques. A programming project/trial period is time consuming. And it's hard to grade everyone consistently when going off of their resume/github.
> Because it's quick to test how good someone is at competitive programming, it's easy to grade everyone consistently, and it (somewhat) correlates with actual programming ability.
I'd agree. Competitive programming does correlate with actual coding ability. The category of people who find it satisfying, earning ranks from a website - that's what bothers me.
Young talents who've got all the time needed to earn score, they do it. What about the rest of our veterans? How fair is it to keep a website rank as a baseline for job in the real world.
I don't know many who find competitive programming fascinating, after 5 years solving real problems for real people. I may be wrong here. Please disapprove/acknowledge me in the comments.
It's a deep problem. Not a lot of organizations can afford the short-term contracting method. I agree. But I consider the cumulative star counts of their github projects, way better a metric than a rank from a website.
There's no one right solution to this. But competitive programming score is IMO a very wrong direction to go. We are very much capable of coming up with better solutions. That's what we are good at :)
Does your correlation go both ways, though? If you think you have evidence that competitive programming is correlated with higher ability, do you have evidence that higher ability is correlated with competitive programming?
Or do you not think about that part, or conclude that anyone qualified you pass on is a fair cost to pay?
It should also be pointed on that #1 is not an exclusive position on HackerRank's leaderboard. It it shared by everyone who got full points on each Java practice problem [1]. I see 16 full pages + 1 partial page = 166 people who are tied for "#1 in Java".
Furthermore, "#1 in Java" is not "Hacker Rank #1". Each leaderboard is broken up by language, topic, or contest. OP is trolling really hard here. There is no overall ranking across boards, so this claim doesn't make much sense.
(All this aside, I do really like the HackerRank platform and have been solving quite a few problems there lately.)
And HackerRank Java challenges are more like training for the beginners than a "Master of Java" verification. I know this because I also was #1 in Java and it was very easy compared to the algo challenges they have (you lose #1 position when they add new questions).
tl, dr: The guy just blindly copy/pasted the answers from the discussion section of each problem to the question itself and passed all tests, without even really reading the question or answer.
Is having a specific HackerRank meaningful to the outside world? I am unfamiliar with HackerRank, but solve algorithm questions on a site called LeetCode for fun. When I get truly stuck, I consult the discussion area and implement the suggested solutions. But I don't think it would be meaningful for me to go through all 450+(?) of their questions and paste in the answers.
What's the motivation to achieve Hacker Rank of 1, when presumably everyone knows you can just copy/paste the answers?
edit: as pointed out below, I jumped the gun on the motivation question. I guess I assumed the second part of the article expanded on the motivations, which were that the author heard people hired based off of HR. Hopefully those companies realize how easy this is to manipulate.
That very article (no offense, but did you skip the last part?) states the reason for this article, for this behavior: A report stating that someone was hired for a somewhat prestigious position, based on their HackerRank.
The article asks if this can be true and tries to prove that this would be a rather foolish metric.
I believe that article stated Morgan Stanley / Banks were hiring based on using Hacker Rank to screen candidates with their own unique tests, not rankings. It didn't involve the default questions William went through, though similar.
The default questions (on which OP has gained #1) are just for practice. The actual contests held from time to time on which companies actually hire are difficult, and don't have solutions easily available. The default challenges are like examples, the real number #1s on Hackerrank contests are actual competitive programmers(similar to #1s on other sites like codeforces, topcoder).
Id hope most people realize how easy it'd be to manipulate.
Reminds me of the LinkedIn recommendation system is completely pointless as you can easily create dummy accounts for referrals. I doubt most people spend much effort investigating the peers and you could come across looking better.
There are tons of opportunities out there to be manipulative if you really wanted to be. Same with github repo example code and lots more.
Just depends if you personally want to risk it and put in effort.
Anyway, that's why Codewars censors the answers if you haven't completed the challenge and doesn't allow you to earn credit for the challenge if you choose to view the answer.
Of course you can choose to make a dummy account and view the answers, but you'd really have to be desperate to do such a thing. And this is all pointless anyway.
Agreed, you might be able to cheat your way to a high(er) karma. But do you know about any company hiring based on the HN comment karma/score for some reason?
> Motivations For Getting The Ranking.
Recently I saw a Bloomberg story linked on Hacker News where it said that Wall Street is frantically looking for programmers.
Companies like HackerRank turn software engineering into a commodity (great for code copy paste). The HackerRank contests submitted by companies were quite buggy, verbose (but with confusing English), and like the author, took a lot of fighting with the website to get the code to pass the tests.
This is in no way a measure of success as a software engineer, where a significant amount of time is spent in defining problems and articulating maintainable solutions for deploying features. This means using design patterns, proper documentation, in lieu of regex type expressions that are indecipherable a week later.
Today in "What happens when nailing the tech interview is impossible for companies but the incitament for doing so is great and well, there's a lot of software companies around".
Great read, worked for about 10 years in dev never heard about hackerrank but it's part of a pattern sure.
I feel like a system like IBM Watson is going to end up writing the code in the near future. The real action, therefore, is in explaining the business logic and requirements in a structured way so that the AI can write the code.
Disclaimer : Developer at HackerRank, however I do not know details about how Furlong was hired, so I can not go into that. Also this is not an official response, but a personal one.
So I think the source of misunderstanding is that we have multiple rankings on HackerRank. The leaderboard Mr. William Ross became #1 was in the practice leaderboard for the Java Domain[1], which is based on practice problems, and which is intended to get people upto speed with Java.
We make the distinction of Contest based leaderboard which are based on your performance in contests, and practice leaderboard, which is the one Mr. Ross got on to.
This is based on contests and the forums during contests are monitored for answers and solutions, and this is what would be considered really hard to get on to, and I know the #1 there, uwi is amazing.
Our regular domains available at our domains page[3] are meant as a learning tool, where you can rise up as you solve problems, and yes the solutions are all available in many places. However since this is a practice area we do not do many of the things done in contests like restrict forums, look if solution is available online, run plagiarism(code similarity) matches etc, and generally we encourage people helping out in forums, although yes we should keep a watch on direct solutions appearing in forums. This is not intended to be a competition.
While I do not know how Furlong was hired, I can tell you the common ways that people do get hired.
1. Companies conduct contest or sponsor HackerRank conducted contests.
2. Candidates apply via HackerRank jobs[4] which again has a HackerRank test that follows.
3. Candidates practice on HackerRank after which they may be approached by companies seeing their positions, but generally this involves a HackerRank test as the first round.
4. Common test for a LinkedIn placements (currently in India alone)
5. The regular HackerRank test companies send across.
Well in practice areas it would if you take it without cheating it will. We do not want to make practice areas competitive in nature. If you want to really get to know your ability or challenge yourselves then I suggest the contests[1]
I have a list of nine different websites (see them below) that I visit every-single-day to keep my programming skills in shape. I have no preference whatsoever since they are all pretty much the same, some of them have better coding problems than others but nothing special.
However, during the last two months I have been using LeetCode and HackerRank more than the others because they are used I have been interviewing with a lot of medium and big sized companies, the big ones usually ask medium/hard questions from LeetCode while the medium sized companies prefer to filter people via HackerRank.
I discovered leetcode recently and left a drive-by forum comment pointing out an algorithm nobody had considered for one of the problems in the recent-discussion list.
Then I tried out a couple of the beginning problems, selected Python as the language, and discovered that since they apparently port the test cases over without modification from other languages, my Python solutions had to check for integer overflow and return special values in those cases.
I decided then that it's probably not going to be a very reliable measurement for the stuff I do or care about.
I thought Code Fights was the current hotness, people have been hyping how they feature real AIs (testbots) created by actual companies or note. Isn't its format at least distinct from the other sites, which are mostly the same Top Coder format of "here is an algorithmic problem, solve it and we'll grade it?"
CodeFights is more like a play environment like CodingGame, I am yet to find a company that requires me to write the algorithm for a robot in order to demonstrate my programming skills. This is why I prefer LeetCode and HackerRank, not because they are better but because they are what companies are using to interview people. CodingGame has a Machine Learning exercise so it is not like the other websites are not innovating, it is just personal preferences.
The author is breaking the rules of HackerRank and should (hopefully will) be banned.
Anytime we share challenge problem solutions in the open there is an ethical issue about it. HackerRank specifically even does plagiarism detection.
I some of my own solutions to challenge questions in a public repo on GitHub [1] for educational purposes. I recently slapped a big disclaimer on that for people like this.
> Disclaimer: These solutions were developed by me individually unless otherwise stated and are shared for education and curiosity. Please do not use them as your own. If you're working on the same problem, please do not view my answer until you've solved it on your own. If you're working on a related problem, it's generally okay to cite a solution to another problem as a reference.
There is already an ethical issue, anyway you look at it. Even if you do not copy paste the answers.
Its not like participants on forums like hackerrank invented those algorithms. Every single data structure and algorithm question asked on sites like hackerrank has solutions invented by some Computer Scientists, participants are just using them.
The only question we are asking from the where do those participants replicate the answers? Do they replicate it from a book? Webpage? Memory? You could replicate the answer from anywhere, as long you didn't invent the data structure or the algorithm you are essentially plagiarizing.
>>HackerRank is a technical recruiting platform.
If you use irrelevant tests to measure capability of the candidates, why cry when they match up to it in their own way?
Writing your own algorithm or data structure implementation from a description of the algorithm is considered fair game in every programming challenge competition I've ever seen. This includes the national level ones like ACM.
> Anytime we share challenge problem solutions in the open there is an ethical issue about it
I disagree, in fact, I hate it when I cannot find a solution to certain problem because I don't care about the Internet points but I do care about the learning. Usually when I am solving those coding problems I do it by myself but when I get stuck I want to see the solution right away, analyze it, then open WikiPedia, some books, and understand why the solution is like that, then close the window and try to resolve the exercise by myself once again in 2-3 days. If I cannot find the solution then I get stuck on that step and cannot learn at all (unless I invest a 3x the time to understand the jargon from WikiPedia/books).
CodeWars, for example, does something similar. They let you see the solutions from other participants and people can vote for the best/clever/optimized ones. However, these solutions are still hidden and you can only see them after you solve the exercise by yourself which is still a problem.
I agree with the other comment that there is no ethical issues here, that is just an overreaction.
A developer who has so much time in hand that he spends his time playing challenges all day is likely to not be "good" or "great" anyways. I've always found these challenge sites to be stupid and would never wanna work for a company who demands a good HackerRank or a good karma score on StackOverflow.
It's a game of cat-and-mouse. A user can modify some variable names and get around naive algorithms.
If you eliminate too many 'pre-made' answers, then you get into a situation (especially for shorter problems) where you start flagging people who legitimately solved the problem, and just happened to write an answer similar to someone else's.
Homework: Write an adversarial ML model in which one model modifies source code to produce equivalent output, and the second model tries to determine whether the output of the first model is 'original' or not...
It's hard for even a human. In some cases, the copied material can be equivalent to original material, thus, literally impossible to distinguish (disclosure: I've worked on a system to detect this sort of thing in academic settings).
People should start using real world coding as a measurement of skill. My personal website shows real-time graphs of my programming in each language I've used.
It's offtopic but the urge to ask is too high. I have an idea of how wakatime works, so on Tuesday you've been coding for almost 13 hours? No planning, not committing, not reading docs, just typing into your editor for 13 hours?
Yep, I had a backlog of things to work on and no distractions that day. However, it's also counting the previous day's coding that spilled over across midnight.
Hackerrank is a great site for solving problems and learning.
If you want to do fraud you can do anywhere. But fraud won't go very far. You would be caught.
One example:
I quit my last job because one co worker (c++) try to set a flag in destructor and checking that flag in member function to fix a segfault. Even though the person was having an ivy league degree and 10+ year of experience I don't want to work with them. Couple of other guys also left the company.
So it won't last long and a fraud would be caught. A fraud might end up working in sucker jobs and always wonder why they ask algorithmic question in interviews ;)
There's no guarantee you won't have a bad colleague in the next place, too. That said, if a bad colleague makes your work exceptionally difficult, that's a tough position to be in.
On a related note, I've observed that some of the solutions to tough problems just perform matching on the input and print out hard-coded expected output. How utterly pointless.
I don't see the point in hackerrank-bashing though. The site's UI is nice and it has got a good selection of problems for brushing up coding interview skills. Also, I think that most companies that "hire based on hackerrank ratings" use it to feed their pipeline and do additional interviews on their own.
imo hacker rank is bad since it commoditizes developers. Ive in the past refused to take a hacker rank quiz. I always offer the alternative to take a live phone screen. Some agree some don't. But in the end I refuse to have my reputation in the hands of some random company.
HackerRank seems ideal for apprenticeships, internships, and other low-risk onboarding programs that provide candidates with opportunities to perform in real-world situations.
Those who "game" the system are easily filtered out.
You earned it as far as I'm concerned. It doesn't sound like you're breaking any rules so much as taking advantage of a flaw in the system. That's hacking in it's most sublime form. If it were a blackhat operation, you'd be exposing yourself to punitive damage. You're not here (unless the mods take retribution on you)
