Last updated
Welcome to Labs! 🎉
You've made it to the final unit at Lambda School—no small feat. You've worked hard to get to this point. You've taken in an immense amount of information in a short period of time. You've learned new concepts, new terminology, and new ways of thinking about software.
Now you're ready to put it all to the test.
Labs is different from what you've done at Lambda School up to now. Here, you'll:
build real software for a real nonprofit or cause organization
work in a team environment to make foundational decisions about your product
gain experience walking through your work to succeed in interviews
This course lays out everything you'll need to get up and running in Labs, start making contributions to your product, and set off on your path toward graduation.
Let's go! 🚀
cHow Labs Works
Often, when we're talking about how something works, it's useful to first examine its structure.
The structure of Labs is designed to set you up for success and arm you with the practice and experience you'll need to land a job.
When you applied for Labs, you got a brief overview of how it works. Let's revisit now that you're here 🙂
Here's a handy diagram of the people in Labs.
First, you'll notice the main Labs Managers—a Product Manager, Engineering Manager, Data Science Manager, and Design Manager. They're your instructors in Labs, and they're here to provide you with instruction and support.
Next, you'll notice Release Managers. Your team might be one of several working on a product, and that product's codebase will be maintained by a Release Manager. Your RM will determine what code makes it into the project and will provide you with feedback on your code and how you walked through it.
You'll also have a stakeholder in Labs—that's the real-world nonprofit or cause organization you'll work with to build a product for social good. They'll set the product direction in concert with your Labs Managers, the Release Manager—and you! You'll meet regularly with them to present your progress, ask questions, and align on the product vision going forward.
Finally, you'll notice the bottom row in the diagram. That's your team. You'll work with the other roles on your team to scope each sprint, execute your plan, and ship your software.
Your main job in Labs is to work with your team to build software. You'll find everything you'll need to do to make this happen laid out in the job description for your role and your courses in Canvas.
In order to pass Labs and graduate, you'll need to achieve all of the objectives for your role—you'll find them listed in your role's description. You'll also find a blueprint in Canvas breaking down exactly how to pass Labs in four sprints. It will take at least four sprints to complete your objectives—and you'll be able to extend your time in Labs up to eight sprints total to achieve them all.
Some of your objectives involve pull requests—submitting your code for review on GitHub, with the goal of getting it successfully merged into the project. With every pull request you make, you'll record a (very) brief video walking through your work, giving you practice that will pay off when you're interviewing for jobs. Your Release Manager will give you feedback on your submissions, setting a high bar but empowering you with ways to level up.
Your final sprint in Labs is the sprint you complete all of your objectives—you'll finish that sprint with your team, then head into Job Search!A Portfolio of Experiences
You might be inclined to think of Labs as a "capstone project," with the goal to produce a project to include in your portfolio. This is not exactly the case.
In some ways, Labs is like a capstone project—it's a final, culminating experience where you put everything you've learned into practice. It's a shift from theory into experience. You'll produce something real.
But ultimately, Labs is really not about creating something to add to a portfolio. This is because you don't need a running application to demo in an interview.
Instead, your skills, experience, and code contributions _are_** your portfolio.**
Software engineering (data scientists are software engineers, too!) is a collaborative exercise, where team members contribute their skills, experience, and time to collectively create a product. When you're being evaluated as a candidate for a role, your skills, experience, and contributions are the focus. The products that you've contributed to are rarely themselves important (particularly for entry-level positions).
The units prior to and Labs have given you the skills you need to succeed in Labs and beyond. You'll also learn many new skills, tools and technologies during Labs.
It's important to catalog every language you've learned and every framework or tool you've used while in Lambda School. You should be able to speak to and demonstrate each of these skills during an interview.
👉 The list of technical skills (languages, frameworks and tools) you've learned while in Lambda School is part of your professional portfolio.
It's been said many times, but that's because it's important: being successful as a Software Professional requires technical skills and teamwork skills. Teamwork skills come from work in teams while you observe, learn, and grow from the challenges that are inevitable when working in groups.
Hiring managers are very keen on hiring candidates that are not only technically skilled, but also understand how to work effectively within a team environment. Labs exists as a significant part of Lambda School to help you experience working in these team environments so you can build the soft skills required to be successful.
The experiences you've had as a team member during your time in Lambda School are especially important to hiring managers. Be sure you can articulate the positive experiences you've had on teams, as well as the challenges you've faced and how you helped your team overcome those challenges.
👉 The positive as well as challenging experiences you've had while working on teams is a part of your professional portfolio.
Your technical and soft skills come together in the form of contributions. Hiring managers will likely browse your GitHub profile to see:
How much code you've written. Do you push code regularly?
How well you write code. Is it well structured, clean, logical and readable?
How well you collaborate. Are you opening Pull Requests with good descriptions and discussions? Are you contributing to code reviews and other pull requests?
The code you write during your time in Lambda School will be linked to your GitHub profile. Those contributions, especially during Labs, will likely be assessed by the members of a hiring committee that are vetting your application.
👉 The code you write and how it is contributed is a part of your professional portfolio.
Both in Labs and on the job, your work will follow (or at least be a critical part of) a repeating cycle: the software development lifecycle (SDLC).
In 2001, a group of software developers got together and penned the Agile Manifesto (Links to an external site.) (yeah... that's how webpages looked in 2001). The Agile Manifesto put forth some key concepts for what to prioritize during software development:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
In short—bias toward action, in small, management chunks of work, and remain responsive to the many sources of change that will throw wrenches into even the best-laid plans.
You might also hear agile methodologies called a "lean" approach to software development. The idea is that, sure, we could try to produce a really detailed plan with steps looking ahead a long period of time ("waterfall" development) and/or build everything at once (sometimes called "big bang" development)—but ultimately, it's much faster, easier, and more effective to iterate—repeat a very short, very simple series of steps, with each cycle building on the last.
That cycle is the software development lifecycle, and with an agile approach, it's short and sweet.
Ultimately, all types of software development will follow a cyclical pattern. There are many different ways to think about the stages of the SDLC, but for our purposes in Labs, let's go with these:
Planning: Determining what to build
Designing: Determining how to build it
Building: ...I mean, yeah, actually building it
Evaluating: Determining how the process went (including testing)
In agile development, each cycle is a sprint, and we go through each stage during each cycle. Rinse, repeat.
In Labs, you'll follow this cycle by:
Planning: Working with the Technical Project Managers on your team to scope each sprint
Designing: Working with all roles on your team to develop lean artifacts like diagrams, API contracts, and implementation plans
Building: Collaborating cross-functionally to write code and deploy infrastructure
Evaluating: Writing unit and integration tests, looking back on the sprint for lessons learned, and factoring those lessons into the next cycle
Ok—now you know how Labs works, the goal of Labs, how the SDLC works, and where to find the Labs standards. But what does success in Labs look like—and how do you achieve it?
Get ready to hear this over and over from here on out: communication is the key to producing great software. If your mind goes blank in an interview and there's only one word you can remember, make sure it's "communication."
Communication comes in many forms:
You'll need to communicate with your stakeholder to present your progress in detail; ask targeted, clarifying questions; and emerge with a solid vision of their user requirements.
You'll need to communicate with your Product Manager about the scope, objectives, and priorities of your product.
You'll need to communicate with your Design Manager to collaboratively approach design problems and iterate solutions.
You'll need to communicate with your Engineering and Data Science Managers for guidance on implementation and to resolve issues (after first troubleshooting with your team!).
You'll need to communicate with your Release Manager by walking them through your pull requests and reaching out for support.
You'll need to communicate with future developers on your product by including solid documentation.
But most importantly, you'll need to communicate cross-functionally with your team (and across teams!) to keep development moving forward in unison.
Do all of these throughout Labs, and you will succeed.
In virtually every way, Labs is designed both to equip you to land a job and to prepare you for the job itself. (What use would it be to be able to get a job, but not keep it?)
Professionalism factors into both of these critical goals. Ask yourself: what does professionalism mean to you?
Many factors contribute to professionalism in the job search and in the workplace, but here are some of the big things to focus on in Labs to prepare you:
Show up: Be here, and treat Labs like the full-time or part-time job it is. Don't leave your teammates hanging.
Cameras on: Have you ever spoken to a Zoom room full of faceless squares? Your instructors have 😞 But you know what? We can take it! A hiring manager, on the other hand... In Labs, you'll need to keep your camera on to practice the level of interaction a hiring manager will expect.
Participate: Speak up during meetings, ask and respond to questions, commit code every day, and engage critically with your project and the curriculum. This will help by getting you in the habit of doing the same kinds of things on the job.
You'll meet regularly with your product's stakeholder throughout Labs. Your Release Manager will lead these meetings, and you'll have opportunities to participate actively in them.
The goals of a stakeholder meeting are:
Present progress
Ask questions
Align on a vision going forward
Make sure everyone on your team is prepared to walk through what they've been working on if necessary
Make sure everyone on your team understands how their tasks tie into the product goals and solve user problems
Make sure your team has generated a list of questions and submitted them to your Release Manager
During stakeholder meetings, remember the 3 Ps:
be Prepared
be Positive
communicate Progress
As with everything in Labs, be sure to focus on professionalism in stakeholder meetings as well—have your camera on, don't interrupt—but most importantly, participate. (Hm—maybe there should be five Ps... 🧐)
You're here to gain experience, which comes through practice. You know what practice means? Failure.
You are here to fail. Meditate on that for a moment.
From here on out throughout your entire career, you will fail. Over. And. Over. Again.
And that is what you want. The reason it's what you want is because it's the only way you can actually learn and grow, expand your skills, and level up.
Labs is your opportunity to learn how to fail in the context of everything else you've learned up to this point. Take advantage of it. Get comfortable with fear and the unknown. Reach out to other people to work through problems together. Use all the tools at your disposal without hesitation—but especially failure.
We're thrilled to have you with us in Labs, and we look forward to working, failing, and learning together with you 🙂
