Bad Interview Answers 🔗
Learning Objectives
Preparation
Grab a list of common interview questions from somewhere like Coursera.
Please set a timer for 15 minutes.
Introduction
Let's energise
🎯 Goal: Let’s wake up and have a laugh (15 minutes)
1. Interviewer: Cold call a random person and ask them an interview question. Choose an ordinary question.2. Interviewee: You must give a terrible answer to this question (keep it clean, please!). Then cold call another person to be the interviewer.
3. Interviewer: Give absolutely straight-faced feedback. If you laugh, you’re out and must nominate another player to complete your feedback and return the game to step 1.
Goal of the Portfolio Module 🔗
Learning Objectives
Preparation
Must have done the prep work for this module
Prep for the exercise on the day:
One person volunteers to ask the questions and choose who is answering them. You can ask each question several times.
But choose a different person every time. We must hear different voices!
Set a 15 minute timer and wrap up promptly.
Introduction
What are we doing in the Portfolio Module?
🎯 Goal: Align the knowledge of the group about what we are trying to achieve (15 minutes)
In one big group, let’s make sure we all understand the Portfolio Module’s goals.
Questions to be discussed:
- What are you doing in the Portfolio Module?
- Name one of the module success criteria, and why it is important?
- How long is the Portfolio Module?
- How can you help make the Portfolio Module a success?
📏 Ground rules
Learning Objectives
We’re going to start off by defining rules and expectations for working on projects during this module.
📐 Ground rules
- We go together
- Do one project at a time
- We will put in the time - 25 hours
🏗️ Projects
- We start a new project when everyone has finished the current one
- We can work as individuals or in groups
- “Done” means “Good enough to show an employer”
- 1 great user story is better than 10 meh user stories
🗣️ Communication
- Post a link to your deployed application by midnight at the end of every Thursday
- If everyone is ~done, we’ll start a new project on Saturday
- If you’re not done, LIST YOUR QUESTIONS AND BLOCKERS
- But don’t wait until Thursday to get help
- We are flexible to people’s needs: but you must express your needs
Reviewing and improving goals 🔗
Learning Objectives
Preparation
Introduction
SMART quick-fire questions
🎯 Goal: Ensure the group has the same knowledge about SMART Goals (5 minutes)
Let’s quickly answer these questions.
- What does the S.M.A.R.T stand for?
- Why do we use this acronym to help set goals?
- Name some benefits of setting SMART goals over non-SMART goals.
Reflect on the previous exercise
🎯 Goal: Share the insights of the smaller groups (10 minutes)
Return to the main group and discuss any common themes or challenges that came up in the small groups.
Some questions that can help you guiding this discussions are below"
- Were most goals SMART, or did they need to be improved?
- Did most of your goals align with your Weekly Activity plan?
- Does having SMART goals make you feel more confident in your chances of success?
- What were the common themes that came up as barriers to success?
- Do you share many of the same barriers?
How can we support each other?
🎯 Goal: Identify resources to support trainees to achieve their SMART goals (15 minutes)
Discuss as a group what solutions and support are available for trainees to overcome these challenges.
Questions to be asked:
- What resources were identified to help overcome these?
- What can the community do to support you?
- What can other trainees do to support you?
- What can you do to overcome these barriers?
- What should you do when you get blocked by one of these barriers?
- How can you help when these barriers block your peers?
Morning Break
A quick break of fifteen minutes so we can all concentrate on the next piece of work.
Understanding Requirements
Learning Objectives
Communication is hard. Today, let’s explore some ways we communicate with each other in software development. It’s not enough to draw a picture of a website and assume the other person will build what you imagine. It’s never a good idea to assume shared context or shared interpretations.
So how do we understand what to do? By understanding requirements.
Formalising Requirements
Today we’re going to think about requirements. We’re going to ask these questions:
- why we’re working on a project
- who we’re making it for
- what they’re going to use it for.
Before starting to solve a problem (how), step back and ask yourself those why, who, and what questions.
We’re going to think about a few projects and discover some requirements. This is really important in order to do technical work, but you don’t need to have any coding experience, or be thinking about coding, when doing this.
Remember
Understanding Requirements
Learning Objectives
Imagine a coursework tracker
As trainees, you have coursework to do. Imagine a website which tracks how coursework is going for you all. Thinking about that website, some user stories could be:
- As a trainee, I can ask for help with a topic or task.
- As a mentor, I can see who needs extra support.
- As a trainee, I can see what coursework I need to complete and when.
- As a mentor, I can see what coursework has not been completed.
These each take the form “As [who], I can [what]”. They don’t say why yet.
Exercise 10 Minutes
In groups of about 5.
Talk about why the “who” is useful. What would we be missing if we didn’t think about the “Who”?
Now think about the “why” for each of the listed user stories. Why are they important?
As a [who], I can [what] so that [why]
Exercise 10 Minutes
Write some user stories for our coursework tracker on a Jamboard.
Think about the “who”, “what”, and “why” for each.
You can think of new “who"s (e.g. the people who write the coursework questions), and as many “what"s as you want - but make sure you remember the “why”.
Reflecting
Key Term
10 Minutes
Why is thinking about user stories useful?
What’s useful about thinking about the “who” and the “why”? What could go wrong if you don’t think about them?
🔎 Gathering requirements
Learning Objectives
In addition to [who] and [what], good user stories also include [why]
As a [who], I can [what] so that [why]
Choosing a project
ℹ️ Use this section if you’ve not already chosen a project
Explore and discuss
🕥 Time: 30 minutes
- A set of project briefs are available here 👉 https://drive.google.com/drive/u/0/folders/1UocnK_dRUkMCuwI6aytZ0Z9a12322EOx
- Split up into pairs
- Each pair choose a project brief. Make sure you choose different ones. Don’t spend too long choosing 😄
📖 Read
Read the business problem carefully
Read ( if there are any ) the user stories carefully
❓ Questions
Answer the following questions:
Do you have any domain knowledge on this project?
Will you need to do more research to understand this business problem?
Does the business problem make sense? Can you explain the business problem in your own words?
Are there user stories for your chosen project brief? If not, sketch out some user stories.
If there are already user stories, check they make sense. Can you think of any more? Can you imagine the users of this application needing the stated functionality?
Does this project interest you?
Reflect and decide
Discuss
🕥 Time: 10 minutes
Get back together as a team.
Get one person from each pair to explain in their own words what the project brief is about.
Explain why you think you should do this project.
Decision
🕥 Time: 10 minutes
As a team, decide on which project you’re going to implement.
Community Lunch
Every Saturday at CYF we cook and eat together. We share our food and our stories. We learn about each other and the world. We build community.
This is everyone’s responsibility, so help with what is needed to make this happen, for example, organising the food, setting up the table, washing up, tidying up, etc. You can do something different every week. You don’t need to be constantly responsible for the same task.
🕹️ User Interface
Learning Objectives
As a team, you need to start thinking about and designing the user interface.
To focus your discussion, keep these two things in mind for your UI:
Sufficiency
Sufficient means enough for a given purpose. Your user interface should provide enough functionality or data for users to achieve their goals.
Simplicity
Simple means easy to understand. Think of the number of times you’ve used a website and it’s been impossible to find the things you need. Your user interface should be simple and intuitive. Users should be able to figure how to navigate and use the user interface with minimal effort.
discussion
🕰️ Time: 20 minutes
Split into pairs.
Each pair, choose a different user story.
Work on the following tasks, remember to focus on sufficiency and simplicity.
- What kind of pages will you need?
- What are the key components of this page (inputs, forms, buttons, cards, etc)
- Ensure you can clearly define the purpose of each page and its components
- What kind of data will you need to expose in this view?
🖼️ Wireframe
discussion
🕰️ Time: 20 minutes
Create some wireframes for the pages you described in the previous section
If you’ve not made wireframes before, check out this guide to help you come up with some ideas: https://balsamiq.com/learn/articles/what-are-wireframes/
🪞 Reflect and check
discussion
🕰️ Time: 10 minutes
Now swap wireframes between each pair.
Check the following:
Does the proposed interface meet the requirements for the user story?
Is it sufficient?
Is it simple?
🗃️ Data
Learning Objectives
For your application to work, your user interface will interact with other services. These services provide data and ways to update this data via the user interface.
Here are the kinds of things these services may do:
📖 Reading
A means of reading data. The user interface might fetch data from some external source and render it in the interface.
💾 Persisting
A means of persisting changes. Users will need to create or update existing data. For example, a user might need to create a comment on an article. Another user may need to update the like/dislike on an existing comment. In each of these cases, any changes are persisted in a database. The user interface enables users to read and persist data without worrying about the
Discuss
What are the key components of the application, how are they connected, is it a static or a dynamic application, what kind of data are you storing?
What sort of data does the client application need - what kind of data is it fetching?
What is the purpose of each component in your application, how will it communicate with other components in the architecture?
How do your different pieces of data relate to each other? If you’re storing things in a database, what tables will you need, and what relationships will there between the tables?
Afternoon Break
Please feel comfortable and welcome to pray at this time if this is part of your religion.
If you are breastfeeding and would like a private space, please let us know.
🧩 Break it down
Learning Objectives
You’ll need to break up your user stories into manageable units of work.
Breaking down tasks into sub-problems is challenging: we often don’t know in advance how challenging the sub-problem will be. However through iteration, practice and feedback we can continue improving how we break problems down.
🎟️ Issues
You can keep track of work using a GitHub project board as you’ve done throughout the course.
Write your issue
⏰ Time 20 mins
- On your GitHub project board
- Create a new issue
- Set the title to the user story you just chose
✅ Acceptance criteria
If you’re working on something, then you need a definition of “done”. In other words, you need to have measurable criteria for knowing when you’ve completed some task. Acceptance criteria are the requirements that must be met for a unit of work to be considered complete. Most often you’ll ue acceptance criteria to decide whether a user story has been implemented. Here are two ways of expressing acceptance criteria:
- Scenario-oriented (the Given/When/Then template)
- Rule-oriented (the checklist template) and
🫱 More detailed information on writing up acceptance criteria.
Note
⏰ Time 20 mins
- Choose one user story
- In pairs, come up with acceptance criteria. Decide on scenario-oriented or rule-oriented acceptance criteria.
Prep the work for the week 🔗
Learning Objectives
Introduction
Planning the next steps
🎯 Goal: Have a clear plan for the team (10 minutes)
Considering all the work done today, what are the next steps you must take as a team?
Some prompt questions that might help if you haven’t discussed them yet:
- Who will raise which tickets?
- Who will set up the meetings?
- Who will work on which tickets and how will we know?
- What time is the best for pair programming?
- What questions do you have?
- Are you confident about what you must do from tomorrow?