How I Became HackerRank 1 in Two Hours
williampross.com
williampross.com
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.
Here is another case of someoen with an impossible laundry list of requirements: https://www.reddit.com/r/dating/comments/58uoo7/should_a_gir...
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.
You try to evaluate people based on what they tell you now, but in reality there's no way to know what they'll be like 6 months from now...
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.
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.
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
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.
* there is no length argument
* localization, should it contain dots or commas?
* the minus sign or a plus sign should be only at start
* there should be only a single decimal separator
* just a dot is not a number
* just a minus or plus sign is not a number
* empty string is not a number
* there should be only a single minus or plus sign
* there should be a minus OR a plus sign
* let's assume something like .0 or 0. is allowed
* let's assume 4E04 is not allowed (although it is a positive integer)
And yes, you're correct at all of those assumptions. :)
In what ways do you find them crappy?
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.
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.
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.
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.
Level the playing field. It's a seller's market (tech workers are still very much in demand).
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.
That's not strange at all. It's much easier to "fire" a consultant than an employee.
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.
- 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.
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.
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.
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.
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 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.
* And o
I'm good at these tests. That doesn't mean that doing them is economically wise.
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.
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.
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.
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.
It's crucial for first level leads to be able to code.
The role name may vary between company, but I believe we can agree that there are different roles to fill.
That's exactly the kind of "senior" person we _don't_ want.
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've interviewed multiple people with such experience who knew next to nothing about C.
char *p;
*p = 'c';
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.
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?
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?
char *p = ...;
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.
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.
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.
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.
It's C code. Your interpretation is not the one used by the compiler.
The point was to catch trivial bugs in code. In this case, the interview didn't.
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';
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.
It's actually a pretty neat little snippet.
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."
Then you would just write it as a function like this:
void foo(char *p) {
*p = 'a';
}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.
This is called "projection".
Yay, the joys of uninitialized variables!
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.
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.
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.
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.
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.
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.)
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.
You declare some pointer and give it whatever value 'c' is?
I probably would have gotten the question wrong too and just saying "Get out" is kind of harsh.
char *p; *p = 'c';[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.
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.
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.
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.)
No, it's not omitted for the sake of brevity. The point is that if you can't find bugs in trivial code, you shouldn't call yourself a C programmer.
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."
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.
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.
https://abc.xyz/investor/news/earnings/2016/Q3_alphabet_earn...
Ditto Amazon, which added 76,000 people in 2015.
http://www.geekwire.com/2016/amazon-hired-76/
(Damn, that's a lot of people. No wonder their recruiters are everywhere.)
Just don't ask me to code a FizzBuzz, that will just p. me off
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.
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.
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.
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.
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?
Separately, how do you properly verify some library, tool, or vendor if you can't actually push it during evaluation?
How do you mentor more junior engineers if you don't know how to create working code?
And the reason everyone has to spend 30 minutes writing working code is because there is a depressing number of seemingly inflated resumes out there.
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.
How would you identify these people if you don't ask for programming problems.
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.
(By the way I'm a huge fan of your app and have used it every week for years.)
https://news.ycombinator.com/item?id=12826364
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.
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.
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?
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.
I also avoid using exponential complexity all the time.
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).
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.
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.
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.
I have seen developers who are good at answering interview questions because they trained for that specifically.
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.
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?
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.
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.
Then repeat, with a function to print numbers from 1 to n (given as argument).
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
Not the OP, but I can narrate an incident here.
When we were hiring for my team, we had candidates do a small coding assignment. It was expected to take 2-4 hours of work, was for a toy problem which was a simplified form of something we used in production, and contained no puzzles or "a-ha!" insights.
We got a submission from a candidate who has been in the industry since 1994. The candidate had used a static variable when a member variable was the right thing to do. The class (in Java) looked something like this:
class Foo {
static Map map = new HashMap();
void addStuff(String key, Object stuff) { map.put(key, stuff); }
int getSize() { return map.size(); }
}
void testFooInit() {
Foo foo = new Foo();
assertEquals(3, foo.getSize());
}
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.
thats enough for me to not call him "crappy" ...perhaps i would call him "ok"
> 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.
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.
But when the line:
Foo foo = new Foo();
assertEquals(
the hiring/recruiting culture often looks like a circus run by mad people
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.
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.
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.
It's amazing that these horribly managed companies haven't gone bankrupt yet.
The rest get to continue past the first five minutes.
70% of people can't do fizzbuzz during the interview?
For our coding screen, we use coderpad.io, which lets you chose whatever language you want. Go try it out yourself!
That's so surprising to me that such a large percentage fail, especially if they get to choose the language
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?
Every time it's mentioned, I have to go look up what it means. For some reason, it refuses to stick in my head.
... 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.
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 isn't to say artisanship is unimportant, but that it's not the most important thing.
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.
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.
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.
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".
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.
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.
When 33% of applicants can't write a program to solve 3 numbers, HackerRank becomes a mandatory step.
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.
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.
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 :)
Or do you not think about that part, or conclude that anyone qualified you pass on is a fair cost to pay?
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.
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.)
[1]: https://www.hackerrank.com/leaderboard/java/practice/level/1...
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.
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.
That would be .. weird, right?
> 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.
The article asks if this can be true and tries to prove that this would be a rather foolish metric.
They also have lessons: https://codility.com/programmers/lessons/1-iterations/ and challenges: https://codility.com/programmers/challenges/
Copy/Paste the solutions from the discussions page.
Cached version: http://webcache.googleusercontent.com/search?q=cache:3BXmrLl...
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.
Great read, worked for about 10 years in dev never heard about hackerrank but it's part of a pattern sure.
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.
This is our global leaderboard sections [2] : http://i.imgur.com/2rkgwmg.png
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.
[1]: https://www.hackerrank.com/leaderboard/java/practice/level/1...
[2]: https://www.hackerrank.com/leaderboard
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.
- https://www.hackerearth.com/
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.
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.
This is imaginary internet points we are talking about here, not your PHD thesis.
The internet points on these websites really don't matter, what matters is the skills you learn while doing them.
Internet points aside, HackerRank is a technical recruiting platform.
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?
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.
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.
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 ;)
You're never going to find happiness that way, friend.
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.
Those who "game" the system are easily filtered out.
It seems no algorithm there taught you more useful things though.