Recruiting Graduates 3#: The Questions

Introduction

Other blogs in this series Recruiting Graduates #1 and Recruiting Graduates #2

In this blog, I’m going to discuss some of the proposed questions as mentioned in #1, and discuss some questions that possibly or were asked in the actual interview process. The job is a Graduate Developer. The applicants will primarily be Indian but there are a couple of job positions available in the UK.

Many of the proposed questions were misleading/ambiguous/wrong.

Here are some highlights:

Multiple Choice Coding Questions

How many values a method can return in C#? 

A) Any number of values 
B) Only 1 value 
C) Depends on the argument passed 
D) Depends on class 
Answer B

A method can have 1 type defined in the return, but this can be an object which contains many values. You could also say the List type is “many values”, and you can also define out parameters. A) seems a better answer in my opinion.

Multiple Choice Testing Questions

The expected results of the software is __________.
a. Only important in system testing
b. Only used in component testing
c. Most useful when specified in advance
d. Derived from the code.

The answer is A apparently.
I think it should be C. Although it’s not “most useful” – more like essential.
Why wouldn’t you think it is important at any other time? Don’t you care about expected behaviour during Regression Testing? Don’t you care for Unit Testing?

A test technique that involves testing with various ranges of valid and invalid inputs of a particular module or component functionality extensively is ___________.
a. Gorilla Testing
b. Monkey Testing
c. Agile Testing
d. Baseline Testing

Answer is Gorilla Testing, but I’ve never heard of it. I was a Tester for around 4 years, and have worked with Testers as a Developer for several years. I sometimes use the phrase “Gibbon Testing“, but that’s an unofficial testing practice that involves furiously clicking with the mouse, or bashing frantically on a touch-screen. What use is a question like that if it isn’t known by the average tester?

When an expected result is not specified in test case template then ___________.
a. We cannot run the test.
b. It may be difficult to repeat the test.
c. It may be difficult to determine if the test has passed or failed.
d. We cannot automate the user inputs.
Answer: C

I assume “Test Case Template” just means “Test Case”. I think the answer should be A, B, and C, but if you can only pick one, I would go with A because that implies B and C.

Which testing cannot be performed on first build of the software?
a. Regression testing
b. Retesting.
c. Sanity testing
d. Only A and B.
e. All of these
Answer: E

E doesn’t quite make sense because D states ONLY A and B. Of course, the answer is E. I suppose you have to actually assume “All” just means all the testing methods stated, rather than “all of the above” like it usually means on tests.

Face to Face Interview Questions

Behavioural

I found a document which I assume to be the face-to-face interview that Colin was doing. On the few interviews I have been on so far, I was only invited to the coding part of the interview, and even Colin’s notes from each candidates interview weren’t shared with me.

Here are his suggested questions. I think you are supposed to answer in the STAR format (Situation, Task, Action, Result), but it doesn’t quite apply to these. I really hope he didn’t present them to the candidates using this poor grammar, or vague statements.

  1. Will you be interested in picking up the testing activity?
  2. You get some clarification on your query in a work item from product, will you communicate the updated to other stakeholders or not, If yes why?
  3. Will you handle the non-reproducible bugs in the dev environment? – Fixed bug working fine in dev environment but not in test environment
Will you be interested in picking up the testing activity?
Evaluation:
Should be ready to pick it
Should be ready to share the team’s work

The sentiment of the question is fine because sometimes when the Testing backlog is piling up, it makes sense for Developers to help out Test (as long as the Developer is not just testing their own fixes). In the past I have heard many developers complain that they are asked to do this. The thing is, even if that is your attitude, why would you answer that question honestly?

His evaluation criteria seems to imply, you are supposed to answer “yes” then mention something about “teamwork” then you get the points.

You get some clarification on your query in a work item from product, will you communicate the updated to other stakeholders or not, If yes why?
Evaluation:
Shall reduce the repeated work from the whole team
All will be in same page
Will help more for dev for coding and unit testing
Will help more for tester to complete the test design and review
Good, all stakeholders in the same page and sync
Will decrease PO effort in communicating the same thing to all team members

Translation: I think this is saying that you have to implement a new feature, but you question one of the requirements. After you ask the Product Owner to clarify, do you share this information you have learned?

It really sounds like you are supposed to say “yes” to it, then mention something about communication. In reality, I think the Product Owner should change the wording of the requirements on the “User Story” or add extra notes to the discussion section. If the information is recorded there, then any Developer/Tester/Manager who views it will see a record of what was discussed and no communication issues should occur. So I’d say Colin’s suggested points are fine, but the overall answer is really: “no, the Product owner should be responsible for updating the User Story”. However, Graduates won’t have experience working in this way, so I think they would just make assumptions and blag an answer.

Will you handle the non-reproducible bugs in the dev environment? – Fixed bug working fine in dev environment but not in test environment
Evaluation:
Whether raised bug is within the scoped limits
Patching done without any errors
Reproduction steps
Verifying the environment client version
Test evidence in the bug
Conducting a triage call with the production team for more info
Verifying the environment details

Translation: This means you have provided a fix for a bug, but then when on the Test System (or could have gone to the Live Environment), it isn’t working as intended. So what is your strategy for deciphering what has happened?

This is a good question, but maybe hard for Graduates if they have no experience. I think the answer is more along the lines of

  • Check the test environment definitely has your fix on it (patched to the same version number)
  • See if there is any difference in Configuration (maybe some Deployment options, Organisation options, User options etc)
  • See if you can see any difference in the selected data. So if you select a Customer then view their contact details, is there any difference in contact details on their system – compared to when you tested it on your computer?
  • Debug the code against their environment to work it out.

So Colin’s notes covers some of the points, but then his other points are vague and only he knows what it actually means.

Database Question

On the technical part, the candidate was sent a question pasted in chat. The grammar was whack and the formatting of the data was abysmal. How are you meant to work with this?

Select Project names which is having employee working in multiple project

Logic Questions

Question: Measure 4 Litres of water, only using a 5 Litre cup and a 3Litre cup (assume that you have an unlimited supply of water).

Answer: Fill 3L cup with water. Fill the 5L cup with the 3L cup. Fill 3L cup again. Fill 5L cup again with the 3L until it gets filled with water. This will result in you having 1L left in the 3L cup (and 5L in the 5L). Empty the 5L cup. Pour the 1L from the 3L cup to the 5L cup. Finally, fill 3L of water in 3L cup and transfer into the 5L cup.

I think when I first saw these type of questions I was baffled, but once you see an answer, you can easily answer variants of them. I recently played Tomb Raider: The Last Revelation and the final set of puzzles were variants of these and I did them with ease.

Question: In this scenario, you are standing in a room with three light switches. Each corresponds to a different light bulb in another room that you cannot see. If all the light switches are off, how do you find out which one turns on which bulb?

Answer: I will turn on one switch and leave it for a few minutes. When I turn it off, I will quickly turn on another switch. I will go to the room which shows what light turned on from the second switch, then feel the other bulbs for which is warmer (which would be the light I left on for a while). The third switch belongs to the bulb that is off and cold.

This question is nonsense. It never says you can leave the room, and it says “you cannot see” which implies you can never see them from a distance, or get close to them to touch. If you can leave the room, you could turn one on, go and look, then go back and turn on another. I think the question needs to stipulate you can only leave the room once only.

Question: You are driving a bus. There were 10 passengers already on the bus. You pick up 8 people from Stop A, drop 12 at Stop B, pick up 5 from Stop C and drop 9 at Stop D. Then, what is the age of the driver of the bus?

Answer: Your own age.

Question: You have to enter one of the three rooms. One room is on fire, another is occupied by a man-eating lion who is hungry for three months, and the last one is occupied by a terrorist with a fully loaded AK47.

Answer: The 2nd room because the lion is dead because of hunger. (Hungry for 3 months)

I’m not a fan of a question like this because wording it as “is hungry for three months” implies it is still alive and hungry. It needs to say “hasn’t consumed any food for three months”. I think it is intentionally been written like that to reduce the likelyhood of coming up with the answer. One of the aims of the test was to examine people’s understanding of English, and throwing in questions that are ambiguous, misleading or containing poor grammar isn’t the way forward.

Recruiting Graduates 2#: The Job Advert

For the previous blog see Recruiting Graduates #1

Our job adverts have been terrible recently with all kinds of inconsistencies between the adverts, and even some factual inaccuracies. 

For our Graduate recruitment drive in India, we put out an advert with the job title of:

“Fresher Hiring” 

Isn’t a “fresher” someone who is in the first year of university? It’s not someone who is about to graduate or has graduated. It should say the job title to be consistent with the other adverts, so: “Graduate Development Software Engineer“.

Also, it’s not listed under Graduate or Student categories either so you won’t find it using the filters; additionally it is under “IT & Telecoms” rather than “Engineering”.

 
So what are we asking for?

Requirements

Essential

n Academic Qualification: B.E/B.Tech, MCA with consistent academic performance from X, XII standards onwards.

n Experience: Freshers
n Good Analytical and Problem-solving skills
n Knowledge of Dotnet
n Good written and oral communication skills.
n Keen to learn and pick up new skills, passionate about software development, enthusiastic and innovative.

Do you love the letter “n”? well join us today because we would love to have you. Seriously, they are supposed to be bullet points, but somehow HR have used “n”s. I assume this is some lazy copy-and-paste and it hasn’t recognised the bullet points. If HR can’t be bothered putting a good advert out, then why would good candidates apply? It’s ridiculous.

Also back to the “Experience: Freshers” bullet point…

interview question:
HR: "what experience with freshers do you have?"
Candidate: "well, we all got drunk and had many nights of debauchery"


“Good Analytical and Problem-solving skills”,  “Good written and oral communication skills”, and “Keen to learn” are fairly generic qualities to put on a job advert but I actually think they are very appropriate for the job. 

“Knowledge of Dotnet” is debatable. I mean, the job is in C# so you do need “.Net”, but as explained in the previous blog, we are going for Graduates that are mainly using Java or Python. So we can’t say that it is essential – it’s actually “desirable”. Also, I think it is rare to see it written as “Dotnet” rather than “.Net” so we should be using the correct terminology and spelling. 

So even if they find the job advert, they might be put-off by the quality of it. The thing is, we have loads of developer and testing jobs available, in completely different team, products and locations. However, we don’t list the product or give information on the team (well 2 adverts had the name in the title; but it is meaningless to external candidates without a description) you are joining, so it’s impossible to separate seemingly duplicate listings. Furthermore, there is no consistency between the job titles or how we refer to the programming languages we are using. I think the term Software Development Engineer is a bit weird, and, until last year, I would have had no idea what SDE is an abbreviation for. If you were a developer, which job would you apply for out of these active listings?:
 

  1. Fresh Hiring
  2. Fresher Hiring
  3. Fresher Hiring – SDE
  4. SDE – .net
  5. SDE – API Development
  6. SDE – C# Dev
  7. SDE Dotnet – Fresh Hiring
  8. SDE (C#, SQL)
  9. SDE – Team Crick
  10. SDE – Team Crick C#/net and WPF
  11. SDE – Frontend Developer
  12. SDE – Dotnet Developer
  13. SDE – dotNet & SQL
  14. SDE – Dotnet
  15. SDE – Dot Net Dev
  16. SDE
  17. Software Development Engineer
  18. DotNet core Developer

Looking at a “Junior Software Development Engineer In Test” (yes, that really is the pretentious job title that Software Testers get these days), there were quite a few aspects of it that made me laugh. Let’s look at this: 

Jr SDET 

Essential
n Minimum + years of experience in a technical testing role.
n Strong knowledge of software testing approaches including agile testing techniques.
n Superb communication skills both written and verbal.
n Experience in driving UI testing down the stack and increasing robustness of the test infrastructure.
n Exposure to some aspects/phases of automation including GUI, integration testing, and performance/load testing.
n Moderate experience working with Product Owners and SMEs to define user story examples/acceptance criteria and exposure to Gherkin using tools like SpecFlow and Fitnesse.
n Some experience in understanding and testing complex enterprise systems architecture.
n Excellent MSSQL skills and understanding of complex XML structures.
n Good programming skills required in C#/Java.
n Good experience defining lightweight, high value test plans and tests.
n Experience defining and tracking test metrics throughout product development.
n Good experience mentoring and coaching Software Engineers in Test.
n Ability to drive the technical testing approach and guide less experienced department members
n Experience working closely with a team of software engineers and product owners.
n Good knowledge of scripting technologies such as PowerShell or Python.

So the “n” bullet points are here again. The opening line says they want “Minimum + years of experience“. Minimum plus years. Brilliant. 

Experience in driving UI testing down the stack“. What the hell does that mean!?

Notice how we want experience in quite a few aspects, and good programming skills (in multiple languages!), but it is for a JUNIOR role, not a standard or Senior role. Then they want “Good experience mentoring and coaching” which is surely a Senior responsibility.

How do we expect to get many applicants with poor adverts which are hard to find on the website, then have formatting errors or other questionable content?

Recruiting Graduates #1: Discussing how to make a good test

Colin arranged a meeting with a few Senior Developers (including me) and a Senior Tester. He stated that we are going to do a big recruitment drive, specifically targeting Graduates in India.

He said he is disappointed with the current Indian staff in general, since many seem low skilled and poor communicators, so he wants us to come up with:

  • Multiple choice logic questions for a timed test
  • Multiple choice programming questions for a timed test
  • Verbal logic questions for an interview
  • Verbal programming questions for an interview

So we are testing them on both written, and verbal comprehension as well as programming. Fine plan so far.

In the next meeting, a few of the Seniors had come up with some questions which they said they got from some websites. I had spent a few hours scouring the internet for ideas but I had found many websites with poorly worded questions, ambiguous questions, or material that I just thought was irrelevant to the job (either not C#/objected oriented/not graduate level). So I only submitted a few questions but I needed to confirm what our aim was…

I noticed many of the suggested questions were specifically programming questions on C# which is what the job is for, but do these graduates we are targeting actually know C#? I ask the question and the Indian seniors say that these days, university courses are mainly Java and Python. So I tell them the test they have come up with isn’t suitable. For multiple choice, the questions have to be just logical questions using pseudocode. For the interview, it needs to be phrased like “using a language of your choice” and we would have to allow them to use Java, Python or anything else.

I also found that they had many questions that were wrong, ambiguous, or irrelevant. I don’t think they used the same bad websites I found, but there’s some terrible questions out there for sure. I think it says something about how bad our staff are when they are meant to be Senior and they are taking questions from online and not really thinking about if they can answer them or not. We are going for Graduates as well. Really the hierarchy would go Graduate/Junior->Developer->Senior. So surely the questions have to be easy for Graduates to do.

“Why are people who don’t know what they’re doing, setting these questions?”

Colleague

“so we can recruit more people that don’t know what they are doing”

Me

Another problem was that we scraped about 50 questions of questionable quality, then Colin says: “I want 60 questions for them to do in 60 minutes…also we need a second set of 60 questions just in case someone leaks the answers to other applicants”.

Everyone seemed fine with this, but I pointed out that 60 questions were a struggle to come up with, and I didn’t think it was possible to answer them in 60 minutes – I said 45 minutes is better. 60 minutes sounds like pure tedium to me. The 3 other Seniors and Colin were all adamant that “60 questions in 60 minutes” was standard in the industry, and a couple of Seniors said they did tests like this in recent years and it was fine.

When we eventually came up with a test, Colin says

“I tried the test over the weekend, I do not think we can do the test in 60 minutes”.

Colin

Wow, I was correct, and was shot down 4 to 1 votes.

He wouldn’t specify what score he got but was insistent that he passed despite not answering all the questions.

I am never a fan of doing programming questions in an interview situation (unless it involves using a computer). Sometimes companies give you pen and paper, (or a whiteboard), and you have to write code. It’s unnatural and very awkward. Also, they come out with cliché problems like sorting algorithms, or data structures. Sometimes you can blag your way through these scenarios if you practice them beforehand. I prefer a take-home-test to build a small application in a few days. I’m conscious that this can be a lot of work especially if you are applying to other jobs at the same time. An alternative could be to show a program you have previously written and do a presentation on it to demonstrate your understanding and talk through the design decisions.

We already had a take-home-test from previous recruitment, so I suggested using that. The Indian Seniors said this would be far too hard especially if it involved calling a Web API. I said the candidates don’t even have to complete it (fully working app with many features), you just want to see how far they get and see how they structure their code and how they break-down the problem. If you just tell them to write one method like a sorting algorithm, then you don’t really get to see how they structure code because it’s minimal, isolated code.

The Indians even suggested a compromise of giving a choice of programs to write, but to give extra marks if you choose the first example. It didn’t seem that fair to me and there didn’t seem any noticeable increase in difficulty. One suggestion was even to get HR to call them and ask them on the phone to decide which test they want. How would that call even go?

HR: "Are you familiar with Web APIs?"
Candidate: "no"
HR: "do you want to do a banking app with a database?"
Candidate: "no"
HR: "you have failed to get the job"

or

HR: "Which test do you want to do? one with a Web API, or a Banking Application with a database? You get more marks for the Web API"
Candidate: "erm…Web API then."

Eventually, they relented and agreed just to ask for a specific program and we would see how far they got. Next up was to decide how much time they actually got. I suggested giving them up to 10 days. One Indian Senior said 10 days was nowhere near enough time given the difficulty of the program. Another Indian Senior (who had previously stated this test was far too hard), then claimed he had a similar test that he successfully completed in 3 hours. I was like “wut“. How can he go from saying it was far too hard, to then saying it is easy and he can do it in 3 hours! He then suggested we should make them create and interact with a database which I think makes it way harder! I challenged him on this and he said he has never seen a university syllabus that has interacted with an API (which my suggested test required)… Despite him showing me a university that used ASP.net which is all about web apps and web services.

I did feel bad criticising their decisions when they had put some effort in, while I did think about the situation but didn’t have any good questions to ask. However, I didn’t think they had put much thought into the problem they were trying to solve.

Some lessons learned:

  • You need to decide what level of experience you want to aim for so you can set relevant questions e.g. Graduate, Junior, Senior, Expert.
  • You need to know what kind of programming languages your applicants will be using. If they are from a Java background but your job is C#, you may have to set the test in Java, but make it clear the language of the job is C#
  • Make sure the questions make sense, aren’t ambiguous, and the answers are actually correct (this will be discussed further in an upcoming blog)

Remembering the failed the Software Development Apprenticeship hiring 

About 4 years ago, we started hiring some “Apprentices” from a Bootcamp company. They only had a few months training, and it wasn’t even targeted to the languages we needed. So we basically were paying fees to this company for them to give us random people we could have just got ourselves. Recently, a few more of these people have left the business, so I wanted to look back and reminisce on the disaster.

“in partnership with Bootcamp, the Apprenticeship Scheme was launched in April this year and currently supports 14 apprentice software developers, including four employees who have moved within the business. Apprentices spend 20 percent of their time learning new skills and the rest based in the work environment. The company is hoping to take on more apprentices in 2020.”

Local Newspaper 2019

It’s interesting reading this quote because the 4 people were actually from another Bootcamp company we hired from a year prior. I think we switched companies because of some management issues (leading to a lack of communication) at that company. Those initial guys were quite good overall, but then the second company gave us generally poor people.

The part about 20% of the time learning was just nonsense. We never had a plan for them. Some people got moved about between teams every few months, sometimes being told to learn a different language so we never really allowed them to become good. But then most of them that I interacted with just didn’t seem to care; we were giving them money for nothing. I guess they had way more than 20% to learn since we often didn’t assign them any work.

“We are embracing this way of attracting people from less traditional backgrounds and allowing people like Sadiq to challenge themselves. In the process, they are to contribute significantly to our future success.”

HR Director 2019

“we don’t want another Sadiq Situation”

Colin (2022) – on the plans to hire more Juniors. We actually need a training plan for them to succeed.

It’s evident that Sadiq didn’t contribute to our future success.

It would be interesting to know the reasons why each person left since I think they were on good money for their ability, and it’s a low-pressure environment. Most were working on our new software that hasn’t been released so maybe they got frustrated about never having their code reach production.

Anonymised NameStatusEstimated Time Spent
MasonLeft4 years
ElijahLeft2 years
TesterResigned (Health issues)~ 1 year
ChrisLeft3.5 years
DanielStill here3 years
SadiqStill here3 years
PaulStill here3 years
JonSacked 3 years
BrogrammerLeft3 years
SimonLeft (Failed Apprenticeship exams)6 months
The MountainLeft (Decided to change career)<1 year
KatStill here3 years (1 year Maternity leave, yet to come back)
HarryLeft3 years
JohnLeft2 years

So there are only 4 left. Sadiq and Paul have been asked to go through some Training that we have put together, and could be sacked if they don’t show signs of improving. I don’t know much about Kat, but she’s taken a year of maternity leave. Daniel is the only one actually contributing and seems a quick learner. So after ploughing money into the future generation of developers, we ended up with one (maybe 2) future developers. Some of the others did contribute but then thought there were better opportunities elsewhere.

I found these chat logs about the initial batch of Apprentices, mainly targeting Elijah. It was a slow start until they got stuck into proper work, but Mason and Chris were actually really good developers.

Me:
what approach are we taking with these Bootcamp guys?

Steven: 16:23:
I think it's the "lounge about all day and get paid to learn how to write crap code" approach
because the company thinks it's cheaper to do that
the guy next to me has written an app that takes a list of countries and people, and would assign each person to a random country - a sweepstake generator
he seems right impressed with it
called one of his mates over to see it

Me: 16:27:
for the World Cup?
doesn't Different Elijah Wood sit next to you?

Steven: 16:30:
yeah!
he sounds like a robot
robot Elijah clone
I think he must smoke 75 cigs a day

Me: 16:30:
does his random algorithm work correctly
better not be newing up instances of Random at the same time and generating the same numbers

Steven: 16:32:
that's a good point
I haven't code reviewed it

Me: 16:32:
has he written it at work?

Steven: 16:33:
yep
yesterday and today

Me: 16:33:
our guy, Mason just reads Reddit all day
he was running the Build last time I saw him though

Steven: 16:33:
he's got a learning C# book
was reading about collections today
I've been given no info on these guys
so don't know what to do about it

Me: 16:33:
are you looking forward to training him up to expert level

Steven: 16:33:
well that's the thing, I'm not employed as a teacher
I expect everyone to be capable
and if not I'll be raising it as an issue

Me: 16:34:
what information do you want? what they should be working on?
I was expecting some info on that as well

Steven: 16:34:
yeah
should they be reading BBC News or learning all day?
or should they be picking up WIs?
what even is a junior dev?
if a junior dev doesn't even know how to code
seems a big risk to me
not even sure why I went to uni
anyone can code, right?
bring your gran to work day
I didn't manage to write any code today, but I did write a poem. <Pats gran on the head>, yeah gran you've done well today, here's a hundred quid, maybe tomorrow you'll be using the collection pattern

Me: 16:37:
I don't mind teaching people but they do need to pick things up quick
otherwise the extra member is just losing time for someone else
so it's a net loss
I think they should be like the old "Apprenticeship scheme" we had - get them testing, that way they can learn what our software does and learn when they are waiting for work

Steven: 16:37:
I don't mind teaching more advanced stuff, or anything not intuitive
yeah, I think that's the best really

Me: 16:38:
but they don't need to be a Software Tester for 3 years; just 6 months or something

Steven: 16:38:
help the "tools guys" make our Internal Tools decent
or have templates for test environments
the tools team don't seem to have time to make any tools

Me: 16:39:
and I guess they could do some kind of assessment to see if they are ready for simple WI
and if not, then they get out
or stay as a tester

Steven: 16:39:
they're more bothered about useless stuff no one wants

So even when the initial apprentices joined, Steven and I were sceptical that they could contribute since we didn’t really have a plan. It seemed I had a good solution though – by starting them off as Software Testers. They can learn about our Software, Agile Development, Processes, Internal Tools etc. Then later start learning C# more and gain experience with the codebase. I think this is roughly what Colin has in mind for the new recruits…

We are going to be hiring again, but going for Graduates this time, but are we going to do better?

False Advertising Jobs

Intro

I’ve never been involved in the recruitment process to hire someone else, but have applied to jobs and read many job adverts. It’s a process that’s intriguing though, and I don’t think many companies get it right.

I’ve criticised performance reviews in previous blogs, and have stated it is very difficult to accurately judge someone. However, job interviews seem even more impossible to me. You need to come up with a good job advert to bring in the correct people to assess. Then your interview and assessments need to judge the best applicants.

Finding the correct people to fill a job vacancy is probably hard. I think you need to clearly convey what the job entails so people know if they are qualified and interested. You want all these people to apply for the job, whilst not wasting your time with people who aren’t qualified or aren’t actually interested.

When someone applies, you need to make a judgement whether to call them in for an interview/assessment. Anyone you reject through the entire process – is time wasted. Employing someone and regretting it is lots of time and money wasted.

I’ve seen many people come and go over the years, some quietly leaving and not even lasting a few months.

Here’s a collection of Job Advert stories.

Apprenticeship Schemes

When I first started my job, we had a special type of apprentice role where you start off as a software tester but then eventually become a software developer.

It sounded like a great idea; you get technical people joining, they then learn how the system works as a Tester. When they have the required development skills after learning with a mentor over a period of time, they can move into a development role. They will show their quality mentality from their Testing role, but also understand the requirements much more than hiring a new developer.

However, they joined, were never assigned a developer mentor, and were stuck as a software tester until they threatened to quit. It was just a scam. The company got technical and ambitious people that did a great job at testing. Those that were allowed to move to the Development role all became great developers. However, some actually moved elsewhere so they lost these good people.

It’s a fantastic idea if it is implemented as promised.

More recently, we hired loads of Apprentices via boot camp companies. Just like before, they never really got assigned a proper mentor. They mostly got placed in teams which didn’t have any direction on how to use them. A few months later, presumably someone highlighted this to managers and they were then moved to another team but without anything else changing.

They also had the promise of “Apprentices spend 20 percent of their time learning new skills and the rest based in the work environment”. We even published stories in newspapers with this claim. Maybe you could say 100% of their time were learning new skills because they were kinda just left alone and not really integrated into the team. Some quit after being frustrated that they couldn’t produce any valuable work. The better ones quit to find another software developer role, and the rest just seem to be happily taking the pay cheque for little expectations.

Having a nice spread of abilities: Apprentice, Junior, Developer, Senior, Expert is great as long as you have a plan of how to integrate everyone in the team. If you don’t have a plan for short term and long term, then there’s no point in hiring them.

Women are likely to apply if the job is accurate

See Women In Tech blog.

“Women working at HP applied for a promotion only when they believed they met 100 percent of the qualifications listed for the job. Men were happy to apply when they thought they could meet 60 percent of the job requirements.”

Hewlett-Packard

I find this statement bizarre. Most job adverts are basically just keyword spam and it is hard to ascertain what the job actually involves when they are being vague. If it really does reduce the number of women applying for roles, then why does it keep happening?

I’ve seen job adverts that we put out which may say something like “experience with VMWare” when you don’t need to know anything about how it works – you just need to know how to open sofware and log in. Or you see job adverts like “experience with React, Vue, Svelte” when you know the job is only going to involve one of them… but which one? If you have experience in React and have no interest in using Vue or Svelte, are you going to apply to it?

lorem ipsum

On a few occasions, our HR have put out adverts where the full text was just “lorem ipsum”. This is ridiculous. I mean, they have 1 job to put out adverts, and they just copy and paste a template and don’t even fill it in.

If people see that in a job listing, are they really going to take our company seriously? The fact that it has happened on multiple occasions means that they should change their process so it doesn’t happen again.

Cycle to work 

We work at home now, but yet still heavily promote the cycle-to-work scheme as a benefit. Recently we have promoted other “green” ideas like discounts on electric cars. If we don’t drive to work, then really it’s just a potential employee discount. Additionally, it’s not as directly aligned to the company values as they make out – they are basically encouraging more cars on the road!

Bad Impression

We are a tech company that makes various software products. However, our Job Vacancies page isn’t mobile-friendly – you have to use a PC to view them properly. Again, this is going to leave a bad impression and people won’t take our company seriously.

Conclusion

When it is hard to find the right people, and costly to recruit, it is important that you get every stage of the recruitment process correct. You need to get the right people applying, then your process has to accurately judge the best candidates.

Placing a “lorem ipsum” advert which doesn’t display correctly on a mobile device, and also promotes a cycle-to-work scheme on a home-working role – isn’t going to get many applicants.

Should Software Developer Job Titles Exist?

I was watching a YouTube video about Job Titles in Software Engineering and there was a comment:

“labels like senior, medior or junior are illusions companies make to pay you less… we can’t put labels on people – everyone is different. This approach also supports imposter syndrome”

The comment got the following response:

“This is certainly a valid opinion, but it doesn’t change the fact that putting these labels on developers is a standard practice in the industry. And if getting a different label means having more opportunities, more money, and arguably more fun, shouldn’t we discuss how to get there?”

This response is definitely correct. If it is standard practice, then it’s beneficial to follow. If you are advertising a job and just write “Developer”, Seniors and above may overlook this advert because they may interpret it as below them.

As for the original comment, I would have thought the opposite is true. If you have the same title, it is harder to justify higher pay. If you have a different title, it is much easier to justify higher pay and you will also obtain higher rises as you jump from one role band to the next.

As for imposter syndrome, having the same title as someone you perceive to be much better can easily dent your confidence. If they have a higher title, then it’s easier to aspire to be the same rank as them; and you will feel confident with your own title.

I definitely think a hierarchy makes sense.

Gender Pay Gap

We recently published our Gender Pay Gap figures, and HR and Directors love to hype it up. However, I read this definition we put out with our results, and wondered how useful it actually is:

The Gender Pay Gap GPG is the difference in the average pay and bonuses of all male and female employees across an organisation. This is different to equal pay which is the comparison of the amount a male and female gets paid for doing the same job.

Mean %Median %
Gender Pay Gap 20207.31.5
Gender Pay Gap 201911.25.1
Gender Bonus Gap 2020-28.514.1
Looks like we have reduced the Gender Pay Gap, although it looks like some women are getting massive bonuses to skew the mean
Pay QuartileMen %Women %
Upper7426
Upper Middle6634
Lower Middle7228
Lower6733
Seems around 2/3 of our staff are men, although women are getting those Upper Middle management jobs

So I’m not sure what these figures mean. I think these vague figures mean that we are grouping together Directors, Managers, Developers, Support Staff, Admin staff, maybe even cleaners. Then we split them by gender and publish the average.

Even if it was grouped by department, I’m not sure what you could take from the results, although I would quite like to see it. There’s not many women Developers in the UK offices, but there’s a fair amount of Software Testers, and plenty of Managers. I’ve no idea if the average manager gets paid more than the Developers but it could be possible women get paid more in our Department.

I think the second set of figures show how I imagine the Development Department is. There’s generally more men everywhere but the managerial roles that women seem to favour – are higher paid. So the highest proportion of women are in the “upper middle” (34%).

But you can’t conclude anything from these figures other than we probably need more women in general. What we need are the Equal Pay figures, but even then, I think there will be plenty of people that aren’t fairly paid regardless of gender. I wrote about how I was unfairly paid recently and I ended up with a promotion and ~£14k rise.

These somewhat cryptic statistics don’t really mean anything and just seems like a token gesture to appease those that would actually benefit from them if they were accurate. What I always find strange is that the HR department is mainly composed of women, and if these women are actually seeing a problem with Equal Pay, then surely they should sort it because they should have the power to do so.

The Changes #2: Demotions

Recently, we have a new CTO and a new Head Of Development. Like all new managers with power, they want to make their own changes.

In The Changes #1, I explained changes to job titles of Testers. Some Developers are also affected.

Currently, the hierarchy is basically Junior, Developer, Senior, Principal, Architect. With the new changes, we planned on removing the Principals so they will become Senior.

When I think about it, there aren’t that many Principals, and their job is really the same responsibilities of a Senior. To be honest, there isn’t actually any difference in responsibility between the standard Developer role as well.

I actually like these titles though. If implemented correctly, it gives you a clear indication of people’s skill level. With the new titles, if managers created 2 teams consisting of 1 Senior, 3 Developers and a Junior in a team. If one team’s Senior is a standard Senior, and the other team’s Senior is the former Principal, then this second team has a massive advantage because they have a leader that is at a significant skill level. I know it’s not a competition, but developers will want to be in successful teams.

With job titles, if you manage to persuade a promotion, then your wage should jump up to that band. If you remove the level, then it puts the power towards the employer to suppress your wages. It’s much harder to justify an increase if you don’t accept more responsibility (or have a title that implies responsibility, even if there actually is none).

I can’t speak for everyone, but a better job title is a massive motivator for me. I have been suffering low motivation for a while because my team members see me as a Senior but I have just had the Developer title. It hasn’t happened many times, but there’s definitely been a few occasions where I felt people haven’t accepted my idea because someone with a Senior job title suggested something else – so they automatically sided with them. So I think you automatically gain respect among certain colleagues.

If I had earned a fancy job title and my employer took that away from me, I would be very angry. If it took people a long time to gain that title, it would be devastating. I guess that means that Colin should have moved back down to Senior which is a much more appropriate job title for him.

However, after about a week, this idea was silently squashed. I found out because I asked a Principal Developer what he thought of the demotion, and he said it wasn’t happening due to the amount of negative feedback the managers received. 

The thing is though, surely anyone with common sense would know that people weren’t going to react positively. If the managers were willing to back down that quickly, then how did the idea even get to the stage where managers agreed to announce it to the department?

Shots Fired On Inexperience: Leaked Transcript

Intro

Even though all software developers should take part in code reviewing their peer’s code, I find most developers I work with aren’t that interested, so ultimately it comes down to a few high-ranking developers, plus me.

Recently, we have been rejecting a lot of bad code from inexperienced developers. It’s fine being inexperienced as long as you have a team to support you and help you eventually produce an effective solution. I think what happens is – there’s not enough seniors (or seniors that are actually good), so the code gets into their Project Branch. Then, when it is time to merge in for the Main release, experienced developers review the code and reject it.

I often specifically get asked by the Software Delivery managers to review code to ensure it is in a good state for the release. We had a group conversation where we were discussing the current bad state we are in. Software Delivery managers had asked Darren, Dave and me to review a project.

Participants

Darren, Dave – Principal Developers

Mark, Michelle – Software Delivery Manager

Me – the silent observer

I’ve given the developers names that start with D, and the managers names that start with M, so it might be easier to follow.

The Conversation

Darren  08:36

Whole lot of Nope in this Code Review.

Mark  10:52

Judging by your review comments, this doesn’t look to be something that can be resolved in the next couple of days. Does their implementation need to step back and restructure?

This might need another call

Have any of you guys been involved from a high level view for this Project?

Darren  10:55

The changes to the Database are totally inappropriate, and possibly way off the mark of what is needed.

Changes to the Database filing are non-trivial, if people don’t understand it, they need to reach out for help, not just smash code in.

Our product is going to turn into a legacy codebase very quickly if this behaviour carries on.

Dave  11:11

We do keep getting Code Reviews to Main with unworkable solutions. It’s highly frustrating, and a big waste of our time. Most of the time, the code or even the work item has not been reviewed by an expert-level person before a review to Main is requested. On occasion, someone gave correct advice in the first instance which was then ignored.

We need to fix this, and have help from you guys raising the problem.

Darren  11:14

The solutions feel like a very reactive approach to programming… Very little thought for design.

Mark  13:02

So have any of you guys been approached about this Project before this review  was raised?

Because I think this ties in with the whole idea of needing an Subject Matter Expert during the construction of the project rather than at the very end – something that we’re trying to drive forward

Dave  13:07

only about 2 days ago 😖

All our Subject Matter Experts are on the New product 😛

Darren  13:08

I reviewed the previous incarnation of it, without the concerning the Database changes.

“All our Subject Matter Experts are on the New product” Even so, I might have made time to discuss this with someone if asked.

Dave  13:09

yeah same

My point is that the day-to-day design and building of the projects is led by inexperienced devs. The developers are not being mentored while developing the code – but instead, at the end of their code writing; which should be something a lead developer is doing

It’s good to have the view throughout the dev process, or at least the start, as well as quality checks at the end – which should be a straight-forward “yeah, you’ve not done anything crazy, it meets the coding standards and is what we agreed”.

Mark  14:43

Yeah. This is all the good stuff which me and Michelle are trying to address as well. Trying to have a Subject Matter Expert assigned to each project during construction just for that overarching view, and to give a steer when needed.

I.e. a month ago this could have been caught at the start by saying “don’t make these changes within the Database itself” haha.

Darren  14:51

To be fair, you don’t need a Subject Matter Expert to tell someone not to dump a load of copy and pasted code from one module into another. Just someone with some experience in developing software to a higher standard than “Hello World”.

Michelle  14:52

“Hello world” just triggered some terrible school flashbacks.

Dave  14:52

Agreed, but as a business, we need Seniors to point out when people are constantly doing silly things to their line manager.

Michelle  14:57

It’s the experience aspect that is the biggest challenge, if there was a better ratio of experienced people to inexperienced people areas where skills are not good enough, they would start to improve (or at least that’s the theory).

Everything just seems stretched way too thinly at every turn. Hell, it isn’t just development that has the problem.

Darren  15:00

I’d also add: knowing anything about the teams working on the code would help.

I can’t know everyone, but I don’t even know what the teams are, what they are working on, who the seniors / leads are to discuss with.

E.g. if someone has a problem with code my team is doing, then I’d expect to be brought into the loop (either to explain our position, or to understand the other sides)

Dave  15:06

Who do we talk to, to at least pass the buck on the issue and raise it?

Michelle  15:11

I think it is more for the Development Director. It’s something me and Mark have brought in fashion everytime we come across an example. Difficulty has always been what to suggest to fix it within the limitations of what we got

Dave  15:21

Certain business types don’t understand the value of good engineers and will simply get the cheapest money can buy, in the hope the decent engineers will act as quality gates and stay with the company.

It must be soul-destroying, working away in an office across the globe, with ‘experts’ in the UK saying if your work can or can’t join the rest of the product. It’s not the right thing to do.

They need infrastructure mirroring ours, and separate projects would be a great way to achieve it

Darren  15:25

Last I knew, the other office still have Development and Testing as separate departments

Dave  15:25

This just reinforces the stereotype that Ben bangs on about: the company is ruled from the UK. Normal companies have different product sectors at different locations, because it mitigates these problems

Michelle  15:27

All valid points. What Dave is saying are points raised verbatim by more than a few people who have been in this world for a while. As for soul destroying: 100% agree it has to happen to catch this stuff; but each time it’s caught it will knock you back that little bit more

Just needs some kind of sensible structure that is adhered to. But then again – if no one is made to follow something, who will?

Dave  15:30

Yeah, for me, it’s responsibility, if you don’t have to pay for your actions, then it drives bad behaviour. But since we maintain our Product, having to pick up the bugs, see the customers complain on Social Media, see the error reports on live and backlogs grow, we’re a lot more invested

it is feeling more and more like, knock this feature out as quick as possible, throw it over the fence at UK law-enforcement, see if it goes through

👮

With responsibility you’re driven to get the right structure in place, you want to place experts/leads with the teams and have them monitor each day, because it soon becomes a very long task to get fixed last-minute. Top-down approach, drives the 9-5 job behaviour, lack of interest and minimum viable work ethic.

Darren  15:32

+1

Which goes back to my point about who the teams actually are. And we really need to do proper ownership. I still own large bits of our Product, because I care about them!

Dave  15:34

Same. Developing and code reviewing isn’t my job, really. However, I don’t want to see the product damaged and go to waste, because it helps people, genuinely.

Darren  15:34

Would be so much nicer to say “I don’t look after this any more, just do what you want and hope nobody gets sued” 😣

And it isn’t any one change that is unsafe, it is the poor quality, lack of adherence to existing designs, just piling code in, coupling stuff together, changes in the wrong place, etc that lead someone else to create a unsafe bug later – usually without anyone batting an eyelid.

OK, some changes are totally unsafe too – a few weeks ago, I have to point out that you cannot calculate an age in months by doing ageInYears * 12

😖

Dave  15:48

So, if I were to write some general comments without mentioning names, and send them to the Development Director, expressing that we’re at our wits-end, would anyone be prepared to back it up or be a part of the revolution?

Darren  15:50

Feel free to add my name to give clout to this

Dave  15:50

sure, I will of course send to you first to check

Summary

  1. Not enough people willing, or have the ability to review code. – I always find this a weird one; given that I reckon 90% of a developer’s job is reading existing code. If you cannot review code, then can you be a good developer?
  2. People aren’t putting enough thought into the architecture, or adhering to well-known standards like SOLID Principles – This is the kind of behaviour I saw in developers I’ve written about like Colin and Derek.
  3. The ratio of Juniors to Seniors is far too high, which not only is a problem now, it is a problem in the future when the Juniors haven’t progressed enough.
  4. The rapid hiring of staff has meant you don’t know who people are, what they are working on, and what their level of experience.
  5. Hiring cheap staff has caused some resentment/uncertainty with UK staff. Pay seems frozen and more jobs are moving abroad. It wouldn’t be that bad if the staff we hire are cheaper and are good, but they often just appear to be cheap.
  6. It would be better to split the offices into separate products so people feel like they have full ownership. There’s other problems too like time-zone differences and general communication problems.

Software Development Interviews

I think a big challenge during the Software Development hiring process is how to determine who is good or not. 

Sometimes companies give large projects as a do-at-home test, but this puts people off when they currently have a job and have other commitments that take up their free time.

You could be given a smaller task, but then it may still not give a good representation of how someone codes, and you could easily get someone else to write it for you.

Other companies leave it until the interview and make developers write code in a manner that is completely out of their comfort zone; e.g. using pen and paper, or a whiteboard. Apparently, Google makes you write code in a shared Google Doc.

I’ve sometimes been given a timed test to complete at home. So you are emailed a list of varied questions and have to quickly code them then send them back via email within an hour.

The challenges they make you do can be varied. Sometimes they can be really basic, using fundamental concepts you will use on day 1 like simple loops. Sometimes they opt for the computer science route, and ask you to implement classic algorithms, maybe a sorting algorithm like bubble sort. Sometimes I have been asked to create a structure like a linked list, or a Directed Acyclic Graph.

You could specifically study these typical questions and then get past the code part of the interview process – even though in a real job you would struggle when posed with various real-world problems. There are plenty of websites that sell training courses that target these algorithms because they are so widely used in the hiring process.

So in the worst case, you will be writing code with a pen, with no resources to help you, under pressure from people watching and judging you.

Yet, when you are employed, you are using an IDE like Visual Studio on a PC, have more time to come up with a good implementation, and can use many internet resources to help you. You will need a good knowledge of the existing codebase, and be utilising 3rd party libraries.

You need to be able to communicate effectively with team members, use Google/Stack Overflow to find solutions/answers. I think it’s important to be able to do code reviews, and show debugging skills, but this is never tested as far as I’ve seen.

In a high-pressure interview, you don’t get a representation of how the person is day to day. I tend to panic in an interview, but am completely relaxed in my job. Even when there is a tight deadline, it still doesn’t faze me as much as an interview situation. So I’d say you can’t even reliably test “ability to handle pressure”.

There was one time we have used this typical interview approach for internal candidates. What’s the point giving a programming test to a software engineer that’s currently employed at your company? It makes sense to give this test to someone moving from another department. I got denied a Senior promotion using this method, yet most of my team members would have vouched that I was among the best in the team. Yet, underperforming Developers got promoted using this process. I’ve written many stories about them here (Colin, and Derek).

I’m not sure what the best way of judging developers, but I would probably go for a programming test using a laptop while allowing use of the internet (or just the interviewer’s knowledge). The test would involve writing some new code, but building upon some existing code which has a bug or two that the candidate is required to debug and fix. The final part of my test would be to review a selection of code changes to see how they handle Code Reviews. This could take a few hours, so I’d only include a few standard questions.

Currently, it’s a failed system if someone can be an excellent programmer, demonstrated by a comprehensive Github profile, yet fail an interview because they couldn’t come up with an optimal solution for some problem while being surrounded by a panel of intimidating interviewers.