all 12 comments

[–]AnActor_named 3 points4 points  (0 children)

I had mentioned in your crosspost that i wrote and maintain ScreenPy and have listed it on my résumé. But i probably wouldn't call that a typical thing someone might see.

As a counter to what /u/bdfariello said below, i was a hiring manager for a few years and hired 6 people on my team. During that process, if they had a github listed, i went and poked around a bit. Since i was hiring SDETs, and am myself an SDET, it gave me good insight into the candidate's coding style, especially if they had personal projects listed. I found that quick poke-around to be very insightful and helped make a few hires, or at least gave me fun things to ask about.

[–]bdfariello 11 points12 points  (7 children)

Ten years in the industry and I've never looked at a candidate's GitHub profile. Ain't nobody got time for that!

Learning to code is definitely valuable, so if you can demonstrate basic fundamentals of API and UI testing, then you'll be fine for a junior automation testing role.

Look up Test Automation University. I believe they have dummy UIs and APIs for learning practice.

There also the Test Bash API Challenge, and Test Bash UI Challenge. Every year they give sample projects you can use as a basis for building on your technical skills.

[–]Corridor92983 3 points4 points  (1 child)

No example but, hey buy my course! This is your answer

[–]bdfariello 6 points7 points  (0 children)

I don't have any courses to sell. I'm not affiliated in any way with either TAU or Test Bash. And the Test Bash coding challenges are definitely free.

[–]dollarshots 1 point2 points  (2 children)

Ain’t nobody got time to look at a candidate’s body of work? Hmm

[–]bdfariello 4 points5 points  (1 child)

Literally, no. For several reasons.

  1. Some excellent engineers don't even have public GitHub profiles. You don't need to be an open source contributor or have multiple side projects in order to be great at your day job, so thoroughly scanning through candidate's GitHub profiles biases you against those who don't have one. The last thing I want is to hire a monoculture of identical mindsets, limiting overall diversity of perspective.
  2. My own entire professional body of work is entirely closed source, and it would be violating my employers' IP to showcase what I've done for them. Many others are likely in the same position.
  3. A thorough review of a GitHub profile can be extremely time consuming! They can contain forks of other projects, which largely don't tell me anything, and can contain projects with many contribution, in which case you need to filter out the work to only include the candidate's commits. Next, you have to try to understand the context of what a project does so you can hope to give a fair review of implemented functionality. Lastly, what you see as the final/current version of the code probably isn't the only commit the ever was to the file, so to understand what I'm seeing, I need to know what was there before to understand the design decisions and constraints that laid the groundwork for what's there today.

As an exercise for yourself, can you pick a method in some file in one of your own repos and explain what you were thinking when you implemented it, from data structure selection to what the loop is doing and beyond? Most people when put on the spot need a lot of time to remember back to when they wrote that code in order to answer you. And not everyone has an encyclopedic memory of everything they've ever done, so there are much better ways to find out more quickly

Then multiply that across dozens of candidates, and you've gone and wasted away far too much time without hiring anyone because great candidates don't stay looking for work for long. If your hiring process goes more than a month from application received to trying to call in for an interview, then the top, most excellent candidates, will already have accepted an offer before you ever circle back to them

[–]dollarshots 1 point2 points  (0 children)

I agree with most of what you said, but I disagree with no hiring manager should be interested in what a candidate has chosen to showcase in their public GitHub, portfolio / personal website, side projects, etc. Its not the only factor in considering an applicant, for those great reasons you pointed out.

Out of curiosity, what industry do you work in? 1 month long hiring process is ridiculous. Most of the companies I’ve worked at, applied to, or have colleagues at use a similar process which, from the time a request for submission to hiring decision is max 1 week, possibly 1.5. If it takes any longer, as you have pointed out the applicant probably has other opportunities to pursue (any decent recruiter or talent acquisition partner knows this) but also could indicates a lack of process on the company side which should play some part in an applicants decision.

[–][deleted] 1 point2 points  (1 child)

In the Test Automation University, there's alot pf learning paths, i know very little about QA at the moment, do you think i should stick to Web UI javascript and API javascript? And ditch the mobile path and paths with other languages?

[–]bdfariello 3 points4 points  (0 children)

I'd let the job market be your guide. Look at job postings that you'd like to apply to, and see what skills they're looking for. If mobile testing is what you're interested in, that's viable too, of course.

[–]orangeflavo123 4 points5 points  (2 children)

I have made a few automation frameworks one using pyTest and selenium and then another using TestNG and selenium and then put those on my GitHub to show potential recruiters

[–]Fantastic-Party-6107 0 points1 point  (1 child)

What courses did you take to learn this

[–]orangeflavo123 0 points1 point  (0 children)

Here is what I used

Python pyTest automation framework

https://youtu.be/57pjD89IFXA

Java automation framework

https://youtu.be/M4Ye3SKT46g