Developer Skills Report(research.hackerrank.com)
research.hackerrank.com
Developer Skills Report
https://research.hackerrank.com/developer-skills/2018/
194 comments
I have never understood the point of HackerRank. I even got into it with fairly high-up executives at my last job for refusing to fall in-line and use it as a tool. As far as I'm concerned all it does is exacerbate the already terrible hiring practices and hiring biases that plague the software industry.
I'm now CTO of a company operating a space that's as challenging as it is esoteric. We make hardware for adding by-wire controls to some existing cars to do autonomous vehicle test/validation. We make high-fidelity, high-bandwidth data capture software for AV sensor mules. We're working on a SDLC that enforces cryptographic chain of custody and produces safety-certification evidence as a continuous delivery artifact, and we're working on a high-assurance runtime environment for AV applications.
Hiring for this diversity of internal & external products would appear to be extremely challenging, but reforming/growing the existing teams and building new teams has proven fairly easy. Insofar as quality of new hires, productivity & growth of realigned staff, etc. is concerned. The challenge was in all the preparation it took to make it easy.
1. I never hire until I am absolutely certain I can identify and articulate a very specific need that aligns with a very specific set of goals.
2. I never hire until I am absolutely certain I understand the responsibilities and level of ownership required to meet those goals.
3. I never hire until I have a meaningful frontier set of models for the personality profiles (fallabilty acknowledged) that are likely to align with both those responsibilities and of the people they'll work most closely with.
4. I have candidates pair with someone or someones they'd actually work with on an actual problem being actively worked on by the team. Why contrive a pointless artifice like programmer-trivia---to guess at what the person would be like on the team---when I can make them an honorary member of their actual future team for a couple hours on-site or over video/screenshare?
5. I don't try to get a bargain on my hires. If I've managed to do all the above, then I know what I need, I know what it's worth, and I know how I need to manage my financial constraints.
This is my problem with things like HackerRank. It's just a thing that hiring managers can hide behind as a kind of faux-rigor to produce a completely meaningless "score" as though such a complex thing can be distilled down into a single number and used as some common metric for comparison.
Hiring is too important to the company, the team, and ultimately the candidate---whose livelihood you now partially hold in your hand---to be so fundamentally lazy about it.
I'm now CTO of a company operating a space that's as challenging as it is esoteric. We make hardware for adding by-wire controls to some existing cars to do autonomous vehicle test/validation. We make high-fidelity, high-bandwidth data capture software for AV sensor mules. We're working on a SDLC that enforces cryptographic chain of custody and produces safety-certification evidence as a continuous delivery artifact, and we're working on a high-assurance runtime environment for AV applications.
Hiring for this diversity of internal & external products would appear to be extremely challenging, but reforming/growing the existing teams and building new teams has proven fairly easy. Insofar as quality of new hires, productivity & growth of realigned staff, etc. is concerned. The challenge was in all the preparation it took to make it easy.
1. I never hire until I am absolutely certain I can identify and articulate a very specific need that aligns with a very specific set of goals.
2. I never hire until I am absolutely certain I understand the responsibilities and level of ownership required to meet those goals.
3. I never hire until I have a meaningful frontier set of models for the personality profiles (fallabilty acknowledged) that are likely to align with both those responsibilities and of the people they'll work most closely with.
4. I have candidates pair with someone or someones they'd actually work with on an actual problem being actively worked on by the team. Why contrive a pointless artifice like programmer-trivia---to guess at what the person would be like on the team---when I can make them an honorary member of their actual future team for a couple hours on-site or over video/screenshare?
5. I don't try to get a bargain on my hires. If I've managed to do all the above, then I know what I need, I know what it's worth, and I know how I need to manage my financial constraints.
This is my problem with things like HackerRank. It's just a thing that hiring managers can hide behind as a kind of faux-rigor to produce a completely meaningless "score" as though such a complex thing can be distilled down into a single number and used as some common metric for comparison.
Hiring is too important to the company, the team, and ultimately the candidate---whose livelihood you now partially hold in your hand---to be so fundamentally lazy about it.
Vivek (founder/ceo of hackerrank) here. Appreciate your comments. When we started HackerRank, it was oriented towards problem solving / algorithmic challenges which assess a certain level of computational thinking skill -- can you break large problems into sub-problems and solve? I still believe this is a good measure but somehow algorithm challenges have been associated with asking complex red-black trees / graph theory questions which has got nothing to do with actual work.
We have been working super hard (and will continue to) to emphasis on 3 aspects -- problem solving to test computational thinking with basic data structures, role-specific knowledge (for e.g. react if you are hiring a front-end developer) & language proficiency (strength in at least one language) as the 3 pillars.
Given the foundation of HackerRank & the overall associated impression of algorithm challenges, we often get bucketed into a "puzzle company". Obviously, this is on us to make the narrative better and we are working towards it.
Ultimately, the goal of us is to ensure developer experience is great -- showcase your skills in the language/framework you are comfortable in with more time (not a 60-min test). It will take sometime but we are heading in that direction.
We have been working super hard (and will continue to) to emphasis on 3 aspects -- problem solving to test computational thinking with basic data structures, role-specific knowledge (for e.g. react if you are hiring a front-end developer) & language proficiency (strength in at least one language) as the 3 pillars.
Given the foundation of HackerRank & the overall associated impression of algorithm challenges, we often get bucketed into a "puzzle company". Obviously, this is on us to make the narrative better and we are working towards it.
Ultimately, the goal of us is to ensure developer experience is great -- showcase your skills in the language/framework you are comfortable in with more time (not a 60-min test). It will take sometime but we are heading in that direction.
Humble suggestion: add more front end-specific challenges. I do a lot of front end work. I cannot begin to tell you how irritating (infuriating?) it is to have a company express interest, send over a HackerRank test, and then you find out that they picked a bunch of algo questions that have nothing to do with building a UI.
This happens more often than you'd think.
This happens more often than you'd think.
Agree. agree. we really need to work on that.
Hi Vivek,
My previous employer eventually made HackerRank a requirement for hiring. Fortunately, by that time I had already basically figured out how to freeze the size of my team despite having an absurdly large headcount projection attempting to being forced onto it, so I was able to ultimately abstain from using it (after catching some hell for actively opposing it).
However, if I had been in a position to have to use such a tool, there was a major failing in the way it worked (at least 2+ years ago) that would have made it impossible to derive useful meaning for me from the results.
What was critical to partially assess for me was a person's ability to fully understand the nature of basic assumptions they take for granted. To get a sense of their completeness of thought and appropriate self-doubt in that completeness.
I wanted to do this by being able to provide a black-box implementation of two simple functions:
add/2 multiply/2
Both of which would be intentionally implemented incorrectly. Then I wanted to be able to have the user write out property-based tests that would help them discover the way in which the opaque underlying implementation was flawed despite the fact that they would have no internal knowledge of the implementation.
This would have very roughly allowed me to assess:
1. How they dismantle basic lifelong concepts that have become mental reflexes like addition and multiplication, but in terms of their properties and invariants (associativity, commutativity, identity, etc).
2. Then also whether or not they could infer what was wrong with the simple opaque implementation based on which properties/invariants weren't holding as they should have. So that I could see how they handled their confidence in the completeness of their analysis.
No idea if you could do this today, but at the time the HackerRank system couldn't usefully support the above use case. Or at least the person who conducted the training had no idea how one would do such a thing.
My previous employer eventually made HackerRank a requirement for hiring. Fortunately, by that time I had already basically figured out how to freeze the size of my team despite having an absurdly large headcount projection attempting to being forced onto it, so I was able to ultimately abstain from using it (after catching some hell for actively opposing it).
However, if I had been in a position to have to use such a tool, there was a major failing in the way it worked (at least 2+ years ago) that would have made it impossible to derive useful meaning for me from the results.
What was critical to partially assess for me was a person's ability to fully understand the nature of basic assumptions they take for granted. To get a sense of their completeness of thought and appropriate self-doubt in that completeness.
I wanted to do this by being able to provide a black-box implementation of two simple functions:
add/2 multiply/2
Both of which would be intentionally implemented incorrectly. Then I wanted to be able to have the user write out property-based tests that would help them discover the way in which the opaque underlying implementation was flawed despite the fact that they would have no internal knowledge of the implementation.
This would have very roughly allowed me to assess:
1. How they dismantle basic lifelong concepts that have become mental reflexes like addition and multiplication, but in terms of their properties and invariants (associativity, commutativity, identity, etc).
2. Then also whether or not they could infer what was wrong with the simple opaque implementation based on which properties/invariants weren't holding as they should have. So that I could see how they handled their confidence in the completeness of their analysis.
No idea if you could do this today, but at the time the HackerRank system couldn't usefully support the above use case. Or at least the person who conducted the training had no idea how one would do such a thing.
>4. I have candidates pair with someone or someones they'd actually work with on an actual problem being actively worked on by the team. Why contrive a pointless artifice like programmer-trivia---to guess at what the person would be like on the team---when I can make them an honorary member of their actual future team for a couple hours on-site or over video/screenshare?
This is the absolutely best skills test I've seen so far. More companies need to try it out.
One of the biggest benefits is that it removes the adversarial relationship of a normal whiteboard interview. That kind of adversarial relationship almost never happens day to day (and if it does something is very wrong).
This is the absolutely best skills test I've seen so far. More companies need to try it out.
One of the biggest benefits is that it removes the adversarial relationship of a normal whiteboard interview. That kind of adversarial relationship almost never happens day to day (and if it does something is very wrong).
The counter argument is how does this provide a level playing ground upon which to compare candidates? Some days, what a team works on is grunt work or trivial. Some days it is designing new, high scale software. And some days it it working on something requiring esoteric knowledge or cracking a difficult bug. There is so much variability depending on when the candidate comes in. Compare this to a set of interview questions or tasks that touch on how an applicant deals with many facets of the above, which is what I'm familiar with.
I would question what signaling effects you think you're actually measuring when you're presenting contrived scenarios for which you already know the answers.
There's a tremendous amount of variability in whether or not the artificial test that's been created actually maps appropriately to what you're trying to assess. It's extremely difficult to do well. There's further variability in the proctoring and posturing in how the assessment is performed, not just the assessment itself.
Almost certainly you've added layers of obfuscation to the thing you actually want to know, unless what you want to know is how good the person is at taking your specific test, which may or may not usefully test anything, and which may or may not be administered in a way that could get useful results even if the test itself is meticulously well-crafted.
If you're intent on, or can't avoid, operating a more traditional looking hiring process, then I'd suggest at least trying this. Even if the assessment is contrived, then use questions that nobody in the room knows the answers to, including yourself. It doesn't relate to the work directly necessarily, but it can at least help mitigate the effects of survivorship bias.
There's a tremendous amount of variability in whether or not the artificial test that's been created actually maps appropriately to what you're trying to assess. It's extremely difficult to do well. There's further variability in the proctoring and posturing in how the assessment is performed, not just the assessment itself.
Almost certainly you've added layers of obfuscation to the thing you actually want to know, unless what you want to know is how good the person is at taking your specific test, which may or may not usefully test anything, and which may or may not be administered in a way that could get useful results even if the test itself is meticulously well-crafted.
If you're intent on, or can't avoid, operating a more traditional looking hiring process, then I'd suggest at least trying this. Even if the assessment is contrived, then use questions that nobody in the room knows the answers to, including yourself. It doesn't relate to the work directly necessarily, but it can at least help mitigate the effects of survivorship bias.
>Compare this to a set of interview questions or tasks that touch on how an applicant deals with many facets of the above, which is what I'm familiar with.
And none of those interview questions will measure how the candidate performs in your team's day to day environment, nearly as well.
And none of those interview questions will measure how the candidate performs in your team's day to day environment, nearly as well.
the job isn't just about the candidate - it's also about the existing team, and the pairing together provides data points for both parties as to how they'd work together, regardless of the task at hand.
I really like your overall approach, and think other hiring managers would do well to emulate a variant, but point 3 seems to be a bit 'woo'. Could you provide some more detail (or examples) of how you build a required personality profile in advance?
I'm not sure what you mean exactly by, "woo", but I can provide a little bit of context. The most important thing to note is that this has proven only meaningful or useful to me in the context of all the other things I mentioned as well. It doesn't stand on its own, ever.
Mostly it's a framework for how to think about dimensions of the problem in the abstract. It's like "team architecture" analysis. I use the OCEAN trait model. I'm aware of it's limitations (and they are numerous), as well as those of other models and methods. The reason I use it is because it's a simple enough, but still rich enough, model for me to be able to partially apply on-the-fly through casual conversation, etc.
For me it breaks down roughly like:
1. I think about that job that I need done and plan traits that probably map to that job. The kind of expressed traits that surface in a fastidious-finisher are very rarely also the traits that surface in a cowboy-hacker (the coarseness of the caricatures is for illustration only).So there's a sketch that looks like: O-low, C-mid, E-NA, A-mid, N-low or something for any given need.
2. I plan out the set of traits that are mandatory to be expressed (or not expressed) strongly. Like it might be the case that I need someone to be super high on C, but if they're also super high on N, and being high on N is fairly undesirable for the current situation, then that warrants further exploration. The point of this is to try to help prioritize focus on what to assess, how to assess it, reasonable confidence in the assessment, and which dimensions are fine to be really fuzzy.
3. With model priorities in place, when speaking to people there are a lot of ways to prompt, leave empty airspace, and methods of story-telling that facilitate creating safer space for a broader spectrum of interaction than is often expected in a normal hirer-hiree dynamic. These help guide filling in that rudimentary sketch. Talking about almost anything other than the job itself helps with this because it's important to try to establish a peer-like posture. With a lot of practice one can get "okay" at doing this in such a way that it can be a meaningful, but incomplete, weight in the calculus on how to proceed with a candidate as well as the team the candidate would be joining.
4. Lastly, the most important thing to do here from my experience is to bias myself toward constantly trying to rapidly invalidate my model sketch at every possible stage of interaction from the first email exchange all the way up to issuing an offer. This does a few things. It forces me to have constant and active intention in every single step of the process and every single interaction with a person. It keeps me from religiously believing in the modelling itself because it's constantly clear that it's incomplete and fallible. Perhaps most important is that it puts the adversarial focus on myself and my assessment process rather than laying that adversarial relationship on the candidate.
I have to read as much or more about psychology and neuroscience as I do about byzantine fault-detection or applications of formal methods. Hiring can't be an afterthought that we as hiring-managers take lightly or try to relegate to passive tools or industry norms that seem patently ridiculous on their face.
Every "bad hire", every misaligned/unsatisfied employee, and every termination is ultimately the fault of management.
Mostly it's a framework for how to think about dimensions of the problem in the abstract. It's like "team architecture" analysis. I use the OCEAN trait model. I'm aware of it's limitations (and they are numerous), as well as those of other models and methods. The reason I use it is because it's a simple enough, but still rich enough, model for me to be able to partially apply on-the-fly through casual conversation, etc.
For me it breaks down roughly like:
1. I think about that job that I need done and plan traits that probably map to that job. The kind of expressed traits that surface in a fastidious-finisher are very rarely also the traits that surface in a cowboy-hacker (the coarseness of the caricatures is for illustration only).So there's a sketch that looks like: O-low, C-mid, E-NA, A-mid, N-low or something for any given need.
2. I plan out the set of traits that are mandatory to be expressed (or not expressed) strongly. Like it might be the case that I need someone to be super high on C, but if they're also super high on N, and being high on N is fairly undesirable for the current situation, then that warrants further exploration. The point of this is to try to help prioritize focus on what to assess, how to assess it, reasonable confidence in the assessment, and which dimensions are fine to be really fuzzy.
3. With model priorities in place, when speaking to people there are a lot of ways to prompt, leave empty airspace, and methods of story-telling that facilitate creating safer space for a broader spectrum of interaction than is often expected in a normal hirer-hiree dynamic. These help guide filling in that rudimentary sketch. Talking about almost anything other than the job itself helps with this because it's important to try to establish a peer-like posture. With a lot of practice one can get "okay" at doing this in such a way that it can be a meaningful, but incomplete, weight in the calculus on how to proceed with a candidate as well as the team the candidate would be joining.
4. Lastly, the most important thing to do here from my experience is to bias myself toward constantly trying to rapidly invalidate my model sketch at every possible stage of interaction from the first email exchange all the way up to issuing an offer. This does a few things. It forces me to have constant and active intention in every single step of the process and every single interaction with a person. It keeps me from religiously believing in the modelling itself because it's constantly clear that it's incomplete and fallible. Perhaps most important is that it puts the adversarial focus on myself and my assessment process rather than laying that adversarial relationship on the candidate.
I have to read as much or more about psychology and neuroscience as I do about byzantine fault-detection or applications of formal methods. Hiring can't be an afterthought that we as hiring-managers take lightly or try to relegate to passive tools or industry norms that seem patently ridiculous on their face.
Every "bad hire", every misaligned/unsatisfied employee, and every termination is ultimately the fault of management.
Recruiter: “How many hours a day would you say you use Meteor?”
Doesn't matter because you probably have experience in the wrong version of it anyway.
I can think of a dozen reasons for that, but here are a few of the most salient ones;
1. Reading and evaluating code in an unfamiliar context is really £@#&ing hard, especially on a complex project. Understanding someone's commits requires knowledge of the project as a whole, the problem space, the environment, etc. That's not possible to do for a large number of candidates. It might not give you a very good insight in to an applicant.
2. Most people's public code is of roughly equal quality (eg 'not great'). You can't really differentiate between people well based on it. What people do in their spare time for fun is rarely commented/tested/documented/etc, so it's a bad way to evaluate their skill level. If you find someone with good public code that's a great sign, but a hiring manager who's looked at 100 Github profiles and found zero good ones might reasonably have given up looking.
Also it could be seen as a discriminatory factor; if you think public code is important you're going to overlook people with little time to write any, eg those with families, care responsibilities, interests outside of coding. Building a great team is about hiring great people more that just great developers.
3. It's hard to trust someone's public code. It's trivial to clone a few open projects and take credit for the work, and a hiring manager doesn't have the time to dig in to everyone's projects to see if they've ripped the work off from somewhere.
Also, you may have dealt with 50 hiring managers who have never looked at your public code in your career so far. That isn't very many really.
I certainly wish there was a better way to evaluate developers skill, and as someone who has plenty of public work on Github I think it'd be great if that was a good starting point, but I don't think it's quite good enough yet. I can certainly see why hiring managers don't look there.
1. Reading and evaluating code in an unfamiliar context is really £@#&ing hard, especially on a complex project. Understanding someone's commits requires knowledge of the project as a whole, the problem space, the environment, etc. That's not possible to do for a large number of candidates. It might not give you a very good insight in to an applicant.
2. Most people's public code is of roughly equal quality (eg 'not great'). You can't really differentiate between people well based on it. What people do in their spare time for fun is rarely commented/tested/documented/etc, so it's a bad way to evaluate their skill level. If you find someone with good public code that's a great sign, but a hiring manager who's looked at 100 Github profiles and found zero good ones might reasonably have given up looking.
Also it could be seen as a discriminatory factor; if you think public code is important you're going to overlook people with little time to write any, eg those with families, care responsibilities, interests outside of coding. Building a great team is about hiring great people more that just great developers.
3. It's hard to trust someone's public code. It's trivial to clone a few open projects and take credit for the work, and a hiring manager doesn't have the time to dig in to everyone's projects to see if they've ripped the work off from somewhere.
Also, you may have dealt with 50 hiring managers who have never looked at your public code in your career so far. That isn't very many really.
I certainly wish there was a better way to evaluate developers skill, and as someone who has plenty of public work on Github I think it'd be great if that was a good starting point, but I don't think it's quite good enough yet. I can certainly see why hiring managers don't look there.
> It might not give you a very good insight in to an applicant.
I'd argue pointless whiteboard trivia doesn't give you good insight into an applicant, either. And yet, 90% of companies do it.
> Most people's public code is of roughly equal quality (eg 'not great').
I disagree with this. Unless you're looking at a toy or unfinished project, most code that's released (on npm, maven, or something similar) is actually fairly high quality. Certainly higher quality than what I've had to work with in production systems that were making millions of dollars a month.
> Building a great team is about hiring great people more that just great developers.
I completely agree. So why do we dehumanize potential hires with standard practices that involve (for example) memorizing algorithms you'll never use? I mean, HackerRank is a testament to how awful our culture is. Is there a DoctorRank or SecurityGuardRank or WaiterRank?
> It's hard to trust someone's public code.
I think this is complete BS. There's people much smarter than me that are getting screwed by these terrible practices. Max Howell, Homebrew's author, was famously rejected by Google for not passing some stupid whiteboard exam, when just about everyone at Google actually uses the software he authored.
I'd argue pointless whiteboard trivia doesn't give you good insight into an applicant, either. And yet, 90% of companies do it.
> Most people's public code is of roughly equal quality (eg 'not great').
I disagree with this. Unless you're looking at a toy or unfinished project, most code that's released (on npm, maven, or something similar) is actually fairly high quality. Certainly higher quality than what I've had to work with in production systems that were making millions of dollars a month.
> Building a great team is about hiring great people more that just great developers.
I completely agree. So why do we dehumanize potential hires with standard practices that involve (for example) memorizing algorithms you'll never use? I mean, HackerRank is a testament to how awful our culture is. Is there a DoctorRank or SecurityGuardRank or WaiterRank?
> It's hard to trust someone's public code.
I think this is complete BS. There's people much smarter than me that are getting screwed by these terrible practices. Max Howell, Homebrew's author, was famously rejected by Google for not passing some stupid whiteboard exam, when just about everyone at Google actually uses the software he authored.
I've had to do one whiteboard coding exercise in my entire career. I knew two other devs that had interview at this company, so I knew what to expect. I accepted the in person interview on a whim. I already had accepted an offer as the dev lead for another company.
The whiteboard interview was to write out algorithm for a merge sort. I thought it was the silliest thing in the world. I had already accepted a position to basically create a development department, and he wants me to write a sort algorithm? Once he described how it worked, I wrote it without much difficulty but that was a turn off and I got an offer that was permanent (as opposed to contract to perm for the offer I accepted), making more money, with a signing bonus.
It was such a turn off, I declined the offer for a chance to build a department that would not expose developers to this foolishness and thought that the interview process tells you a lot about the company.
A year later. I'm glad I made the choice I did.
On the other hand, I've done quite a few pair programming type of interviews where there was a skeleton of a program with a lot of failing unit tests you had to make pass. I enjoy those.
Is there a DoctorRank or SecurityGuardRank or WaiterRank?*
Doctors have to go to school 8+ years and do a 2-4 year residency before they can practice without supervision. Lawyers have to go to school 7 years and pass an exam. Software Engineers only have to watch a couple of YouTube videos and they can call themselves "programmers". Doctors can't say they are qualified because they have been doing brain surgery since 6th grade in their bedroom.
The whiteboard interview was to write out algorithm for a merge sort. I thought it was the silliest thing in the world. I had already accepted a position to basically create a development department, and he wants me to write a sort algorithm? Once he described how it worked, I wrote it without much difficulty but that was a turn off and I got an offer that was permanent (as opposed to contract to perm for the offer I accepted), making more money, with a signing bonus.
It was such a turn off, I declined the offer for a chance to build a department that would not expose developers to this foolishness and thought that the interview process tells you a lot about the company.
A year later. I'm glad I made the choice I did.
On the other hand, I've done quite a few pair programming type of interviews where there was a skeleton of a program with a lot of failing unit tests you had to make pass. I enjoy those.
Is there a DoctorRank or SecurityGuardRank or WaiterRank?*
Doctors have to go to school 8+ years and do a 2-4 year residency before they can practice without supervision. Lawyers have to go to school 7 years and pass an exam. Software Engineers only have to watch a couple of YouTube videos and they can call themselves "programmers". Doctors can't say they are qualified because they have been doing brain surgery since 6th grade in their bedroom.
I think half the reason companies can't find talent is: 1. They wouldn't know it if it hit them in the face. 2. They actively repel talent by their interviewing practices. 3. They refuse to learn form this mistake. Since it couldn't possibly be them (they are infallible of course), it must be the talent.
This is 100% true. Earlier in my career I might have jumped through these types of hoops because I needed a job. Today, if a potential employer were to tell me I needed to go write X test program for free or do some bullshit test on Hacker Rank I would just say, "No thanks, I've got better things to do." Then I would move on to the next employer.
At this stage in my career when I still get this type of bullshit from someone I just find it ridiculous.
I'm just left thinking, "Did you read my cover letter? Where I told you how I worked on a 3 million CLOC air flight cockpit software that runs in actual planes; so if there are bugs real people would die? How about the part where I discussed being the software lead on financial derivatives trading software; where bugs could lead to millions or even billions of dollars be lost? Did you see that software library I maintain in my free time that has over 1 million installs? And you still aren't sure I'm qualified? Well no sense wasting any more of your time; I'm clearly not qualified then."
Ironically what I would consider the two best interviews of my career went like this respectively.
1) I was called in for a technical interview. The VP of the IT department sat down with me and asked me to tell him about my work experience. I gave him an overview and then he started delving in deeper and deeper on the subjects that I said I had experience in to see what my level of knowledge was. This went on for about 1 1/2 hours at which point he stopped me and said, "Ok, how much money do you need?" I gave him a number to which he replied, "We could do that. Hold on a minute." The VP then went and brought in his top developer (turns out he's also the hiring director) and then we basically repeated the whole thing, but dove into even more technical details. That lasted somewhere between 2 and 3 hours. At the end of it this he says, "I can have an offer letter ready for you tomorrow. When can you start."
2) Preface - I was referred by someone already working with this company.
I get a phone call from the company CEO (small start-up). He asks me a few questions about my background, some soft skill type of questions, nothing real technical. After 20 or 30 minutes of conversation that is basically just a "can we get along with each other" check the CEO says, "Ok, I'll need you to do a technical interview with our team lead." A couple days later I get a call from the team lead.
The conversation goes basically like this.
Him, "Ok, so here's the deal. Steve says your really fucking smart and Steve is really fucking smart so it's probably true. Elijah (CEO) thinks we need to do technical interviews, but really they're all just bullshit anyway. If it turns out you can't do the job we'll fire you in less than three months; if you actually know what you're doing we won't. So do you want the job or not?"
Me, "Yeah"
At this stage in my career when I still get this type of bullshit from someone I just find it ridiculous.
I'm just left thinking, "Did you read my cover letter? Where I told you how I worked on a 3 million CLOC air flight cockpit software that runs in actual planes; so if there are bugs real people would die? How about the part where I discussed being the software lead on financial derivatives trading software; where bugs could lead to millions or even billions of dollars be lost? Did you see that software library I maintain in my free time that has over 1 million installs? And you still aren't sure I'm qualified? Well no sense wasting any more of your time; I'm clearly not qualified then."
Ironically what I would consider the two best interviews of my career went like this respectively.
1) I was called in for a technical interview. The VP of the IT department sat down with me and asked me to tell him about my work experience. I gave him an overview and then he started delving in deeper and deeper on the subjects that I said I had experience in to see what my level of knowledge was. This went on for about 1 1/2 hours at which point he stopped me and said, "Ok, how much money do you need?" I gave him a number to which he replied, "We could do that. Hold on a minute." The VP then went and brought in his top developer (turns out he's also the hiring director) and then we basically repeated the whole thing, but dove into even more technical details. That lasted somewhere between 2 and 3 hours. At the end of it this he says, "I can have an offer letter ready for you tomorrow. When can you start."
2) Preface - I was referred by someone already working with this company.
I get a phone call from the company CEO (small start-up). He asks me a few questions about my background, some soft skill type of questions, nothing real technical. After 20 or 30 minutes of conversation that is basically just a "can we get along with each other" check the CEO says, "Ok, I'll need you to do a technical interview with our team lead." A couple days later I get a call from the team lead.
The conversation goes basically like this.
Him, "Ok, so here's the deal. Steve says your really fucking smart and Steve is really fucking smart so it's probably true. Elijah (CEO) thinks we need to do technical interviews, but really they're all just bullshit anyway. If it turns out you can't do the job we'll fire you in less than three months; if you actually know what you're doing we won't. So do you want the job or not?"
Me, "Yeah"
About the same experience with my current job.
It was a contract to perm position. I asked my now manager, why was this a contract to perm position? Was it because they wanted to see if the person was a good fit or were they under a budget constraint that might stop me from coming on permanently? He said the former.
I had to create the department from scratch with basically nothing but "database developers" who were just learning C# and no infrastructure. I laid out a 6 month plan. Six months in, i was able to negotiate a higher pay than I could have originally since it was my first official lead role and make extra money by being able to bill hourly. It was a major win.
When I was single without the skill set, network, or health benefits from my spouse, I would have never left a full time position for a contract to perm.
It was a contract to perm position. I asked my now manager, why was this a contract to perm position? Was it because they wanted to see if the person was a good fit or were they under a budget constraint that might stop me from coming on permanently? He said the former.
I had to create the department from scratch with basically nothing but "database developers" who were just learning C# and no infrastructure. I laid out a 6 month plan. Six months in, i was able to negotiate a higher pay than I could have originally since it was my first official lead role and make extra money by being able to bill hourly. It was a major win.
When I was single without the skill set, network, or health benefits from my spouse, I would have never left a full time position for a contract to perm.
I think part of the reason for whiteboard style interviews is that programmers don’t have a professional body evaluating their programming skills and knowledge like many other professions do. You can have a CS degree without really being much of a programmer. I’ve seen quite a few Masters graduates that can’t program at fizz buzz level.
I agree that something like implementing a merge sort is ridiculous. On the other hand I think it’s fair to expect a CS graduate to recall some of what they have learned without the questions being condemned as pointless trivia.
> programmers don’t have a professional body evaluating their programming skills and knowledge like many other professions do
Even if there was, no one would trust it. Case in point: ABET will accredit CS programs like they do other engineering programs; not many schools bother because companies don't give a shit about it.
> You can have a CS degree without really being much of a programmer.
You can get a BSEE without being much of an engineer, too. BSEE new grads definitely get tested by hiring companies to make sure they know their shit, but it is nothing like what this industry does.
Even if there was, no one would trust it. Case in point: ABET will accredit CS programs like they do other engineering programs; not many schools bother because companies don't give a shit about it.
> You can have a CS degree without really being much of a programmer.
You can get a BSEE without being much of an engineer, too. BSEE new grads definitely get tested by hiring companies to make sure they know their shit, but it is nothing like what this industry does.
> The whiteboard interview was to write out algorithm for a merge sort. I thought it was the silliest thing in the world.
Last one I had was to implement QuickSort. Had a -huge- argument with the interviewer who insisted there was an off-by-one error and it would never work. Needless to say, he was thoroughly wrong once it was coded up and I didn't get the job. :)
> It was such a turn off
It's pretty much an automatic "no" for me now too.
Last one I had was to implement QuickSort. Had a -huge- argument with the interviewer who insisted there was an off-by-one error and it would never work. Needless to say, he was thoroughly wrong once it was coded up and I didn't get the job. :)
> It was such a turn off
It's pretty much an automatic "no" for me now too.
When the interviewer gets angry (wrong or right) I take that as a useful filter not to work there
And the rest of the story....
After the contract was over, I was able to negotiate a higher pay to convert to perm than the job I declined offered even with the signing bonus.
After the contract was over, I was able to negotiate a higher pay to convert to perm than the job I declined offered even with the signing bonus.
This is kind of interesting and brings up a question: would you recommend as a technical lead who has powers to hire, that I go on interviews to other companies myself to see what's great and what sucks in their hiring process? Is it worth while?
I didn't purposefully do that, but I've changed jobs three times since 2012, had 30+ phone screens and 6 in person interviews (I keep a Google Sheet). With no rejections (equally due to going through recruiters as my own skill set). So I've had the chance to see what I like and don't like.
In my experience, the best type of coding tests are based on creating a skeleton program with failing unit tests already written and pair program with the candidate and see how they code and make the unit tests pass.
Currently I have two phases in my unit test based interview.
Phase 1: simpler tests and requirements that they have to make pass.
Phase 2: more complicated requirements and a second set of unit tests they have to make pass without breaking the first set.
To me, that mirrors how we actually work - get an MVP out the door relatively fast and add features later on ensuring you don't get regressions.
In my experience, the best type of coding tests are based on creating a skeleton program with failing unit tests already written and pair program with the candidate and see how they code and make the unit tests pass.
Currently I have two phases in my unit test based interview.
Phase 1: simpler tests and requirements that they have to make pass.
Phase 2: more complicated requirements and a second set of unit tests they have to make pass without breaking the first set.
To me, that mirrors how we actually work - get an MVP out the door relatively fast and add features later on ensuring you don't get regressions.
Your interview actually sounds like a fun process. I've been really frustrated with all of this lately. I don't know what I should be focusing on. Should I grind LeetCode/HackerRank, work on personal projects, or read CTCI a million times (ugh)? I love working on projects more than trying to solve problems on LeetCode/HackerRank.
Agreed on this being the best way. Companies using HackerRank can do this process today in CodePair, where the code can be run to ensure the test cases pass and recorded for replay.
'I'd argue pointless whiteboard trivia doesn't give you good insight into an applicant, either. And yet, 90% of companies do it.'
I've (thankfully), never had to whiteboard. Think it's a US/SF thing.
That these interview techniques are determined so much by culture, fashion, and following what the successful companies do (I.e. Google), in itself shows how useless they are.
That said, I acknowledge I can't think of a perfect way to assess software engineers. We have a take home exercise, but ultimately gut feel drives the decision.
I've (thankfully), never had to whiteboard. Think it's a US/SF thing.
That these interview techniques are determined so much by culture, fashion, and following what the successful companies do (I.e. Google), in itself shows how useless they are.
That said, I acknowledge I can't think of a perfect way to assess software engineers. We have a take home exercise, but ultimately gut feel drives the decision.
>>I've (thankfully), never had to whiteboard. Think it's a US/SF thing.
And that has spread all over the world now, because a lot of companies outside of SV, tend to view these BigWebCo's as something to emulate and imitate from, and are doing these whiteboard interview all the time.
In fact the whole point of these Hacker rank kind of sites is to basically provide the web equivalent of a white board. You are asked to submit code(Typically some question based on a exaggerated edge case of some algorithm) and see if it passes all test cases. You are in if it does, out otherwise.
And that has spread all over the world now, because a lot of companies outside of SV, tend to view these BigWebCo's as something to emulate and imitate from, and are doing these whiteboard interview all the time.
In fact the whole point of these Hacker rank kind of sites is to basically provide the web equivalent of a white board. You are asked to submit code(Typically some question based on a exaggerated edge case of some algorithm) and see if it passes all test cases. You are in if it does, out otherwise.
I'd argue pointless whiteboard trivia doesn't give you good insight into an applicant, either. And yet, 90% of companies do it.
The fact that some companies use bad practises for hiring doesn't change how hard it is to judge someone's code from their Github repo. I agree that whiteboard tests are horrible, but switching to a different bad idea wouldn't help.
Unless you're looking at a toy or unfinished project, most code that's released (on npm, maven, or something similar) is actually fairly high quality. Certainly higher quality than what I've had to work with in production systems that were making millions of dollars a month.
You're moving the goal posts from "Has code in public" to "Launched, contributed to, or otherwise involved with a successful open project." That's quite different, and arguably a lot of hiring managers do look at that sort of thing very favourably.
I think this is complete BS. There's people much smarter than me that are getting screwed by these terrible practices. Max Howell, Homebrew's author, was famously rejected by Google for not passing some stupid whiteboard exam, when just about everyone at Google actually uses the software he authored.
I'll defer to Max's own explanation for that: https://www.quora.com/Whats-the-logic-behind-Google-rejectin...
As he says himself, Homebrew is a successful product but not necessarily great computer science. He 'failed' a computer science question. We can question whether or not Google needed to ask that in the interview, but they clearly thought it was important enough for the role Max was applying for to ask it. So maybe rejecting him for that role was the right decision. We don't really know. We do know that he wasn't applying to Google for the job of "Homebrew Maintainer" so his work on Homebrew, while really impressive, isn't really the whole story in hiring him. Surely you're not suggesting that the author of a successful project should be able to walk in to any developer role regardless of what's needed to do the job?
The fact that some companies use bad practises for hiring doesn't change how hard it is to judge someone's code from their Github repo. I agree that whiteboard tests are horrible, but switching to a different bad idea wouldn't help.
Unless you're looking at a toy or unfinished project, most code that's released (on npm, maven, or something similar) is actually fairly high quality. Certainly higher quality than what I've had to work with in production systems that were making millions of dollars a month.
You're moving the goal posts from "Has code in public" to "Launched, contributed to, or otherwise involved with a successful open project." That's quite different, and arguably a lot of hiring managers do look at that sort of thing very favourably.
I think this is complete BS. There's people much smarter than me that are getting screwed by these terrible practices. Max Howell, Homebrew's author, was famously rejected by Google for not passing some stupid whiteboard exam, when just about everyone at Google actually uses the software he authored.
I'll defer to Max's own explanation for that: https://www.quora.com/Whats-the-logic-behind-Google-rejectin...
As he says himself, Homebrew is a successful product but not necessarily great computer science. He 'failed' a computer science question. We can question whether or not Google needed to ask that in the interview, but they clearly thought it was important enough for the role Max was applying for to ask it. So maybe rejecting him for that role was the right decision. We don't really know. We do know that he wasn't applying to Google for the job of "Homebrew Maintainer" so his work on Homebrew, while really impressive, isn't really the whole story in hiring him. Surely you're not suggesting that the author of a successful project should be able to walk in to any developer role regardless of what's needed to do the job?
"As he says himself, Homebrew is a successful product but not necessarily great computer science. He 'failed' a computer science question. "
Maybe Google is different but I usually need to do computer cine type stuff about one a year.I have used recursion on maybe 4 different occasions in my carreer, but that's the sort of thing that comes up regularly in coding tests. Why not test for things that are actually being used on the job?
Maybe Google is different but I usually need to do computer cine type stuff about one a year.I have used recursion on maybe 4 different occasions in my carreer, but that's the sort of thing that comes up regularly in coding tests. Why not test for things that are actually being used on the job?
Some Google engineers work on the sort of problems, and at the sort of scale, where algorithms and the science that drives them actually makes a difference. I don't think it's unreasonable for Google to ask computer science questions in interviews where that's the case.
Some do, but instead of allocating you to a correct position for your skills based on your performance in the interview, you just get outright rejected, which means you have to try again and again until you find a position which happens to give an interview which you can pass.
Yes, that's true. But how many times when they need to solve those problems are they placed in front of a whiteboard in a fairly high pressure situation? Wouldn't they rather have a chance to collaborate, think, research, and test?
So you've only used json, or html, or (insert recursive data structure here) 4 times in your career? Seriously, recursion is everywhere.
Am I flexing my electrical engineering skills when I turn the TV on with a remote control? Parsing a json tree uses recursion under the hood but unless you are writing a new json parsing library each month you won't get the chance to use those recursion skills too often when dealing with json in day to day code.
> 3. It's hard to trust someone's public code. It's trivial to clone a few open projects and take credit for the work, and a hiring manager doesn't have the time to dig in to everyone's projects to see if they've ripped the work off from somewhere.
A public code repo is more than just code.
* It's documentation
Is there a decent README or other background info on how to get setup? Sample data? Tests?
* It's activity
Was this a fork with one patch and nothing since then? Or is it a long-term project with regular/periodic activity?
* It's community
Is this project getting bug reports, feature requests? How is the owner dealing with them? Ignoring them? Being rude? Actively engaging? Delegating? Honestly admitting they don't have the time and asking for help?
There's a whole mess you can judge about someone that goes beyond "code" when looking at a repo. I know someone who was hired at a company a couple years back who was brought in because of a friendship but the "github" profile was referenced as justification. "This person has a lot of projects and stars - they're definitely active!". The person had starred other projects, and had cloned about 40 repos, and made (trivial) changes in about 5 of them. They had no original code. The person had been brought in to lead a team of about 6 developers, and left within 2 months because they had no experience working with actual production code or working with people on a team. That was quite apparent from their github profile.
A public code repo is more than just code.
* It's documentation
Is there a decent README or other background info on how to get setup? Sample data? Tests?
* It's activity
Was this a fork with one patch and nothing since then? Or is it a long-term project with regular/periodic activity?
* It's community
Is this project getting bug reports, feature requests? How is the owner dealing with them? Ignoring them? Being rude? Actively engaging? Delegating? Honestly admitting they don't have the time and asking for help?
There's a whole mess you can judge about someone that goes beyond "code" when looking at a repo. I know someone who was hired at a company a couple years back who was brought in because of a friendship but the "github" profile was referenced as justification. "This person has a lot of projects and stars - they're definitely active!". The person had starred other projects, and had cloned about 40 repos, and made (trivial) changes in about 5 of them. They had no original code. The person had been brought in to lead a team of about 6 developers, and left within 2 months because they had no experience working with actual production code or working with people on a team. That was quite apparent from their github profile.
[deleted]
If I had a dollar for every time a recruiter has asked me to complete a code challenge within 5 minutes of my last push to GitHub, I wouldn't need to work anyway!
> That's funny, I've never had a hiring manager or interviewer look at my literal hundreds of thousands of lines of code on GitHub or several of the OSS projects I've contributed to.
I was thinking, since public repositories or open source contributions are the new "mandatory". If you want to see me coding, just request a new feature to one of my public repositories on github. These coding assignment you sent by email? I don't even bother to read them, in fact I store them scrupulously together with your email - once you might be looking for a job and I will be the one doing hiring.
I was thinking, since public repositories or open source contributions are the new "mandatory". If you want to see me coding, just request a new feature to one of my public repositories on github. These coding assignment you sent by email? I don't even bother to read them, in fact I store them scrupulously together with your email - once you might be looking for a job and I will be the one doing hiring.
In the last two years I got more and more questions to describe my professional projects and provide links to opensource project - that was a requirement.
I've never written a line of publicly accessible code in my life, I've been working for 20+ years and I rarely fail at getting an offer for a job I apply for. Then again, I don't submit resumes blindly. I always go through recruiters, that has more to do with my hit rate than my skill set.
Let me take that back. I got my first development job in college from another school about 100 miles away because he saw a HyperCard Eliza clone I wrote and posted on AOL back in 1993.
Let me take that back. I got my first development job in college from another school about 100 miles away because he saw a HyperCard Eliza clone I wrote and posted on AOL back in 1993.
I have an anecdote somewhere here about a developer I recommended hiring on our startup while I was off doing consulting work who was competent and basically ruined the company and destroyed a couple years worth of work because he knew how stuff just had to be.
I recommended hiring him based on a github profile.
I recommended hiring him based on a github profile.
> Irrespective of your job, it will become important for everyone to learn how to code
It strikes me that the person who wrote that is used to associating with technical people, and might spend a little more time in the real world. I work in a company of 100 ish people, 15 are delivery drivers. 40 odd are sales assistants that customers value for their detailed product knowledge. 4 are involved in cleaning of different kinds. None of those people will ever learn to code, or need to learn to code, or frankly be capable of learning to code
It strikes me that the person who wrote that is used to associating with technical people, and might spend a little more time in the real world. I work in a company of 100 ish people, 15 are delivery drivers. 40 odd are sales assistants that customers value for their detailed product knowledge. 4 are involved in cleaning of different kinds. None of those people will ever learn to code, or need to learn to code, or frankly be capable of learning to code
Completely agreed. Whoever wrote that should find a hobby or profession where being biased and living in a bubble doesn't cause others to be misinformed.
Do those sales people use complex spreadsheets? Are there major effeciency gains possible with a minor amount of scripting?
Depends on the role. But salespeople are there to sell stuff, the efficiency gains are orthogonal to the objective. Their job is to call people, go shake hands, get ink on dotted lines, etc. Not faff about with Excel.
Note: They also sell themselves to their bosses too. Hence why they tend to outlast engineers in largish orgs.
Note: They also sell themselves to their bosses too. Hence why they tend to outlast engineers in largish orgs.
mostly agree, although the sales/asst folks being able to use spreadsheets and understanding equations and similar is helpful in many situations, although most folks wouldn't think of that as 'code' so much. I'm working with a client and I'm surprised (sort of) as to how much they can get done in spreadsheets. Coding would make their lives even easier wrt to many tasks, but managing electronic data with some excel scripting is 'good enough' (compared the where they were with paper 10 years ago).
Don't be like these people. Keep an open mind, be ready to adapt, and try to just be kind. Kindness is one thing I can guarantee you'll want to have as a skill, in any future.
https://www.pcworld.com/article/155984/worst_tech_prediction...
https://www.pcworld.com/article/155984/worst_tech_prediction...
I was the author. I could have reworded. I still think computational thinking is an important skill irrespective of your job role & is actually a pretty powerful tool that helps you solve problems and make decisions. Coding is one of the fastest ways to get there.
Completely agree but I would also agree if you would have said:
None of those people will ever learn to code, or need to learn to code, or frankly be capable of learning to code, neither, we devs, are interested in that..
None of those people will ever learn to code, or need to learn to code, or frankly be capable of learning to code, neither, we devs, are interested in that..
Sales assistant jobs are being automated by AI
Cleaning tasks are being replaced by robotics
With 40% of jobs soon to be replaced by automation, if your colleagues want to stay ahead, they should learn to code.
[citation needed]
The U.S. will be hit worse by job automation than other major economies
A new study from PwC estimates that 38 percent of U.S. jobs could be lost to automation in the next 15 years.
https://www.recode.net/2017/3/25/15051308/us-uk-germany-japa...
> The biggest gap in knowledge is with JavaScript frameworks
> Most often, employers want developers who know AngularJS, Node.js, and React.
Am I overthinking this? When I've been looking for jobs, I've found the emphasis on JavaScript frameworks slightly perplexing and frustrating. I would assume that a competent web developer should be capable of quickly learning a framework. Having to know JavaScript, CSS, etc. to the level of passing a technical interview is already demanding.
Learning one framework very well is another opportunity cost. Researching and picking a framework to invest time into, then building a project or two using this new framework is another. Keeping up with the world of JavaScript framework developments is a whole project in and of itself.
> Most often, employers want developers who know AngularJS, Node.js, and React.
Am I overthinking this? When I've been looking for jobs, I've found the emphasis on JavaScript frameworks slightly perplexing and frustrating. I would assume that a competent web developer should be capable of quickly learning a framework. Having to know JavaScript, CSS, etc. to the level of passing a technical interview is already demanding.
Learning one framework very well is another opportunity cost. Researching and picking a framework to invest time into, then building a project or two using this new framework is another. Keeping up with the world of JavaScript framework developments is a whole project in and of itself.
> I would assume that a competent web developer should be capable of quickly learning a framework
Well, not that I disagree with you that a lot of employers are being awfully ridiculous when it comes to Angular background requirements, but... you're in for a shock if you try to pick up Angular quickly. Angular is more than a framework - or rather, Angular is a framework that depends on a sprawling ecosystem of other dependencies, each with its own idiosyncrasies. It's not just that Angular is a huge, complex, vast, partly undocumented framework that changes almost completely every few months (Angular 1 and Angular 2 are completely incompatible), but Angular is also heavily dependent on node.js and npm which are themselves pretty complex and prone to break in odd ways that Googling error message doesn't normally help much with. And that's assuming that you don't want to do any sort of unit testing, because the Karma/Jasmine/Protractor frameworks are themselves prone to unexpected breakage and version incompatibilities. But you'd better plan on doing a lot of unit testing, because debugger support is nonexistent too. This is all assuming you have a VERY good handle on HTML, CSS, and Javascript - don't even dream about trying to make sense out of Angular if you're not already an expert on all of those (especially Javascript, even though Angular doesn't use Javascript directly any more). I've been coding now for 25 years, and the only things I've seen come along that were as loved by executives and as fragmented and hard to troubleshoot have been Corba, EJB and Ruby on Rails... so I'm inclined to wonder if any time spent learning Angular will actually be well spent in the long term.
Well, not that I disagree with you that a lot of employers are being awfully ridiculous when it comes to Angular background requirements, but... you're in for a shock if you try to pick up Angular quickly. Angular is more than a framework - or rather, Angular is a framework that depends on a sprawling ecosystem of other dependencies, each with its own idiosyncrasies. It's not just that Angular is a huge, complex, vast, partly undocumented framework that changes almost completely every few months (Angular 1 and Angular 2 are completely incompatible), but Angular is also heavily dependent on node.js and npm which are themselves pretty complex and prone to break in odd ways that Googling error message doesn't normally help much with. And that's assuming that you don't want to do any sort of unit testing, because the Karma/Jasmine/Protractor frameworks are themselves prone to unexpected breakage and version incompatibilities. But you'd better plan on doing a lot of unit testing, because debugger support is nonexistent too. This is all assuming you have a VERY good handle on HTML, CSS, and Javascript - don't even dream about trying to make sense out of Angular if you're not already an expert on all of those (especially Javascript, even though Angular doesn't use Javascript directly any more). I've been coding now for 25 years, and the only things I've seen come along that were as loved by executives and as fragmented and hard to troubleshoot have been Corba, EJB and Ruby on Rails... so I'm inclined to wonder if any time spent learning Angular will actually be well spent in the long term.
That's true, especially the testing part (ever seen chain of promises, a deferred object, and completely useless error stack trace?). Debugging? Source maps, transpilers, file watchers - impenetrable pulp. Why the community is so fixated on forcing the framework down the throat of developers? It certainly solves some problems, but these problems could probably be solved in a more comprehensible and simpler way. Angular it not the new cool thing - it's a complex thing with multiple versions, each incompatible with the others.
> I would assume that a competent web developer should be capable of quickly learning a framework.
I agree. And I got hired by a company who agrees, and who let me learn on the job. Not all hiring processes are as broken as one might believe solely by reading posts and discussions online. But it does take some effort to put out enough feelers to find those companies, because there are also a plethora of folks who hire for skill sets, not skill.
I agree. And I got hired by a company who agrees, and who let me learn on the job. Not all hiring processes are as broken as one might believe solely by reading posts and discussions online. But it does take some effort to put out enough feelers to find those companies, because there are also a plethora of folks who hire for skill sets, not skill.
I'm not sure I believe that "most often" employers want this. I did quite a few interviews last year, and I was freaked out because I didn't know any of the latest frameworks. I didn't even know Angular. But no one cared. As long as you understand the problem frameworks are trying to solve, then you're good.
And btw, I interviewed with some relatively big tech names - Squarespace, Blue Apron, etc.
Edit: most of them did list specific frameworks, but upon an actual interview, they revealed that they didn't really care if you had worked with it before as long as you understand basic MVC stuff.
And btw, I interviewed with some relatively big tech names - Squarespace, Blue Apron, etc.
Edit: most of them did list specific frameworks, but upon an actual interview, they revealed that they didn't really care if you had worked with it before as long as you understand basic MVC stuff.
Believe yourself being lucky or sheltered because over here it's "HOW MUCH OF EXPERIENCE DO YOU HAVE WITH ANGULAR WHICH VERSION OF IT WE ARE MIGRATING EVERYTHING TO REACT ALL FRONT END DEVELOPERS HAVE LEFT THE COMPANY WE ARE SENDING RIGHT NOW CODING CHALLENGE TO BE DONE IN RXJS!". Then rejection email regardless of solving the challenge or not. I think I'll start simply disconnecting on such calls.
Jesus, that's terrible. I do live in NYC, so my options are considerably greater than elsewhere. What a stupid set of requirements. Sorry you have to go through that.
Really makes me want to stay at my current job for as long as possible. I'm not interested in that bullshit.
Really makes me want to stay at my current job for as long as possible. I'm not interested in that bullshit.
You're applying to the wrong companies.
Right, they don't want to have to pay you to do the learning.
It's usually not "how to get a simple task done with React" – many engineers can get there very quickly – but rather having an understanding of best-practices in terms of architecting your application.
Angular, well, can take a while to learn how to use properly.
It's usually not "how to get a simple task done with React" – many engineers can get there very quickly – but rather having an understanding of best-practices in terms of architecting your application.
Angular, well, can take a while to learn how to use properly.
> It's usually not "how to get a simple task done with React" – many engineers can get there very quickly – but rather having an understanding of best-practices in terms of architecting your application.
Perhaps I'm being too pedantic here, but the UI library used has very little to do with how you architect an application. Knowing how to write half decent sql or not reinvent your own message queue is far more important than whatever is happening on the front end, but you don't see the focus on them like you do with the latest javascript library.
Perhaps I'm being too pedantic here, but the UI library used has very little to do with how you architect an application. Knowing how to write half decent sql or not reinvent your own message queue is far more important than whatever is happening on the front end, but you don't see the focus on them like you do with the latest javascript library.
The problem is that in the most of the Europe they dont’t pay market wages. Way below them. Certainly not enough to keep up to date with the the JS framework brainfuck.
Statistically, how can most of a market not pay market wages?
The entire market being low cost, or at the bottom of corporate outsourcing chain. Market rates == they have higher recruitment requirements than in developed markets where there are higher wages.
I'm still trying to parse that. If the market in question is paying low wages for the industry, that is the market rate. The entire market can't pay below market rate.
Are you sure that the rate is below market or are you just looking at the inflated rates of the west coast in the U.S.? I don't live on the west coast, I live in a major metropolitan area in the south, with good wages for developers (90-140K with experience) and even that would be considered below market compared to the west coast.
Are you sure that the rate is below market or are you just looking at the inflated rates of the west coast in the U.S.? I don't live on the west coast, I live in a major metropolitan area in the south, with good wages for developers (90-140K with experience) and even that would be considered below market compared to the west coast.
How about developing EU country with wages 25-35K? Doing project exclusively for German/British/American markets, where one would have to pay developers locally at least twice... and no, the life is not that much cheaper over here.
If they're offering such wages and getting candidates to work for such wages, then that's the (local) market wage, by definition. Pay of developers elsewhere and cost of life are not relevant, "market wages" is the salary level (in that particular market) where the job offers and willing candidates meet.
All your arguments state "the market wage here is low compared to other markets", not companies not offering market wages - "not offering market level wages" look like a large number of job postings that are not getting filled for a long term because candidates reject these jobs. However, if those job positions are getting filled at that rate (even if begrudgingly) then that's the market rate then and there.
All your arguments state "the market wage here is low compared to other markets", not companies not offering market wages - "not offering market level wages" look like a large number of job postings that are not getting filled for a long term because candidates reject these jobs. However, if those job positions are getting filled at that rate (even if begrudgingly) then that's the market rate then and there.
> If they're offering such wages and getting candidates to work for such wages, then that's the (local) market wage, by definition
Let me phrase it this way - it's very difficult to find software dev/eng older than 33-35 and the only career path for them is middle management (i.e. distributing tight budget over undemanding workforce). The employers notoriously complain for not being able to find "specialists".
Let me phrase it this way - it's very difficult to find software dev/eng older than 33-35 and the only career path for them is middle management (i.e. distributing tight budget over undemanding workforce). The employers notoriously complain for not being able to find "specialists".
That's only true if you're looking to work for one of the cool, hip, startups. There are plenty of older devs working in boring corporate jobs that are not interested in changing the world. I'm one of them.
That’s corporate jobs I’m talking about. We refactor and support that awful ASP.NET web app written hecticly 10 years ago by some hipsters, we develop products for markets which are not so profitable or prestigious. There are almost no cool hip startups and those existng are not worth attention because they pay peanuts and usually are just proxy for cheap labour. I think we are talking about completely different job markets.
As a US citizen, if I thought one state had lower wages than another state. I would just move to the state where the wages are better. Why can't a citizen of the EU do the same?
Yes, I chose to leave a small town with no real opportunities after graduating.
Yes, I chose to leave a small town with no real opportunities after graduating.
One can, but there is significant language and cultural barrier, one is paying awfully high social contributions while the person's family stays in a different country. Plus many in developed countries are prejudiced against employees from developing countries ("you have to agree for less, to put your foot in the door and learn our superior ways of doing things" kind of stuff).
Still trying to understand. You're a citizen of the EU as is your family. Why leave your family behind?
Not having been to Europe so I don't know, but if you speak English does that help make mobility easier?
Not having been to Europe so I don't know, but if you speak English does that help make mobility easier?
Family might not be willing to suddenly be surrounded by completely different language? By completely different legal, administrative, and educational environment? Oftentimes, all these not exactly welcoming to their particular origin/ethnicity (e.g. who is considered an expat and who an immigrant). The chances of a 45-65 year old family member finding a job in new place is basically nil, from social and pensions systems they will receive only humiliation. Also, soon English will barely even be among official languages of the EU.
What's your point exactly ? That we can't all get Switzerland salaries even when living in remote areas where the cost of life is way lower, all this while being unwilling to move to cash out for a few years ?
BTW, they may be referring to what, for Americans, is 'extended family' ; that is, not your spouse and kids, but your brothers, parents, uncles etc :)
It is great to have your whole family around; they will probably not move with you :)
It is great to have your whole family around; they will probably not move with you :)
Again, so what? My responsible is to myself, my spouse, and my kids. I'm going to move to wherever I can get the better quality of life for us is.
If I have dependent relatives like parents, they would have to move where I move.
EDIT:
Thanks for the possible clarification. I'm thinking very US centric. I forgot that many other cultures seem to place a higher value on being close to and living with extended family than we do.
If I have dependent relatives like parents, they would have to move where I move.
EDIT:
Thanks for the possible clarification. I'm thinking very US centric. I forgot that many other cultures seem to place a higher value on being close to and living with extended family than we do.
90-140K
And even that is at least 50% higher than the pre-tax wages of a good developer in Sweden.
And even that is at least 50% higher than the pre-tax wages of a good developer in Sweden.
It's all relative. 100K where I live affords you a nice house, in a decent area of town with good school systems. $170K household income (one developer salary and one person doing basically anything) allows you to easily afford a home in one of the top 25 most affluent counties in the U.S. with plenty of wiggle room in your budget. Our lifestyle wouldn't be the same in the Bay Area.
Also, from what I understand, Sweden has a lot of benefits that we have to pay for in the US (healthcare, post secondary education, paid parental leave, etc.)
Also, from what I understand, Sweden has a lot of benefits that we have to pay for in the US (healthcare, post secondary education, paid parental leave, etc.)
Still too much, that's why you nearshore to Czechia, Poland, and Romania.
Ukraine seems to be the new go to place in my experience
Ukrainians flee like crazy to Czechia, Poland, and Germany. The rates offered in Ukraine are literally a spat in the face, also the country offers almost no social security. It's a sad and dark place to create the software in - corporations love it.
> It's usually not "how to get a simple task done with React" – many engineers can get there very quickly – but rather having an understanding of best-practices in terms of architecting your application.
Find me a Web Developer than can perform a sysadmin role on production sites, building out a CRM integration on some bizarre platform with its own programming language, work on improving an ERP, and the integration between them. Oh, and you also need to know React and some standard MVC stack like RoR.
No?
---
Now, you might think that is a joke or absurd. It is not. It is also as relevant an expectation as asking if they know React.
Your point of view screams silo'd front end developer.
Find me a Web Developer than can perform a sysadmin role on production sites, building out a CRM integration on some bizarre platform with its own programming language, work on improving an ERP, and the integration between them. Oh, and you also need to know React and some standard MVC stack like RoR.
No?
---
Now, you might think that is a joke or absurd. It is not. It is also as relevant an expectation as asking if they know React.
Your point of view screams silo'd front end developer.
If any large-ish company hired such a candidate, it would still likely use them in a pure front end development role, because administration of production sites would be handled by dedicated people (sometimes by necessity - e.g. PCI DSS and other security standards like to ensure a strong separation between development and production teams); CRM/ERP would be handled in a different team, etc.
Specialization is a thing, if your team isn't tiny, you'll have different functions handled by different people.
Specialization is a thing, if your team isn't tiny, you'll have different functions handled by different people.
People keep telling me that but I've worked in S&P 500 companies, startups, etc.
Somehow, somehow it never seems to be true if you are doing anything close to "architecting" anything.
Somehow, somehow it never seems to be true if you are doing anything close to "architecting" anything.
I can do all that, but no one would want to pay what I'd charge for all that.
Once you learn one front-end framework, you're halfway there to learning any of them.
There's a lot of shared ideas and concepts among the most popular choices. So it's much faster for, say, an Angular Dev to get productive with Vue.js than it would with a vanilla JS developer doing the same thing.
There's a lot of shared ideas and concepts among the most popular choices. So it's much faster for, say, an Angular Dev to get productive with Vue.js than it would with a vanilla JS developer doing the same thing.
It's an example of how brain-dead the hiring process is for tech in general. Most of the jobs I've worked in my entire career have involved working with languages, not just frameworks, that I didn't know beforehand. I learned all of them and became good at them on the job. If you have a good grounding in programming fundamentals and you are reasonably productive then it's pretty easy to pick up any language in a short amount of time, especially now.
I think part of this is that there is this common delusion that tech workers in hot fields (like silicon valley startups) have to all be rockstars or have to all have some exceptional level of expertise. And having those people on board is how you crank out software better and faster. The reality is that someone who coincidentally happens to have experience with whatever your current technology stack is may not have the highest level of overall expertise or talent that you truly need.
I think part of this is that there is this common delusion that tech workers in hot fields (like silicon valley startups) have to all be rockstars or have to all have some exceptional level of expertise. And having those people on board is how you crank out software better and faster. The reality is that someone who coincidentally happens to have experience with whatever your current technology stack is may not have the highest level of overall expertise or talent that you truly need.
Yes, I got given a "full stack" test. Entirely in JavaScript. No database element. Required to use React. Screw that, its going to take me a couple of days to get up to speed in a framework that I don't know, and I likely won't make a good job of my first attempt.
> And new generations are opting for YouTube to self-teach over books
I'm definitely in the older generation because it's completely mind-boggling to me how someone effectively learns to code from watching a video tutorial. You can't flip back to a page, bookmark a link, copy text, zoom-in to see exactly what was done, etc. It feels like you're inherently missing out on so much you gain from a book or a text-filled website. MOOCs generally have a great UI/UX intermingling video, text content, and usually a REPL of some sort... but YouTube videos?
Is this a huge flaw in my learning ability or is there some secret to effectively learning these sort of skills via video?
I'm definitely in the older generation because it's completely mind-boggling to me how someone effectively learns to code from watching a video tutorial. You can't flip back to a page, bookmark a link, copy text, zoom-in to see exactly what was done, etc. It feels like you're inherently missing out on so much you gain from a book or a text-filled website. MOOCs generally have a great UI/UX intermingling video, text content, and usually a REPL of some sort... but YouTube videos?
Is this a huge flaw in my learning ability or is there some secret to effectively learning these sort of skills via video?
I don’t think it’s either-or. I find video tutorials incredibly helpful. I’m a fan of SafariBooksOnline where you get full texts and hours-long professional videos.
If you're the older generation, then so am I, and I'm not even 30. Video is garbage, for me, and I really wish people would just write up their materials, because they are essentially useless to me in that format.
Don't get me started about searching for how to configure/troubleshoot a piece of software and the best answer lives inside a 60-second video.
Webdriver.io literally has gifs of themselves typing in the terminal as documentation. Wtf.
Video to me is just to give you a rough orientation and a small amount of depth on a broad set of ideas.
after i watch a talk about new features in [insert language] sometime later i'll be writing something and remember that feature, and off to google or github i'll go to find how exactly to imeplement it or the specific syntax.
after i watch a talk about new features in [insert language] sometime later i'll be writing something and remember that feature, and off to google or github i'll go to find how exactly to imeplement it or the specific syntax.
Horses for courses. Video tutorials are great for things where you have to find some obscure menu item, or otherwise perform a non-obvious "secret GUI handshake" to access a feature or perform a task. For learning to how to actually write code, they're awful, for all of the reasons you mention.
[deleted]
That's what documentation and github repos are for. Video is for the discussion section.
And you can seek to any point in a video you like. The best videos are organized as playlists of chapters, and/or contain a table of contents with links to that time in the video.
And you can seek to any point in a video you like. The best videos are organized as playlists of chapters, and/or contain a table of contents with links to that time in the video.
There are lots of secrets you can pick up watching videos. Books glaze over some details like IDE choices and how to set up dev environments, but you get to see all that watching someone code from scratch
Don’t knock it until you try it. I’ve learned a great ton from YouTube videos or just watching the videos in sequence on Frontend Masters. Watching them at an increased speed let’s me cover a lot of ground very quickly. I also like writing down headers of important topics, and then going back and doing research on those topics and essentially trying to write a brief book in my own words on everything. Helps me get a deeper understanding, ensure I’m actually learning stuff, and be able to come back to things for reference. See: https://baron816.gitbooks.io/good-stuff-to-know/content/
> Don’t knock it until you try it.
I've tried it, and found video quite good for conveying emotional content, general high-level overviews, and general feeling of comfort with the shape of a topic, but quite bad at detailed technical information.
That's not saying that they aren't useful: I find videos that provide overview of material provided in detail in a textual medium to be quite useful. But if I had to do one or the other alone for learning technical material, it would be textual media over video 100% of the time.
I've tried it, and found video quite good for conveying emotional content, general high-level overviews, and general feeling of comfort with the shape of a topic, but quite bad at detailed technical information.
That's not saying that they aren't useful: I find videos that provide overview of material provided in detail in a textual medium to be quite useful. But if I had to do one or the other alone for learning technical material, it would be textual media over video 100% of the time.
Not only that, but when the speaker starts going over "fluff" (or stuff you already know), it's easy to pull up a spare article or resource in another browser and multitask until we're back on track.
I'm not sure it's generational. I've always encountered developers who prefer to learn from people rather than words. I think the difference here is that now that YouTube has come along these developers are catered to more, so the people who prefer to learn this way have a better choice.
I don't really see any advantage to video over text / rich documents for learning development topics, and I see several downsides. But perhaps I'm biased, because I'm like you and very strongly prefer words.
I expect improvements to the technology will help alleviate some of the downsides to video in the long run as well. Are there any video platforms widely used for developers that let you do a full-text search over the transcript for code and then jump to a point from a list of results? Because that at the very least is a dealbreaker for me.
I don't really see any advantage to video over text / rich documents for learning development topics, and I see several downsides. But perhaps I'm biased, because I'm like you and very strongly prefer words.
I expect improvements to the technology will help alleviate some of the downsides to video in the long run as well. Are there any video platforms widely used for developers that let you do a full-text search over the transcript for code and then jump to a point from a list of results? Because that at the very least is a dealbreaker for me.
Many of us learned in classrooms. At the end of the day you have to sit down at a keyboard and try things. How your filing your head before that I think comes down to the learning styles you’re comfortable with.
You just need to know about these keys on Youtube:
Pressing ">" speeds up the video, "<" - slows it down.
"f" - toggles fullscreen, "c" - captions.
You can be very fast reader, but you can't keep up with me when I'm watching videos in 2x.
Videos (and talks for that matter) are good a giving a quick over and showing you what is possible (i.e. getting you into a position where you know what you don't know). Books are good ways to dive deep into things you already know you want to learn.
Videos are dynamic. They are the closest medium currently we can get to pretending we're inside the presenter's head in real time (I'm thinking of khan-academy style videos). To experience how an expert solves a problem and the steps they go though is great and is hard to convey though a book (you would essentially need a flip-book or multi-step diagrams that get very big very fast and it's also hard to convey the temporal aspect of the process that's being explained).
What's missing on the "core competency" is communication. Honestly, communication and ability to turn a communicated idea into code is more important than problem solving ability. If someone is solving the wrong problems, they're not creating value. Whereas if someone is stuck on a problem, we can fix that by talking about it - as long as the discussed solution can be turned into code.
Communication is such a nuanced thing. In our core senior group there is one guy who refuses to let us talk about anything remotely resembling an implementation-related detail if we're early in the high-level design stage, and it honestly shuts conversation down. I get his point, however at the same time a group of good engineers should be able to briefly and abstractly discuss the potential downfalls of a design decision while considering an implementation detail (say, using columnar storage to address some high-level requirement).
Then, there's folks who communicate "well" in standups, meetings, design discussions, are cogenial, etc. At the same time they might be drowning in some technical debt they've taken on and no one understands it until they're 2 weeks overdue on a deliverable.
Then, there's folks who communicate "well" in standups, meetings, design discussions, are cogenial, etc. At the same time they might be drowning in some technical debt they've taken on and no one understands it until they're 2 weeks overdue on a deliverable.
I was wondering why some of the languages listed as being popular in the graph by employers seemed so out in left field with my understanding of the market, then I read this part:
A total of 39,441 professional and student developers completed the online survey from October 16 to November 1, 2017. The survey was hosted by SurveyMonkey and HackerRank recruited respondents via email from their community of 3.2 million members and through social media sites.
It's a self selected sample and probably skews a lot toward what the "cool kids" are doing and not what most corporations are actually doing. There is no conceivable way that Lua, Kotlin, and Go should be more highly represented than Swift/Objective C and C#
A total of 39,441 professional and student developers completed the online survey from October 16 to November 1, 2017. The survey was hosted by SurveyMonkey and HackerRank recruited respondents via email from their community of 3.2 million members and through social media sites.
It's a self selected sample and probably skews a lot toward what the "cool kids" are doing and not what most corporations are actually doing. There is no conceivable way that Lua, Kotlin, and Go should be more highly represented than Swift/Objective C and C#
The graphs about languages seem very weird. Let's take a look at the "Which languages do developers prefer by age?":
Python: 84.6%
C: 54.0%
C++: 48.2%
Java: 48.2%
JavaScript: 47.6%
...
Ruby: 21.0%
Why is Python so far ahead of everything else? Why is Ruby, which is all about programmer happiness so far down?
It seems people actually like JavaScript. Wait, people do actually like C++?!?
Also if you take a look at Go by age, for example, it goes from 53.6% (35-44) up to 67.8% (45-54) and back down to 7.6% (55+). I don't see a reason for such a huge preference variation. There's also a few 0.0% with 55+ years.
It seems there weren't enough answers for this to be anywhere near conclusive.
Python: 84.6%
C: 54.0%
C++: 48.2%
Java: 48.2%
JavaScript: 47.6%
...
Ruby: 21.0%
Why is Python so far ahead of everything else? Why is Ruby, which is all about programmer happiness so far down?
It seems people actually like JavaScript. Wait, people do actually like C++?!?
Also if you take a look at Go by age, for example, it goes from 53.6% (35-44) up to 67.8% (45-54) and back down to 7.6% (55+). I don't see a reason for such a huge preference variation. There's also a few 0.0% with 55+ years.
It seems there weren't enough answers for this to be anywhere near conclusive.
You're almost certainly right that their sample sizes are too small, especially in the upper age brackets. I suspect it's hard to find a lot of 55+ year old programmers who are willing to do silly things like take a HackerRank poll. Given the industry stats, it's fairly hard to find 55+ year old programmers, period.
> people actually like JavaScript. Wait, people do actually like C++?!?
Yep to both. I actually don't mind the latest versions of JavaScript. I don't like C++ at all, but have done professional work in it alongside people who thought it was a great language.
> Why is Ruby, which is all about programmer happiness so far down?
Programmer happiness is subjective (as evidenced by my previous remark and by the love/hate you see expressed for JavaScript, Go, Clojure, etc). Personally, I'm not a Ruby fan. I don't like the syntax. I vastly prefer composable functions to Ruby's "blocks". I find that most Ruby code I've worked with is too heavy on OOP abstractions and would be much clearer if expressed functionally. I could go on, but the point is, it's subjective.
> people actually like JavaScript. Wait, people do actually like C++?!?
Yep to both. I actually don't mind the latest versions of JavaScript. I don't like C++ at all, but have done professional work in it alongside people who thought it was a great language.
> Why is Ruby, which is all about programmer happiness so far down?
Programmer happiness is subjective (as evidenced by my previous remark and by the love/hate you see expressed for JavaScript, Go, Clojure, etc). Personally, I'm not a Ruby fan. I don't like the syntax. I vastly prefer composable functions to Ruby's "blocks". I find that most Ruby code I've worked with is too heavy on OOP abstractions and would be much clearer if expressed functionally. I could go on, but the point is, it's subjective.
I also had issues with this graph. Reading the top, it's the percent approval of that language minus the percent disapproval of that language within that age group. Then, it's split on age group with the tabs up top.
Look at how rust changes when you select age. The younger people are the more they dislike it, and it even goes negative at the lowest bracket (and in total)
> It's a self selected sample
Yeah, the majority of the people I know who use HackerRank are college-aged looking for jobs. It's hard to place any confidence in this study.
Yeah, the majority of the people I know who use HackerRank are college-aged looking for jobs. It's hard to place any confidence in this study.
Dear hackerrank:
You can do scrollto or lazy load. You cannot do both.
The table of contents is essentially nonfunctional on mobile.
You can do scrollto or lazy load. You cannot do both.
The table of contents is essentially nonfunctional on mobile.
There’s no way that many people use VIM.
The ones who use hacker rank do. All the other people don’t bother using a site like that they are just living their lives playing baseball and other things outside of the job
That one stat made me question the entire survey. There's no way so many people use VIM over Atom, Sublime, etc. Right? Someone reassure me here.
I've recently been having issues with Sublime randomly freezing and restarting (may be due to a package, but I'm not going to waste my time verifying what packages are misbehaving out of the hundreds I have installed), I've gone back to Vim.
After setting Vim up for multiple environments (PHP, Go, Python, and JavaScript) it's now my daily driver. Maybe other people feel similar?
After setting Vim up for multiple environments (PHP, Go, Python, and JavaScript) it's now my daily driver. Maybe other people feel similar?
> may be due to a package, but I'm not going to waste my time verifying what packages are misbehaving out of the hundreds I have installed
Welcome to vim, but if you go overboard on plugins then you will have the same issues with it, probably more so.
Welcome to vim, but if you go overboard on plugins then you will have the same issues with it, probably more so.
I'm finding with Vim that less is more, or maybe as I become more experience I'm not relying so much on the GUI aspect of text editors (creating new files, git integration, color pickers, etc) but instead just sticking to the command line for a variety of operations.
Among the hundreds of professional programmers I've seen, talked to and worked with, in Europe at least, Eclipse (Java), Visual Studio (.Net), Sublime/Visual Studio Code/Atom/Notepad++ (web folks), IntelliJ are far and away ahead of all other editors.
I'm one of the relatively rare birds to also use Vim.
I'm one of the relatively rare birds to also use Vim.
You're probably right, I'm the sole full-time vim user at my place of work (primarily a python shop). I was vindicated in my choice yesterday when somebody forgot to pay off the credit card and the jetbrains license payment bounced, so nobody could work because their pycharm locked them out. I get why people love pycharm though, it does a good job, but I always felt like it was such a pig. Plus you can write some hairy code because the IDE will just let you prance through it without a care in the world.
Its a VIM vs Emacs question, all the other answers are in the (other) category. Considering that, the results make sense.
I use both Visual Studio Code and Visual Studio with VIM keybindings. Does that count?
Same here. This does not match up with other similar surveys. Also, apparently my opinions line up with that of a 55yo programmer...I'm 28. They must have sampled an older crowd that all use Vim and happen to like JavaScript more than most.
Hold up. They asked “Vim or Emacs?”, not “What’s your favorite editor?” That’s why the answer distribution looks like that. I think we all know there are more normal text editor/IDE users than vi/emacs users.
I think there's a problem with their data or their analysis. Vim is probably very well known and held with affection for a lot of developers whereas IDEs are far more subjective and occasionally hated.
There's also a fundamental problem of expectations. Vim is miraculous as far as terminal-based text editors are concerned. You can be amazing productive without a mouse. I can do 100X more and do it all faster with IntelliJ Ultimate but since I paid a wad for it, all I can see are the flaws.
There's also a fundamental problem of expectations. Vim is miraculous as far as terminal-based text editors are concerned. You can be amazing productive without a mouse. I can do 100X more and do it all faster with IntelliJ Ultimate but since I paid a wad for it, all I can see are the flaws.
Go on a random terminal and fire up emacs. It isn't there. Also, your favorite editor isn't there. That's why. The practical choice is Vim vs. Nano or Joe or Ed or whatever.
There are dozens of us.
One Vim to rule them all, One Vim to find them,
One Vim to bring them all and in the darkness bind them
I am proudly one of those dozens.
Mostly I use IntelliJ, but when I’m futzing on the commmand line I end up in vim. Couldn’t resist the joke.
My machine org professor plans on teaching it this semester because employers in the area are preferring it. I was surprised by how many people knew it already.
I use it all the time when I ssh into prod/staging/test...
People use Stack Overflow to learn how to code? How? I use SO to learn how to do very specific things if I can't figure it out myself, but to learn how to code?
Lot of new questions are about basic stuff explained in the official documentations. I answered a bunch of questions yesterday about React and Babel setups: I just had to pick the answers in the first pages of the docs.
The site is actually readable if you turn off that awful css. Who thought removing white space from the titles and adding an obnoxious faux cursor were a good idea?
Most/all of the charts gain absolutely nothing from the interactive features either, a grouped histogram style chart could show the same information in a static image. It would be better actually, you could compare the groups side by side instead of relying on animations and hovering back and forth.
Most/all of the charts gain absolutely nothing from the interactive features either, a grouped histogram style chart could show the same information in a static image. It would be better actually, you could compare the groups side by side instead of relying on animations and hovering back and forth.
I agree. On my relatively high speed internet connection on Chrome 63 (latest) running on a recent laptop, it took 55 seconds, 426 requests, and 2.6MB to load the first graph on the page. Sure, a lot of the loaded assets are in my cache for subsequent visits, but that initial load time is just...wow.
The content of those 426 requests weren't created for free. Part of the "high demand" developer skills I suppose. Adding gunk to the point you can't get the content. I'd guess sooner rather than later the pendulum is going to swing back to simplicity. Then having good sense about how to effectively portray something without tormenting everyone and wasting resources will be in high demand. As it always should have been.
> Execs place the highest value on GitHub and personal projects
Well, good luck with industries that are 99% closed source (like gamedev). I have a few toy projects in my Github, but I bet it's nothing compared to any front-end developer who has the luxury of submitting PRs to the tools and framework he uses.
Well, good luck with industries that are 99% closed source (like gamedev). I have a few toy projects in my Github, but I bet it's nothing compared to any front-end developer who has the luxury of submitting PRs to the tools and framework he uses.
Yeah, are the answers from these "execs" biased by a certain industry or location? Literally nobody has ever brought up my Github projects or PRs...
Being an Emacs enthusiast myself, it always surprises me how much more popular VIM is. Is this because VIM is taught more in schools? Maybe because VI/VIM is typically installed by default on Linux systems?
It's tiny and ubiquitous. Even tiny VMs and embedded devices have Vim.
Despite this, in my experience, Emacs provides a more feature rich environment, comparable to an IDE, rather than only a text editor.
It’s not about features. Vim is meant to be custom tuned through plugins until it meets your needs, after which no other editor will satisfy you.
I hope you're not trying to explain the value and satisfaction of customization to an Emacs enthusiast!
The thing is an interpreter for Elisp, which the text editor is written and configured in. You can change the core functionality of the editor if you wanted, by writing some code in a buffer and pressing C-M-x. You can make it act exactly like vim if you wanted to. You can add line numbers on the side, better autocomplete for commands and searches, a git porcelain, new modes for different types of files. You can implement an IRC client, a browser, tetris, a file browser, or an email client; or you can just use the implementations that come included.
You can spend a lifetime configuring Emacs, and if you have attained the ultimate configuration, you'll look back at the end of your life and realize that it was worth the thousands of hours you put into it. But if you have not, don't worry: you'll be reborn into the cycle constant suffering-due-to-inferior-configuration until you figure it out.
The thing is an interpreter for Elisp, which the text editor is written and configured in. You can change the core functionality of the editor if you wanted, by writing some code in a buffer and pressing C-M-x. You can make it act exactly like vim if you wanted to. You can add line numbers on the side, better autocomplete for commands and searches, a git porcelain, new modes for different types of files. You can implement an IRC client, a browser, tetris, a file browser, or an email client; or you can just use the implementations that come included.
You can spend a lifetime configuring Emacs, and if you have attained the ultimate configuration, you'll look back at the end of your life and realize that it was worth the thousands of hours you put into it. But if you have not, don't worry: you'll be reborn into the cycle constant suffering-due-to-inferior-configuration until you figure it out.
> You can make it act exactly like vim if you wanted to
Thanks to Spacemacs, Emacs is already better Vim than Vim itself. I know what I'm talking about. I'm a die-hard vimmer.
Thanks to Spacemacs, Emacs is already better Vim than Vim itself. I know what I'm talking about. I'm a die-hard vimmer.
The same can be said for Emacs with all the various packages and any elisp you write.
Is it? I run a mostly stock .vimrc and no editor will satisfy me.
Not everyone wants an IDE, though. Unix is my IDE, and Vim is just my text editor. I learned emacs first and left it for Vim.
This is fair. For someone that just wants to edit text in an efficient way and doesn't want to tweak/tailor their editor
vanilla vim is a good choice.
I'll take nano and previously pico over vim
Emacs has a reputation for being big and scary, and more effective if one knows Lisp (which is also scary).
Also, the feeling that one's keyboard ought to have 'meta' and 'super' keys.
Also, the feeling that one's keyboard ought to have 'meta' and 'super' keys.
The default modal keybindings are fantastic for editing text, once you start learning them it becomes addictive. Once you've learned most of them everything else feels annoyingly clunky.
I sometimes use IntelliJ and sublime but if I'm sshing around our network or editing random configs vim is the one that jumps to hand, and it's pretty much my default for everything now. Vim modes in those two IDEs are also pretty good.
EDIT: vimscript kind of sucks though, Emacs is way better on that front
I sometimes use IntelliJ and sublime but if I'm sshing around our network or editing random configs vim is the one that jumps to hand, and it's pretty much my default for everything now. Vim modes in those two IDEs are also pretty good.
EDIT: vimscript kind of sucks though, Emacs is way better on that front
The biggest game-changer for me in converting/sticking with emacs was finding out I can edit remote files with my local emacs via TRAMP (https://www.emacswiki.org/emacs/TrampMode). No more logging into remote machines and installing a sub-standard subset of my highly customized editor configuration.
And before you say it, yes I know you can edit remote files with vim too. But with emacs/TRAMP it's dead simple.
And before you say it, yes I know you can edit remote files with vim too. But with emacs/TRAMP it's dead simple.
I’ve heard quite a few people complain that Emacs caused them RSIs. That’s why I stopped using it too. Vim is much easier on the hands in that regard.
One word - spacemacs.
It's emacs with vim bindings. You get all the editing goodness of vim with the extensibility of emacs.
Spacemacs has won the editors war.
It's emacs with vim bindings. You get all the editing goodness of vim with the extensibility of emacs.
Spacemacs has won the editors war.
[deleted]
Sidenote : The background images are '3D' fractals, I remember reading about in HN itself a few years back. There was a fascinating article about a programmer writing about the steps he went through to get a 3D fractal.
I'd love to get my hands on that article/link, do you have it handy?
---
Found this free software for 3D fractals: http://www.mandelbulber.com/
---
Found this free software for 3D fractals: http://www.mandelbulber.com/
http://www.skytopia.com/project/fractal/2mandelbulb.html
This is the closest reference I could google.
The article I am talking about had the author explain the various steps he went through, starting with rotating a 2d fractal, and move up the process to finally get the math equations to generate a truly 3d fractal.
This is the closest reference I could google.
The article I am talking about had the author explain the various steps he went through, starting with rotating a 2d fractal, and move up the process to finally get the math equations to generate a truly 3d fractal.
https://hn.algolia.com/?query=3d%20fractal -> https://news.ycombinator.com/item?id=935241 (Nov 2009)
But unless you read HN for 5+ years without creating an account, the exact discussion you recall may be some other search result there.
>mrob: the Wikipedia page is a better starting point: https://en.wikipedia.org/wiki/Mandelbulb
PS. Algolia seems a bit finicky, a couple of these were on the second page of results for the first search: https://hn.algolia.com/?query=3d%20fractal%20comments%3E0&so.... I always hate how they show different results for plurals, but this is a new problem I'll keep in mind (sort by popularity doesn't work?).
But unless you read HN for 5+ years without creating an account, the exact discussion you recall may be some other search result there.
>mrob: the Wikipedia page is a better starting point: https://en.wikipedia.org/wiki/Mandelbulb
PS. Algolia seems a bit finicky, a couple of these were on the second page of results for the first search: https://hn.algolia.com/?query=3d%20fractal%20comments%3E0&so.... I always hate how they show different results for plurals, but this is a new problem I'll keep in mind (sort by popularity doesn't work?).
The article was very very similar to this.
https://christopherolah.wordpress.com/2011/08/08/the-real-3d...
https://christopherolah.wordpress.com/2011/08/08/the-real-3d...
Oh yeah. I lurked a lot. But that is not the site. The site was by a developer complete with code extracts.
> Coding helps enrich your computational thinking, which is powerful in making decisions.
That is backwards. Computational thinking is fundamental to learning to code, and also aids in many other aspects of both learning and performing in any path you may choose. Learning the fundamentals of computational thought is the core skill that everyone will need in the future.
That is backwards. Computational thinking is fundamental to learning to code, and also aids in many other aspects of both learning and performing in any path you may choose. Learning the fundamentals of computational thought is the core skill that everyone will need in the future.
I feel like the wording misrepresents the results in the "In Demand Qualifications" section.
> There's a popular belief that recruiters favor candidates with CS degrees from prestigious universities. But it turns out that they actually care about what you've done — not where you went to school
But over 40% employers say that they care about your educational qualification. It doesn't' make sense to say "they actually care about what you've done - not where you went to school" with this result. If you don't have a college degree in CS, you're going to have a significantly tougher time getting your foot in the door, so therefore, even if it's not the MOST important credential you need to get a job, it's unfortunately still very important as a pre-requisite. We still don't have a good signal for that kind of preparation if the candidate doesn't have a lot of publically viewable work.
> There's a popular belief that recruiters favor candidates with CS degrees from prestigious universities. But it turns out that they actually care about what you've done — not where you went to school
But over 40% employers say that they care about your educational qualification. It doesn't' make sense to say "they actually care about what you've done - not where you went to school" with this result. If you don't have a college degree in CS, you're going to have a significantly tougher time getting your foot in the door, so therefore, even if it's not the MOST important credential you need to get a job, it's unfortunately still very important as a pre-requisite. We still don't have a good signal for that kind of preparation if the candidate doesn't have a lot of publically viewable work.
Interesting - older developers like Swift a lot. There is a resurgence of C++ among younger developers.
I don't know how or to what extent it's organized, but I've noticed a considerable effort promoting C++ per se (not scoped to a particular dialect/platform/product) in the past ~5 years. Outlets like isocpp.org and CppCon seem to have done a lot to raise the profile of the language.
>>There is a resurgence of C++ among younger developers.
C++ is the only tool of choice for the time limitations online judges like hackerrank have. So most people submitting code there are basically writing it in C++. Also most people using C++ there are using a very minimal subset of C++, which would largely look like C with things like vectors<int> etc.
That doesn't say anything about production uses of such languages.
C++ is the only tool of choice for the time limitations online judges like hackerrank have. So most people submitting code there are basically writing it in C++. Also most people using C++ there are using a very minimal subset of C++, which would largely look like C with things like vectors<int> etc.
That doesn't say anything about production uses of such languages.
Yeah. I suspect you're right. When I've done HackerRank, I've done it in Clojure, but the handful of times that was too slow (due to boot speed, I think), I solved the problems in Go.
Too bad they don't differentiate between AngularJS and Angular (2+), which are totally different frameworks. Would be interesting to compare Angular and React.
Wow I'm surprised by students really putting compensation down on the list of things that are important to them compared to professionals.
Is there any way to find out what hackerrank is without signing up first?
Crappy "coding challenge" site with plenty of reason not to use it in your hiring process, but that's what they are selling it to employers for.
Whats with Julia ? why so much hate among almost all ages ?
"Hard to assess skills before onsite" -- That's funny, I've never had a hiring manager or interviewer look at my literal hundreds of thousands of lines of code on GitHub or several of the OSS projects I've contributed to.
Not to mention the actual book I co-wrote.