Sometimes it’s hard or against policy to rock up to a job interview and show off your latest build for a client. We therefore need to expand our own portfolio where possible, so we have examples to show of our Power Platform work.
This is the subject of Nati Turtledove’s latest ‘Power Use Cases’ series, as per his post on LinkedIn last month. I was keen to have a crack at this for a few reasons:
> Nati has one of the best Power Platform blog spaces out there, he’s also one of the nicest people in the community.
> I’ve always taken evidence of work to interviews, so love this concept to help others build to generic use cases.
> I’ve done my fair share of recruitment and like it when candidates come prepared to show off their work.
In this article, I’ll go over my build and my experiences in evidencing work as a candidate. I’ll also touch on things I look for when I’m on the interviewer side of the process.
If I had loads of time, I’d build a solution with all the bells and whistles so when it comes to interview time, I’ll knock the socks off the panel. However, I have a job, a family, other commitments and a Netflix binge habit to maintain, so I attacked this challenge slightly differently.
As well as evidencing your own work during interview, sometimes you may be given a new challenge to build for by the company you’re courting. You might have a deadline of, let’s say a week, to build a Power Platform solution and present back. I worked out that if I was given a week to turn something around, I’d have approx. 1.5hrs per evening = 7.5hrs, plus a couple of hours on the weekend. Let’s call that a nice even 10 hours of available time.
My approach therefore was:
> Stick to 10 hours build time (or less).
> Complete all specified user stories, even if only as a Proof of Concept.
> Build ‘functionality first’, making it look pretty can come later.
> Maintain best practice throughout.
> Anything I wanted to do but ran out of time to do, will be explained to show technical depth.
Requirements & decisions
In the LinkedIn post, Nati has linked to a GitHub repo with the use case, requirements and supporting files. You can find it here. Let’s break down the 5 user stories and my initial thoughts of what I’d need for the build.
“Teachers can select the class they are teaching and view all their students.“
To select a class, we’d need some kind of scheduling view as a class would happen multiple times in an academic year. There’ll need to be some filtering logic to get students equal to the class selected.
“Teachers can mark students as Absent, Late or Attended.“
This will probably be buttons or a drop down, that’ll update a collection ready to be patched back to a table of some kind.
“Teachers can view all their students attendance results when needed.“
Ok, so need a relationship of some kind between a teacher and recorded attendance for their relevant students.
“The principal should be able to view an attendance report per grade and teacher per month.“
Could be Power BI, but also like the idea of users needing the fewest amount of applications or clicks to achieve a goal. Also…
“The principal should be able to make attendance adjustments if required and needs to provide reasoning.“
Could do that in Power BI too with an embedded Power App, but I’d have to build the Power App in the first place, so just make it in the same App then.
There’s also a couple of other requirements in the blurb, so a good exercise in reading everything before just ploughing in, to make sure you don’t miss something that’s key.
My initial thoughts were 2 canvas apps. Firstly, we’d need a way for teachers to log attendance per lesson and for the principal to see all attendance records. This would need some kind of security to direct users to different screens/options depending on their role. Secondly, some kind of admin app. Whilst not specified, this to me would make sense in the scenario as you wouldn’t expect a teacher or principal to manage a student database, or schedule lessons. This would typically be done by clerical staff (at least it is in the UK), so let’s give them something intuitive too. Maybe an admin app could be done with a model-driven app, I prefer canvas so sticking to my strengths.
Build walkthrough
Step 1 is always step 1 – create a new solution. I might not be ALM’ing this one up to the max, but if I’m showing this on an interview I’ll want to show best practice.
I then need some tables. Nati has provided sample data for the majority of the tables I needed (bordered red in the image below), though I added a couple more with my potential design in mind for capturing attendance (bordered green):
I’m planning on creating 2 canvas apps, with the same look and feel for consistency. So the next step is…
Component library
I decided to bake out a default screen layout to cover a header row, name & image of the logged-on user and a navigation menu to the left. There are various input properties to cover styling, storing user details and the menu mechanics, to make it easy to deploy to any of our relating apps. This would be another best practice I’d be keen to evidence to a potential employer.
For my header row, I knocked up a dirty bit of text in Canva to cover the name of the school in the Power Use Case – ‘School of Legends’. The business logo is of a legend too, the one and only Mousa Dembélé 🐐
Admin app
The first app where our component is deployed. Each screen offers administrative abilities on each of the tables. For consistency, each screen offers the same experience; a gallery to view the records, with an accompanying form control to add new records or edit existing ones.
Form controls don’t always get the love they deserve, especially for collecting data for a handful of items. They’re also super quick to throw together to prove a concept and should be the go-to entry point for new makers to canvas apps. I sense a new blog series coming along.
Anyway, a couple of example screen shots from the admin app. Here’s the admin for utilisations, which shows what teachers are assigned to what class and grade:
Setting this up allows me to do some cascading lookups on the ‘Lesson Scheduler’ screen. Selecting a year and a subject will filter the list of available teacher(s) for that combination:
Nothing too complex Power Fx wise to make that happen; we’re simply filtering the Utilisations table where the Grade/Year and Subject matches. In the sample data provided, there is only 1 teacher per unique combination, but setting it up like that means we capture any future ones by default. Evidencing scalability in design, another important thing to showcase if you can:
Filter(
'Teacher Utilisations',
'Util Year' = cmbGrade.Selected.Year &&
'Util Subject' = cmbSubject.Selected.'Subject Name'
)
I go back to my SSRS days, always loved a good cascading lookup so nice to flex that in Power Apps every so often.
Attendance Tracker app
Do you have a handful of blogs or vlogs bookmarked, that you rely on again and again? You can remember most of the steps by now but always forget a small part? Yep, that’s me when it comes to creating calendars in Power Apps. I’ve built loads of them in canvas apps before, invariably I’ll have this brilliant post from Matthew Devaney as a follow along, or even just to sense check some logic.
So that’s the default landing page of the Tracker app. It would assume the view only shows the lesson schedule for the logged-on user. In reality, you’d have more depth to lessons that would also include duration, start and finish time, the fact a teacher could have multiple lessons a day. Again though, just proving logic:
The button for the lesson is formatted blue if the attendance log has already been submitted, orange if it hasn’t. The OnSelect property of the button has similar logic – create a new blank collection to capture data for an attendance log, or build a populated collection with data if already captured.
Once a lesson is selected, the teacher would see the following screen:
The students for the relevant class are loaded into a collection that also has an ‘attendance status’ field. This collection is built using the table where I’ll be saving the data, so the schema matches exactly which will make saving the data easier. The collection is viewed via a gallery, with 3 buttons to log attendance. Each button performs a similar UpdateIf to the relevant row of the underlying collection:
UpdateIf(
colRegister,
'Name of Student' = ThisItem.'Name of Student',
{'Attendance Status': 'Attendance Status Choices'.Late}
)
Using the collection/gallery method then makes the patch back to the data source to add all records, line by line, much simpler:
Patch('Lesson Attendance Logs',colRegister)
No Defaults, no {ID: ID}, no ForAll. A far more seamless and efficient way of patching records and, with that technique, it automatically handles both new and edits in one go. 
Another benefit of using a collection is being able to run real-time analytics quickly. Adding the attendance per student will update the graphics on the screen:
The bar charts in the bottom right are another component that I’ve built in the component library. It features a couple of labels, a button and a slider control to generate the look I wanted. Using sliders as bar charts is something I’ve done plenty of times before, including my F1 app in 2022.
As per the requirements, a teacher can’t edit entries post-submission, only the principal can do that. They’d have their own area in the app, security-driven, to see a list of all lessons. With more time I’d have done some additional filtering to only show lessons with an attendance log, or lessons in the past without a log, but none the less:
Selecting a lesson brings up the attendance log, where the principal can make changes and provide supporting comments:
Teachers also have access to a summary matrix per month, to track overall student attendance. Those with an attendance rate higher than 90% get a gold star. The principal gets the same view, only with additional filters for teacher and grade:
Not too bad for 10hrs work. I wanted to mock up some integrations with Teams to do a few automated posts & tags but got carried away with canvas fun! There’s a few other things missing but will explain them in the next section.
My interview experiences
I’ve regularly been in interview cycles whereby I’ve had a presentation to do, or build some kind of app, dashboard, example code and present back. With expected time constraints, I’ve focused on the immediate requirements/use cases first, much like I have with Nati’s Attendance Tracker scenario.
However, I still have other ideas that, time willing, would have been nice value adds or further underline design decisions/logic. If I was presenting this app back to a panel, I’d at the very least cover off 2 things at a good level of detail.
1- The tracker app will be security driven so teachers & principals only see what they need to. That’s an easy phrase to say, but how would you do it? I’ll always explain the how as well, because if I can’t show someone evidence of my understanding I can at least articulate it. So mentioning that security can be driven with security roles, dynamic AD groups, group teams etc would be my place to start, then I’d throw in a brief one or two liner as to how I’d configure those from a technical perspective.
2- Automate communications/notifications. We live in Microsoft Teams these days (well, I do anyway!), so I like to provide direct notifications there rather than email, client willing of course. I can be more granular with this too, as I’ve automated creating and replying to Teams threads with both Power Fx and Power Automate. Either way, the trick is to save the ID of the newly created post, so you have a dynamic reference to automate replies to. Articulating the techniques is great for demonstrating that difference between theoretical & practical.
Away from this specific challenge and as I mentioned in the intro, taking evidence is a thing I’ve just done for as long as I can remember. When I started out building Excel dashboards and writing VBA, interviews were in person so I’d print off good examples and have them in a folder. I extended this over the following years with examples of SQL code I’d written, SSRS reports, PerformancePoint dashboards – the works.
Now we’re in the cloud and most interviews are remote, it’s much easier to screenshare to show off a portfolio. Deciding what I would present is all part of my preparation; good examples of apps, flows, Power BI dashboards, documentation I’ve done – all ready to go along with a rehearsed ‘pitch’ for each.
Hiring manager perspective
That leads me onto the perspective of hiring. I’ve been very lucky in my career to have been given opportunities to be part of the hiring process, end to end. Rightly or wrongly, I have expectations of candidates that are in line with what I’d do. Top of the list – be prepared to showcase some of your work. Whether I get asked to or not, I’ll always prepare for the eventuality and I’d expect the same for anyone I interview.
I think this takes extra onus in the Power Platform world for a number of reasons:
1- Sharing is Caring: it is, and I LOVE being part of a community that openly shares knowledge, samples and everything else. Unfortunately for some, Sharing is also “download it and pass it off as my own”. As an interviewer, I’ll want to ask probing questions about what you’re showing me, to try and get to the bottom of whether it’s yours or someone else’s build. I love to hear about a build from the ground up and get geeky over the tech!
2- Current market: I think the Power Platform Developer market is now getting a bit more diluted. There are more and more making that jump from a Maker/Citizen Developer into a full-scale Developer/Consultant role. I fully encourage this of course and it’s a natural progression. On the flipside, someone could build one end-user app and install a CoE, make their CV look pretty and apply for every Solutions Architect role going. It’s very easy to talk about the Power Platform, but showing extensive knowledge, understanding, technical depth – that can be really tough without a solid portfolio.
3- Competition: more people are going for the same jobs, so you have to stand out. You can do this easily with a solid portfolio. When applying for roles, I’ll normally include a Word doc with a few screenshots if I can. Wet the appetite. CV’s can be dry, especially when you’re reading through 100’s of them, so give me something to grab my attention and put you to the top of the ‘to be interviewed’ pile.
A few tips
I enjoy playbacks of a candidates portfolio, whether it’s a build they’ve done themselves or been asked to do. Rehearsing the ‘pitch’ is one part, but you should also expect additional questions to come your way. In the example of this Attendance Tracker scenario, if it was being shown to me I might fire off things like:
1- please can you walk us through the patching logic for writing the attendances back?
2- how have you constructed the calendar?
3- what column types have you used in your data sources?
4- please could you show us the component build for the slider-based graph?
I’d also want to dig a bit deeper into your patterns and practices. To me, these are little things that go a very long way; it shows you care, that you know your beans, that you’ve the experience to bake these things in as standard into your work:
1- what’s your standards for renaming controls?
2- have you commented complex blocks of code? You literally have no excuse!
3- have you cleared down accessibility & performance issues?
4- what is your solution made up of?
5- are you using the Try-Catch method in your flow?
6- what would your Entity Relationship Diagram look like?
Showcasing your portfolio and deep knowledge of it can also give you a great reason to be confident and own an interview. I’ve experienced a couple of interviews where I’ve felt I’m struggling, only to turn it around by eulogising about things I’ve built. It’s a fabulous opportunity to show your passion and strengths.
Finally, it’s worth noting that the tech stack is vast and wide. This was a bit of fun for me and so I just focused on canvas apps, but I could have covered Power Pages, model-driven apps, Power BI, use of Azure components (DevOps, Service Bus, Logic Apps), custom code. Try to make your portfolio cover multiple angles, so you can pivot and showcase different things depending on the role you’re being interviewed for.
To conclude
Interviews are a fantastic space to geek out over common technology and use cases. Take pride in collating and showing a wonderful portfolio of work, it’s a great way to make yourself stand out as a viable candidate. Be prepared to answer questions and celebrate your amazing skills!
Thanks to Nati for putting this idea out there. If you’re not already doing so, I highly recommend you follow his content via his blog, Twitter or LinkedIn.
