Activities: what questions do you have about the activities that a software developer does on a daily basis?
- I've been told that you often spend more time reading code than writing it, could y'all elaborate? I'm interested to see how that actually looks in a professional environment like this.
- What does y'all's workflow look like? We've been trained on using git vcs, was wondering how much that differs in a production environment.
- Do y'all practice TDD? How does testing fit into the workflow?
Environment: what questions do you have about the overall environment and culture of this workplace?
- How have y'all been maintaining the company culture as we've transitioned to being more remote?
- How has the workflow changed since y'all have gone remote?
Interactions: what questions do you have about the team at this company? What do you hope to see in your interactions during the shadow?
- In general, what does the day to day workflow look like with the full dev team?
- I noticed from y'all's site that the company offers two distinct products - do two separate teams work on those products? Does everyone bounce back and forth? If y'all do touch both products, what does the workflow for that look like?
Objects: what questions do you have about the code or the product?
- What stack do y'all use? Could you elaborate on what y'all use on the front end and why?
- To confirm, y'all's products are logistics platforms, one for recruiting and one for managing the logistics of ongoing research?
Users: what questions do you have about how the company interacts with their users?
- The platforms y'all offer are pretty unique - do y'all work on a case by case basis with each of your clients? It seems like User Interviews serves a pretty wide array of companies.
Activities: what was engaging to the person/people you shadowed?
In general, just talking about the technologies that we were using and how our workflow has changed over the years. She actually gave me permission to control her screen, so we talked through our problem solving processes as well and she helped guide me through her typical workflow - she was super interested in seeing how I went about solving the problem.
Environment: what did you notice about how they talked about the culture and environment of this company?
They're a relatively small, younger company (30ish employees), in the middle of a big expansion process. It was interesting hearing them discuss the changes they were anticipating in their workflow - prior to the expansion, everything seemed very personal, and they had a lot to say about their culture and inside jokes. It was interesting, because the person I was shadowing had just come from a very large company (oracle), and she was talking a lot about the differences in processes and ownership of the product. The culture at the place I was shadowing at comparatively was very intimiate.
Interactions: what did you notice about your interactions with this person/people?
They were all super friendly and open about their opinions on the workflow - again, the company was relatively small and tight-knit, so it was interesting seeing all the inside jokes that they had about pretty much everything. It was a very humanizing experience, for sure.
Objects: what did you learn about their approach to code and/or product development?
They followed a pretty standard workflow - the teams were broken up into groups of 4, comprised of 1 PM, 1 designer, and 2 engineers. At this company size, the engineers did a lot of full stack work, working with all parts of the platform. They used git vcs and were encouraged to follow TDD practices - all in all it felt very similar to the kind of work that we're already doing at Turing (minus the full stack part - they were using a React/Ruby stack and I still don't know too much about Ruby).
Users: what did you learn about their approach to their users?
It's really interesting, their platform is designed for UX researchers - they talked a lot about different use cases and what considerations they would take when designing certain user flows. Their approach to designing for different use cases seemed very regimented, and the way the person I was shadowing described it, seemed especially useful since the devs actual kind of wore design hats as well.
What are your main takeaways from the shadow? How will you use this information to help you with your job search strategy?
A BIG takeaway was the consideration of company size in my search - it'll depend on how much of the product I want to get my hands on. If I want a more focused, regimented experience, I'll want to work at a bigger company, and if I want to dive in and possibly expand my responsibilities a bit more I could work at a start up - both have their advantages and disadvantages.
Another is the expectations involved with full stack work - I'd have a lot of catching up to do, at least with where I'm at right now. I'm beginning to realize how much fun full stack is, though, so I'm glad I got the exposure to it.
Interview Prep:
Pick a successful project and write about it with the STAR method (What was the situation/scenario of the project? What was the task/target of the project? What action steps did you take? What were the results?):
One of my favorite projects that I've had the opportunity to work on was a recreation of the card game SlapJack with HTML, CSS and JS. It was our final solo project for our first quarter at Turing, so it was the culmination of everything I got to learn early on, and the first time to really show that I had a grasp of the fundamentals.
I jumped right in - and all in all, it went pretty smoothly. I set some goals for myself as far as writing clean, reusable, dry code, and I'm proud to say that I met my goals. The project ended up being a solid pass, and it's now one of my portfolio pieces to demonstrate my understanding of the fundamentals.
Write about a time you failed and what you learned from that experience:
Recently, I participated in a group project in which I believe I failed to advocate for myself enough. By not advocating for my thoughts on the app architecture, I ultimately ended up working around a codebase set up in a manner that didn't fully understand, and it snowballed into a few technical problems later on. These were all ultimately resolved, but I believe the collaborative process (as well as my personal development process) could have gone a lot smoother if I had just been more vocal early on.
From this experience, I've learned first hand the importance enabling everyone in the team to have their opinions heard - and to not be afraid to make mine be heard, as well. Doing so ultimately makes the whole process go smoother, and will ultimately lead to a stronger product, stronger codebase, and a happier team.
Write about how you’ve approached working with a team using a specific example:
Within a team, I do my best to fit whatever role is needed - if the team needs a facilitator, I can facilitate. If someone else is facilitating, I'll do whatever I can to fulfill the needs of the process laid out in front of me. I'm all about keeping things moving.
As an example, in my second quarter at the Turing school, I was a part of a group project with a team of 3. The goal of the product was to take an existing codebase and refactor it to maintain the same functionality while cleaning up the codebase. Given that this was a workflow that we as students hadn't done before, there was a lot of uncertainty as far as first steps go.
The team dynamic quickly found a rhythm - we had one group member that was fairly quiet and neutral in their approach to the workflow, so the other two of us would alternate as facilitators and propose our thoughts about the next best steps.
This pattern of working with a group (finding a rhythm, facilitating when needed) is something that I've noticed I do in most group settings now.
What other stories will you prepare to share?
My customer experience may come into play as well - working as a security officer, and as a cashier. I can speak to a lot of customer interactions and experiences. I'll need to do some reflecting to remember specific scenarios that would come in handy for interviews, but I know there's a lot of interesting stories there.
Do some research into your top companies’ tech stacks; what do you already know? What can you compare to your own learning? What do you need to learn more about?
A lot of what I've seen is a stack that uses React on the front end and Ruby on the back end. I'm familiar enough with javascript frameworks and libraries (from FE to BE, things like React on the Front-end, Express and Node on the back-end), but I really want to expand my horizons beyond javascript.
Using this interview prep resource doc, pick out at least 3 resources you will use to prepare for interviews as well as 3 behavioral questions you could practice:
Resources
- Definitely going to use Ian's site.
- The tech interview handbook or the front end handbook - will start with the former
- Watching old interviews from interviewing.io!
Practice Questions
- "Why should I hire you?" - this question scares me the most, to be frank. I don't have a 100% solid answer for this yet - not that I'm not confident in my abilities, but rather I'm not 100% confident in articulating those abilities. Also, the idea of an elevator pitch kind of freaks me out.
- "Tell me how you solve a problem." - I think that on the fly my answer for this would be too vague. Need to do a bit of reflection to give a concrete answer.
- "What is your biggest weakness?" - including this one because I think about this question a lot and still haven't decided on a solid answer.