Posts tagged "technical recruiting"

GitHub

Do You Have To Be Active on GitHub to Get a Software Developer Job?

April 18, 2019 Posted by Recruiting 0 thoughts on “Do You Have To Be Active on GitHub to Get a Software Developer Job?”

Most blogs that teach you how to get a software development job will stress having a few projects available on GitHub, but do you absolutely need a GitHub account? This question isn’t as clear cut as it seems because technical recruiters value different things in a candidate. Some recruiters who only hire senior talent would probably focus on work history and white boarding performance. Others who have openings for junior devs may need more measurements that can adequately gauge the “readiness” of a candidate. In that case, having multiple repositories ready for inspection can make a junior candidate stand out among the crowd. On the other hand, a PhD in Computer Science and relevant research papers may make a GitHub account unnecessary to other recruiters.

TL:DR: A GitHub account isn’t necessary, but it’s a conversation starter. The game of interviews is a sort of Game of Thrones. You’re battling it out with other candidates vying for a single position. Being able to show a recruiter that you can write clean code and work with others can only be a bonus. That’s assuming that your GitHub account features polished projects and worthwhile contributions.

I often find answers like the one above unsatisfactory because it distills a range of opinions into a boilerplate answer. Though the answer may be satisfactory, I also like hearing from actual people involved in the recruiting process to see what they actually think. Here’s a conversation from Dev.to that I’ve culled to provide you a range of opinions.

 

Evan Oman

If a candidate is active on Github I like to check their profile to get a sense of what they are interested in and what their code looks like.

If a candidate is not active I don’t hold it against them, I just ask different questions.

 

Aleksei Matiushkin

I believe nobody makes a decision on the candidate based on GH profile only. But if Jean has one and John has none, it tells me that probably Jean’s more engaged in development in general and in open source in particular.

I like to work with people who love what they are doing.

Also, GH profile completely covers the write-code/whiteboard part of the interview. If the candidate loves to do whiteboard—fine, let’s do whiteboard

 

Kris Siegel

I like doing this but not as a requirement. Basically, if you have a project on GitHub, I can bring it up at your interview and ask you things like:

  • Why did you go with this arcitecture? Did it end up being ideal and could you have done it another way?
  • This code looks really interesting, can you explain it to me?

Especially when I interview senior developers it’s helpful to know how well they can explain a concept to a stranger as that’s a big part of their job.

But a GitHub account is never a requirement. It simply helps steer the interview.

 

Jaime Rios

Here is my personal opinion about why I’d appreciate some GitHub account and why I value organizations that do.

  1. A public repo shows initiative. Either you took the initiative to learn something or you built something and have the courage to share it. In the end, you did more than what is expected of you.
  2. Open source enriches us all. Think of Linux and the millions of servers deployed thanks to it.
  3. It shows initiative. It is a special kind of action. Most people only react to change. But to initiate it, is quite different.

Any organization that cares enough to take a look at my profile instead of the average white board test is the kind of people I’d like to collaborate with.

 

Bryan Swagerty

Personally if I’m looking at a resume, I won’t discount people with non-super-active github profiles, but ones with it stand out.

 

Joseph Michael Casey

A well documented public portfolio is a much stronger representation of what a candidate can contribute than anything else because it is literally the closest thing you can get to the employee working for you. A public portfolio with contributions to OSS and personal projects shows so much more value than a 2 – 3 hour interview ever can.

The current interviewing process for software engineers heavily favors code golfers, and this attitude leads to an industry where startups, after the release of Pokemon Go, chase AR for investment dollars on unused product functionality. It results in tech giants that say things like ‘Move Fast and Break Things’. An employer who values a GitHub portfolio looks like an employer who wants engineers deeply involved in their community that can also provide real world value.

 

Carley Ho

I know we don’t really look at them that much unless the candidate specifically pointed to it for samples of their work. Sometimes I’ll check and see if they have any cool stuff up there if they link it on their resume or portfolio site, but it’s extremely non-required. (Esp since, if you work for a private company that uses source control, most of your interesting work is going to be in private repos anyway, haha.)

 

Alistair McDonald

GitHub can be really useful to get a sense of what someone is learning, what tech they have used, to see their code-style, etc. It can be a good talking point, E.g: What made you choose this framework? Why did you architect things this way?

Having a good GitHub profile is just one aspect of a candidate’s ability, but it can be an important one.

I am usually involved in front-end/cross-functional candidate interviews. It depends what role you’re hiring for, but as an example: if an engineer has been working in the front-end for 10+ years and can’t walk me through a single code example from their GitHub profile, then that same information has to be teased out in other ways.

If you are going to interview for a job as a software engineer, it’s reasonable for your prospective employer to want to see an example of your work. Candidates that can show lines of code they have written and demonstrate a good understanding of what they did, will obviously do better than candidates that show nothing.

 

Anthony Bouvier

I do check.

But I don’t rely on it.

It is just another conversation starter for me. It shows me what they might be tinkering with, where their non-work interests lie in the tech realm, what they might be studying.

I don’t code review them or pick a part their pull requests to things. I don’t use it to stalk them and see code quality.

Just one more thing to have in a conversational interview (so I can skip stupid things like whiteboard coding).

 

Jake Varness

I just like seeing everything that people are working on nowadays. I think it’s fun to see what people work on in their spare time!

I don’t use it to make hiring decisions though. I like hearing about side projects and how people have worked effectively with a team in the past.

 

Ben Sinclair

When I’ve interviewed candidates, it only comes up if they volunteer the information. I don’t go searching for their usernames on github based on what I find by stalking them elsewhere.

So it’s the candidate wanting to show their work. If they came to the interview and I had no idea what was on their github profile, they’d be justified in thinking we either weren’t interested or had taken on too many candidates to allocate time for.

Like others have said, though, unless they have a pinned project which is evidently awful, nothing I see there is going to put me off, even if they only have a bunch of empty hello-world projects.

 

David Young

For me it helps connect the part of their resume that lists “technologies I’ve worked with” or “languages I know” part a bit more practically. I still take it with a grain of salt, but it does help when your dealing with a large volume of resumes.

For example if they list react as one of their skills and I see any react project, and I mean you could make a few changes to a generic create-react-app, I sort of know that at least this candidate does indeed know something about it and it gives us something to talk about in the interview.

Again, massive grain of salt, and if they don’t have any projects it just alters the line of questioning a bit. Also larger projects they’ve worked on could very well be in private repos, but it doesn’t take long to skim through a github profile.

Disclaimer that I’m biased towards this type of checking, because I had a built up github profile before I started applying for jobs.

Please follow and like us:
0

Hiring a Junior Developer Isn’t As Bad As You Think

February 6, 2019 Posted by Recruiting 0 thoughts on “Hiring a Junior Developer Isn’t As Bad As You Think”

Experience is one of the most valuable traits in the job market–and for good reasons. Someone with more seniority wouldn’t need supervising and training. Rookie mistakes are not expected from someone with years in a particular industry, especially an industry like software engineering. Often, developers are working on mission critical tasks that can affect the future of the company. With all that said, hiring a senior engineer over a junior engineer seems like a no-brainer.

The issue is that there is a shortage of senior engineers, which means a handful of the best companies are bidding for the best talent. Though the idea of the software developer shortage has been claimed to be a myth, what many would agree is that there is a shortage of 10x developers. There was a great article, written by Yevgeniy Brikman, that tackled the concept of these seemingly mythical developers that you can check out in order to gain a better understanding of what they are. These developers are every HR  Manager’s dream. Their output supposedly matches that of 10 of your worst developers. They’re the sort of developers that encourage job postings desiring 5 years of experience with a framework that is only 2 years old, just to be able to attract said unicorn.

With high demand and limited supply comes cost, if we’re to follow the basic principle of supply and demand. It goes without saying that staffing an entire team with senior developers is expensive. In many situations, the amalgamation of talent produces results that offsets salary overhead, but there is always the risk of turnover and a new hiring cycle.

The question then arises, how can one keep talent that will allow their company to produce at a consistent level if they’re not the Microsofts of the world or the hottest new startup on the scene? For smaller shops looking to maintain consistent production, the answer may be grooming Junior Developers. Robert C Miller, one of the authors of the Agile Manifesto, wrote a blog post 5 years ago highlighting the lopsided ration of programmers under 28 compared to those over 40.

What he concluded was that the few engineers with 10-15 years of experience could act as mentors to a young crop of engineers, saying,

As a leader, that programmer can teach the team about principles, patterns, practices, and ethics. That leader can temper and curb the youthful enthusiasm that leads to premature decisions about frameworks and architectures. That leader can help to instill the value of refactoring and clean code, as a counterweight to the youthful thrill of gettingittowork. That leader can encourage the team to work hard for eight hours, and then to leave work so that they are fresh the next day. This would prevent burnout, resentment, the false sense that hours equals work, and the insidious dependence upon, and value of, heroics.

Robert C. Miller

The key to instilling this team-first mentality within the development team is to change the common conceptions associated with hiring junior developers.

Experience

While experience is king, it is important to highlight problem solving experience as opposed to language experience. A language can be learned in a few months, but problem solving is a skill that takes years to hone. Weeding out applicants who may not have X amount of years spent with one language can be futile if that same person then has to learn a legacy language just to maintain code that may be poorly documented.

What you want is someone who can understand business logic and juggle multiple priorities. When looking at a potential candidate from this perspective, a company can instill a growth mindset within the team that fosters exploration.

Impact

How can a junior developer contribute to the team? What impact will they have besides draining precious time away from senior developers? These are questions that can be dispelled by the fact that work culture affects the well-being of workers. According to a study conducted by the American Psychological Association, about 60% to 80% of workplace accidents are attributed to stress. A Harvard Business Review article written in 2015 cited that, according to several studies, positive interactions  between coworkers produces positive health results.

When junior devs are placed among senior devs, they have the potential of bringing a love for coding that may have been lost by some of the senior devs. The mentor/mentee relationships can build strong bonds between team members as senior developers may feel that their value within their company increase as they mentor up and coming developers.

Cost

The lost opportunity cost of having a senior engineer take time out of their schedule to mentor a junior dev may seem like a reason to never hire a junior dev, but the long term benefits should not be ignored.  A junior dev who experiences mentorship from great developers may then become an evangelist for your company.

As their network grows, they may be able to refer talented engineers to your company. More importantly, you create a talent pipeline that allows you to promote within the company. Former junior devs that were mentored well will most likely return the favor and mentor new junior devs.

In The End

This is not to say that a company must hire a junior developer. There are some business models–like those of software development agencies–that cannot practically train junior developers.

Also, hiring a good junior dev isn’t much easier than hiring a good senior dev. There is always a list of pros and cons to weigh before making any decision. The point here is that, to those who may feel that junior devs are unhirable under any circumstance, there are legitimate reasons for focusing hiring efforts on junior devs.

Please follow and like us:
0

6 Red Flags(That Are Actually Green Flags)When Hiring a Programmer

January 8, 2019 Posted by Recruiting 0 thoughts on “6 Red Flags(That Are Actually Green Flags)When Hiring a Programmer”

I recently came across a post on Dev.to that listed red flags to watch out for before you hire a programmer. Though some of the points seemed reasonable, others were, at best, questionable. We will go through each point while providing reasons why these red flags are actually green flags.

Programming is only a day job

As more and more millennials join the workforce, selling your soul to a company becomes less and less of a selling point. Of course, this potential red flag assumes that programmers who are actually passionate about their craft will “Always Be Coding.”

Though the idea of a programmer toiling his free time away working on the next Facebook may seem appealing to hiring managers, finding these “gems” can’t replace the practical task of finding a competent developer. This Medium article details the hidden cost of hiring developers. The question HR has to ask is, how many man hours do we want to waste looking for the 24/7 coder?

You can argue that a programmer who spends his hours away from work pursuing hobbies like swimming, fishing, and writing will be more productive when it comes time to work.

Don’t really want to “talk shop”, even when encouraged to.

This point implies that coders who don’t talk shop aren’t skilled in their area of expertise. This is a narrow way of viewing a candidate, focusing only on the bubble of engineers. But engineers don’t code in a closet. They often have to interact with other members of the company, like UX and UI designers, technical writers, and project managers. Someone who doesn’t really want to “talk shop” may be able to communicate better with other members. The developer also may have a different method of problem solving that involves mentally removing himself from the development process to refresh his or her insight.

Learns new technologies only in company-sponsored courses

This potential red flag ignores the possibility that the developer’s learning style is suited to a sponsored classroom environment, free from the burden of having to pay for an expensive course.

Admittedly, a developer should constantly keep up with trends, but if the company is willing to foot the bill and the developer is able to learn new technologies that benefits the company, then this should be a bonus to an employer. The developer is willing to advance his career, and the employer can then market that his company is a hub for career growth. Who’s the loser here?

Started programming at university

This was one of the most questionable red flags. I doubt a Hiring Manager will ever care about when you started the skill they’re looking for. They usually want to know how much years of experience you have and how that reflects in whatever projects you may have in your portfolio.

Like the first red flag, this red flag assumes that child prodigies are readily available. Sure, someone who started coding at thirteen would have a better Tell Me About Yourself  answer than someone who learned to print “Hello World” to a console in her Computer Science 101 class. Still, if the developer has grasped the relevant languages needed to succeed on the job during her four years, this should be a plus on his resume. It shows that she’s a quick learner.

All programming experience is on the CV

This red flag would make sense for a developer with 20+ years of experience. But with many engineering roles demanding 5-10 years of experience with a certain technology stack, a developer who lists all of their experience would save you the trouble of having to pry that information out of them. The true red flag would be experience where the developer’s role does not include detailed, actionable responsibilities.

Focused mainly on one or two technology stacks (e.g. everything to do with developing a java application), with no experience outside of it.

One of the most baffling aspects of the recruiting process is the regurgitation of every technology stack known to man on a job board. The idea is to attract as many prospects as possible, of course. But, ideally, you want a developer to be an expert at at least one stack. That’s what you’re hiring them for.

Specialization is becoming more and more necessary in the field of IT as products become increasingly complex. The notion of a polyglot is akin to Silicon Valley’s unicorns. They are few and far in between.  It’s better to be an iOS expert than a general app developer who can’t delve into the nuances of both Android and iOS.

Conclusion

What we should take away from these red flags is that the hiring process can be highly subjective. Some companies love white boarding while others prefer to highlight soft skills in the recruitment process. Some may take non CS degrees, others may shun them. Some value experience, while others value raw talent. Oftentimes, developers aren’t one-dimensional–you can’t place them in a color coded box. There is no perfect candidate.

Please follow and like us:
0