
SWE EPA: AM2 Professional Discussion & Portfolio Overview | by Esgrid Sikahall
Welcome! It looks like you have been thinking about your EPA. You may have come from the Software Engineering EPA introductory article or from the Assessment Method 1 articles. If you haven’t read the EPA article though, go ahead and read it. You won’t regret it! It will help you understand how the two parts of the EPA - Assessment Method 1 and Assessment Method 2 - fit together.
This two-part article is a one-stop guide for the Assessment Method 2 or AM2. We’ll focus on two things:
- The 1-hour Professional Discussion
- Your Portfolio
In this part, you’ll get an overview and a detailed description of the discussion, alongside an introduction to the Portfolio. In the second part, we’ll focus on a detailed description of the Portfolio and how to structure each piece of evidence.
Preliminary Considerations About AM2
Ok, let’s get to the point now! The AM2 of your EPA is a one-hour Professional Discussion underpinned by your Portfolio. Your Portfolio isn’t assessed directly. What is assessed is the 1-hour discussion but your Portfolio creates the context and the content of the discussion.
The purpose of the discussion is to show that you have met the relevant Knowledge, Skills and Behaviours or KSBs in your Portfolio. The KSBs are the DNA of your Software Engineering L4 Apprenticeship and they underpin both AM2 and AM1.
The apprenticeship standard contains the list of KSBs and in the apprenticeship assessment plan, you can find which KSBs are tackled in either AM1 or AM2. Below we’ll focus on the KSBs you need to tackle specifically for AM2.
AM2: 1-Hour Professional Discussion
The most important aspects of the discussion are the following:
- The Professional Discussion is booked within 10 days of submitting your Portfolio at Gateway. It will happen at least 10 days after submitting your Work-Based project, alongside the 1-hour Q&A based on your Work-Based Project report.
- An assessor from Accelerate People - Multiverse’s End Point Assessment Organisation (EPAO) - will conduct the discussion. You should expect at least 12 questions.
- The discussion could be extended for about 5 to 10 minutes to give you a chance to finish answering the last question.
- The discussion will swim in the waters of your Portfolio and especially on all the KSBs which your Portfolio should’ve covered.
You should be able to distil all the wisdom you acquired in the creation of your Portfolio in your 1-hour discussion. This means that your Portfolio should be structured so that you can use it to point to specific instances of meeting each of the KSBs.
Professional Discussion Structure
Can you picture this discussion in your mind yet? Perhaps the advice above is useful but doesn’t help you imagine yourself having the conversation. That’s ok. Here is a structure from Accelerate People that can help you have a sense of what it will be like:
- Welcome & introductions: You should be told here that the discussion will be recorded.
- Identity and tech check: You must have a form of photographic ID and make sure your equipment and software are working properly.
- Overview: the goal of the discussion - as an assessment - should be made explicit here.
- Job role and everyday tasks question: You will be asked to explain your job role, the kind of work you do daily, and the type of company you work for (what they do).
-
The main discussion:
- The assessor will explore what you have done and how you’ve done it, based on the evidence in your Portfolio. Here is where the minimum of 12 questions come in, following up with more questions if necessary.
- The goal is to see how you demonstrate all the KSBs holistically and in sufficient depth.
- You should be confident and able to speak in the first person about everything in your Portfolio: use “I” and not “we” since all the work in the Portfolio is your work.
- Take every opportunity to clarify your points and use your Portfolio to show evidence to support your points.
Preparing for the Professional Discussion
Always follow the bright STAR. It takes practice to answer a question well, without waffling and without falling short of showing clearly, with concrete evidence, what you want to say. STAR is a way of helping you focus your mind and speech when answering. STAR = Situation Task Action Result.
Look at this fictitious exchange between an independent assessor (IA) and an apprentice (A):
IA: “...Great to meet you and thanks for showing me your ID. Would you mind if I ask you about an instance where you linked some data to a particular function or place in your code?”
A: “Sure, good question. In my team we use databases hosted in AWS and once I was asked to access a specific user table to draw the user details and make sure they all had valid data, changing things like blank spaces or non-alphanumeric characters to a null value.
“Before this task, I should mention, I had been trained in AWS and I actually got the AWS Certified Cloud Practitioner certification, which was really helpful.
“What I ended up doing was, first of all, to make sure I could access the data, without changing it. For this, I created a script in JavaScript to make sure I could log some of the data. After my script worked and passed the tests I wrote for it - and you can see a screenshot of the passing tests on page 15 - I changed one of the data rows and made sure that it was working correctly.
“Finally, I applied my script to the whole table of users. I was glad to see that all the users seemed to have changed correctly and that I had done the task adequately. Later I learnt that there was a more efficient way of drawing the data but I was glad to have created my own workflow since I now know two different ways of doing it. I actually used this other method on this other project on page 25 where I was asked to do…”
Can you identify each of the STAR elements? Take a few minutes to pick this answer apart and identify where each element is and how it helped the apprentice answer the question.
Make sure that you bring all the evidence from your Portfolio to help you answer any questions. If you didn’t include something because it wasn’t necessary and you feel it would make your point even stronger, make sure you mention it.
Also, note that our STAR apprentice mentioned they’d done a course on AWS. Bring all the learning you’ve done to your discussion - show the assessor that you have been trained and that you have worked in depth. You want to leave no doubt that you have done everything you needed to do to meet all the requirements with excellence.
Finally, regarding your physical space and setup:
- Make sure you have a suitable internet connection, camera, headset, and microphone.
- Make sure you locate yourself in a space where you can express yourself confidently, with no interruptions.
- Remember that nobody knows more about your Portfolio than you do.
- Practise the setup you’ll use for the discussion. Open the application (Microsoft Teams for example), locate it on the screen as you want it, and close all other windows (of PDFs, browser windows, or any other app, etc.) except your Portfolio - you should be able to search it and refer to it quickly. You can also use a notetaking application like Microsoft Word, Notes, or Pages - the screen will be shared so the assessor can see what you’re doing and seeing.
- Have an empty desk - no notebooks, mobile devices, posters, textbooks, or anything else that could be considered an aid. The only aid you should have is the digital copy of your Portfolio.
Assessment Criteria
Before moving on to the Portfolio in the next section and in the second part of the article it is useful to give you a first glimpse of the KSBs you’ll need to meet in AM2. The assessment plan separates the KSBs into the pass and distinction versions of the KSBs:
|
Minimum (Pass) Criteria for Portfolio and Professional Discussion |
Meets Criteria? |
|
|---|---|---|
|
Yes |
No |
|
|
Describes all stages of the software development lifecycle. (K1) |
||
|
Describes the roles and responsibilities of the project lifecycle within their organisation, and their role. (K3) |
||
|
Describes methods of communicating with all stakeholders that is determined by the audience and/or their level of technical knowledge. (K4, S15) |
||
|
Describes the similarities and differences between different software development methodologies, such as agile and waterfall. (K5) |
||
|
Suggests and applies different software design approaches and patterns, to identify reusable solutions to commonly occurring problems (include Bespoke or off-the-shelf). (K7) |
||
|
Explains the relevance of organisational policies and procedures relating to the tasks being undertaken, and when to follow them including how they have followed company, team or client approaches to continuous integration, version, and source control. (K8 S14) |
||
|
Applies the principles and uses of relational and non-relational databases to software development tasks. (K10) |
||
|
Describes basic software testing frameworks and methodologies. (K12) |
||
|
Explains their own approach to development of user interfaces. (S2) |
||
|
Explains how they have linked code to data sets. (S3) |
||
|
Illustrates how to conduct test types, including Integration, System, User Acceptance, Non-Functional, Performance and Security testing including how they have followed testing frameworks and methodologies. (S5, S13) |
||
|
Creates simple software designs to communicate understanding of the programme to stakeholders and users of the programme. (S8) |
||
|
Creates analysis artefacts, such as use cases and/or user stories to enable effective delivery of software activities. (S9) |
||
|
Explains, how they have interpreted and implemented a given design whilst remaining compliant with security and maintainability requirements (S17) |
||
|
Describes how they have operated independently to complete tasks to given deadlines which reflect the level of responsibility assigned to them by the organisation. (B1) |
||
|
Illustrates how they have worked collaboratively with people in different roles, internally and externally, which show a positive attitude to inclusion & diversity. (B4) |
||
|
Explains how they have established an approach in the workplace which reflects integrity with respect to ethical, legal, and regulatory matters and ensures the protection of personal data, safety and security. (B5) |
||
|
Illustrates their approach to meeting unexpected minor changes at work and outlines their approach to delivering within their remit using their initiative. (B6) |
||
|
Explains how they have communicated effectively in a variety of situations to both a technical and non-technical audience. (B7) |
||
|
Illustrates how they have responded to the business context with curiosity to explore new opportunities and techniques with tenacity to improve solution performance, establishing an approach to methods and solutions which reflects a determination to succeed. (B8) |
||
|
Explains how they reflect on their continued professional development and act independently to seek out new opportunities (B9) |
||
The distinction criteria cannot be met without meeting the pass criteria. Distinction always means meeting the pass criteria and going beyond them. The distinction criteria are as follows:
|
Distinction Criteria for Portfolio and Professional Discussion |
Meets Criteria? |
|
|
Yes |
No |
|
|
Compares and contrasts the different types of communication used for technical and non-technical audiences and the benefits of these types of communication methods. (K4, S15, B7) |
||
|
Evaluates and recommends approaches to using reusable solutions to common problems. (K7) |
||
|
Evaluates the use of various software testing frameworks and methodologies and justifies their choice. (K12) |
||
Portfolio: General Remarks
So, having seen the pass and distinction criteria, what should your Portfolio look like and what should it include? As we saw before, you’ll be using your Portfolio in your Professional Discussion and the assessor will use it to guide the discussion. The structure, its contents, and how you present the content must be pretty important!
According to the assessment plan of your apprenticeship standard, your Portfolio should include 10 pieces of evidence in total. Accelerate People suggests, however, that you could have 3 or 4 larger projects or a combination of smaller and larger tasks.
The Portfolio should contain evidence of work projects or tasks done by you at your workplace, and these tasks or projects should show clearly that they meet all the KSBs required and are adding value to your business. There should be at least one piece of evidence meeting each of the KSBs and each piece of evidence can, and normally does, meet more than one of the KSBs.
But what is a suitable task for my Portfolio? Accelerate People actually refer you to the list of skills (see them below) to give you an idea. But remember, this isn’t an exhaustive list. Many kinds of tasks can fit the KSBs. As long as a task meets one or more KSBs robustly, this task can be considered suitable.
The evidence you need to provide could be:
- Written:
- Accounts of activities completed
- Work instructions
- Safety documentation
- Technical reports
- Company policies and procedures as appropriate to the activities
- Images:
- Photographic evidence and work products (think screenshots of code, designs, your actual app, drawings, etc.). Remember to always add explanatory text to a given image!
How to structure your Portfolio so that it shows the KSBs clearly though? One thing is to know the kind of evidence that is admissible, but quite another is to know how to put it together and what a good way of laying it all out would be, don’t you think?
Don’t worry! We’ve got you covered. Why don’t you check out the second part of this article for the Portfolio structure details and for some final remarks on how to validate your evidence and put it together in one single document (a.k.a the Portfolio).
Make sure to check out the whole SWE EPA series:
- SWE EPA: An Introduction
- SWE EPA: AM2 Professional Discussion & Portfolio Overview
- SWE EPA: AM2 Portfolio Structure
- SWE EPA: AM1 Work-Based Project and Q&A Overview
- SWE EPA: AM1 Work-Based Project Report Structure
Esgrid Sikahall is a Software Engineering coach at Multiverse.
