DEV Community: Danielle Thompson

#GettingBetter at Interviews: Important Q's to Ask During your Developer Job Interview

Danielle Thompson — Mon, 28 Nov 2022 00:37:57 +0000

Getting your first job as a junior software developer is often an incredibly stressful and emotionally taxing process, as is interviewing for developer roles. There are frequently multiple rounds of interviews with a number of different people in a company, and it was hard know what to expect from company to company and when I could expect a technical interview versus a recruiter interview, for example, so that I could prepare as efficiently as possible for the appropriate stage of interviewing. While I was going through my own process of securing my first job in tech, I came up with a list of questions that were important to ask to show that I was engaged in the interview and get the information I needed to determine if the company was a good fit for me.

Over time, I learned some questions worked better at various stages of the interview process or with specific people in the hiring chain. I'd like to share those questions with you and provide some basic illumination to what interviewing for a developer role looks like in the first place, so that you might better prepare for your own interviews and land that first role in tech. And really, this list isn't just useful for entry-level roles, but, rather, many of these questions can be adapted and used throughout one's career.

First off, it's worth mentioning what a full round of interviewing often looks like in the first place. If you have not yet worked in tech before, the duration of interview phases is robust and the process unknown before you go through it a few times. Generally, there will be 3 to 5 interviews to get through before you know if you have an offer or not. (It's a lot, I know!) The first interview often will either be with a technical recruiter if the company is large enough, or it might be with someone from HR if the company is smaller. Occasionally, I've had my first interview be with the direct hiring manager though!

The next step in line is often with the hiring manager, who you would be reporting to on a team. Sometimes, this phase will include a technical exercise small enough to be explored in the course of the 30 or 60 minutes scheduled that day ("whiteboarding"); sometimes, it will be more of a getting-to-know-you interview with some technical questions peppered in along the way.

Rather than doing "whiteboarding" live with a hiring manager, some companies prefer to give take home coding problems that can then be reviewed and discussed at a later stage of interviewing. Occasionally, the technical portion of an interview could be working on an additional feature or bug in the code you come up with after a couple of hours of working on a take-home challenge. (Make sure not to spend too much time on these - no more than a couple of hours!) Occasionally, (really good, imho,) companies will have you work on a current problem or bug they have in an existing live project with them, both to give you a real example of what you could be working on and to see what you can do.

There is also often a portion of interviewing where you get to meet other developers on the team. Sometimes this can include some technical pairing work. If you get to meet other potential team members, this is a great opportunity for you to get a feel for how they feel about their role and the company, and to see if you "vibe" with your possible future colleagues.

As I said before, different companies have all sorts of ways to run interviews, and there is certainly variation in the order of which interviews are done when, but the above outlines a pretty common trend of interviewing scenarios right now.

Now for those questions - let's dig in!

(Often Preliminary) Interview with the Recruiter

The main priority for you is to get a general feel for the company culture, structure, etc. For the recruiter interview, you want to focus on simply proving you’re a human who is pleasant enough to talk with, can work with others, can do the basic requirements of the job, etc.

What is the company culture like? What is your favorite thing about the company culture?
Is this a new role, or one that already existed? If the latter, what are you hoping to see from the next person to fill this role that was missing in the last?
What is the current market/audience of Company Name? What is important to those users/customers?
Where do you see the company heading in the next few years?
What is the organizational structure at Company Name?
How big is the IT/engineering department?
(You should already have an idea of who the executive/board level leaders are, but ask something like…) What are the top priorities and values of the upper leadership for the company?
What are the major projects the engineering team is working on?
What is the tech stack?
Is the work environment collaborative or independent
Transition to covid - how has that been? What has that looked like for the company?
From what you know about the role, what are the characteristics of someone who would succeed in the role?
What does success look like for this role?
LAST AND INCREDIBLY IMPORTANT QUESTION - What are the next steps in the interview process? (You will want to get as clear of a picture for the remaining interview stages as you can so that you know what you need to prepare and when. Honestly, this question is valid to ask at the end of every interview stage; altering this question slightly to confirm what you understand the next phase of the interview is also valid.)

Interview with the Hiring Manager/Dev Team

Wherein the most important objectives are to demonstrate competency for the position, your humanity, and where you will typically discuss some technical topics. Your objectives are to dig into getting a better feel for what the engineering department/team is like, what your manager would be like, what the work you’d be doing would be like day-to-day, as well as to demonstrate to the hiring manager that you are pleasant to work with and capable. Remember that capable doesn't always equal "can do the job in full down to the letter"; capable almost always encompasses "can learn and grow within my role" as a developer. Since there are often more than one interview rounds with technical folks, I will break up these questions as needed between interviews.

What tech stack do you work with? (It's OK to repeat this question from the interview with a hiring manager; more often than not, the hiring manager will be more technical and have more accurate and more specific information about the tech stack than a recruiter will, but you still want to make sure the basics of a tech stack align with what you're looking for in a first interview with a recruiter to make sure the job is a good fit for you.)
What does the day to day look like?
What are the major goals and projects for the engineering department/team? What projects would I be working on?
Top goals for my first 3 months / 6 months / 1 yr
Is this a new role, or one that already existed? If the latter, what are you hoping to see from the next person to fill this role that was missing in the last?
How is my performance evaluated? What are your practices around performance reviews (how frequent) and code reviews?
What does the promotion cycle and process look like? What’s the average time someone spends working towards a promotion?
What is your management style?
What kind of mentorship is available to me as an associate dev, and how is that executed day to day?
Walk me through the process of an engineer picking up a ticket to getting code merged into production.
What's a mistake that you made during your time on the team? How was it handled?
What's the median age that a PR is open for?
What does the onboarding process look like?
Any pair or mob programming? How frequently?
What is the feature release schedule like? Any important annual dates to be aware of?
Who is responsible for the UI/UX design and how are those design goals relayed to the engineering team?
How does testing/QA work? What kind of testing (TDD) is required?
What kind of security practices do you require or request for the engineering department?
What kind of accessibility practices do you employ, or standards that you set around accessibility?
What is the current market/audience of Company Name? What is important to those users? Who is the company trying to reach through marketing?
What does a career trajectory look like at Company Name? What do I need to accomplish in order to grow my career?
Transition to covid - how has that been? What has that looked like for your team?
VERY IMPORTANT Q (use at tail end of interview) - What would I need to accomplish for this to be considered a successful hire?

While thorough, this list is not exhaustive. It can give you a very solid place to work from for interviewing for dev jobs though. With many interviews being virtual nowadays, I am in the practice of pulling up my Google Doc of interview questions on one of my screens next to my virtual interview space. This helps me to stay on track and not forget any important questions while I'm trying to keep my cool and manage any nerves that inevitably arise.

Shout out any additional questions you have found to be valuable to developer interviews in the comments to keep this list going! :)

#GettingBetter at Recognizing your Accomplishments as Junior Developer (and Beyond)

Danielle Thompson — Sun, 27 Nov 2022 23:08:49 +0000

In my first several months as a junior developer, everything was brand new and intense. Expectedly, most days I was overwhelmed by the amount of information being thrown at me and the breadth of everything I had to learn. I was very motivated to do my best to learn quickly, not only so I could become a productive, valuable contributor on my team, but also so I could put intention towards getting a promotion.

Going through the first 6 months of my first position was an emotional roller coaster. Some weeks I felt like I was learning and moving fast, and that I was contributing more and more to deliverables for my team. Other weeks, however, I felt like I hadn’t contributed anything, even if in hindsight, I was still learning a ton even when I wasn’t writing many lines of code. Looking back, I can see now that, sometimes, progress as a developer can be hard to mark and internalize, especially when I felt like I was just trying to keep my head above water with everything I had to learn and know.

I also had a big goal of working hard towards getting “junior” out of my title to achieve a promotion to a mid-level engineer position. Being able to demonstrate my ongoing accomplishments and increased capacity for more labor-intensive work would be important to make this happen. This certainly added pressure to my work flow, knowing I wanted to show that I could handle more responsibility soon. One thing I came to realize though, too, working on a small team at a small company that had only ever had a single junior developer before, was that there wasn’t yet a lot of structure or metrics in place to determine how a junior developer could accomplish getting promoted.

At some point while working towards this goal and struggling with the emotional ups and downs of growing in my role, my partner (who is also in tech but further along in his career than me) shared an experience he had had that he felt could help me as I worked to feel confident in taking on more complex problems at my job. One of his new reports expressed they were having a hard time emotionally at work. This person was still relatively new in their career as well and had started working on more complex problems within their role. They were delivering what needed to be delivered and doing good work, but they didn’t feel like they were doing well because the pace at which they moved now was slower. Because they weren’t shipping as regularly as they used to, they were struggling in their confidence to feel that they were doing enough to contribute to their team. This simply wasn’t true. Taking on more complex problems requires more time and effort than solving small, concise problems will, but generally provides greater benefit to a company and its customers. While talking with his employee, my partner realized that it was important to provide structure and opportunity for more junior employees to have regular “wins” to keep morale up, while also gradually building them up to be able to tackle more intensive problems. I, too, felt the growing pains of being able to take on more complex problems but the loss of feeling like I had accomplished something daily or weekly because the number of my “wins” were fewer, even if the weight of the wins I did have was greater.

I came to realize that I wasn’t doing a good job of seeing my accomplishments and growth as they were happening. I needed to find a way to do so, so I set out to create a system that would help me build confidence and recognize wins as they happened. Simultaneously, I knew I needed to keep better track of my accomplishments to share with my direct manager that could provide clear evidence through metrics to support an eventual promotion. In order to do this, I came up with a simple but valuable reflection template - the template you will see below - with a mix of qualitative data and quantitative metrics that I used to track my professional growth and work contributions at the end of the week every week while the details of the week were still fresh in my mind. Eventually, I started my reflections earlier in the week and added to my weekly reflection as I recognized that I was doing or had accomplished something I wanted to mark. Doing so regularly helped my confidence as a junior developer immensely. No longer would I float through weeks, feeling like I had contributed or grown little. No longer would my brain miss all the ways, big and small, in which I was moving along nicely in my professional growth.

Weekly Reflection

Date: _______________
What did I learn this week?
What goals or deliverables did I complete?
What did I find challenging?
What areas can I improve on?
How did I support others?
What is one (+) thing I should do next week that would make the week successful?
What do I want to learn next week?
Metrics
Pairing/collaboration count: ________
Total Points Worked on this Week: _________
Tasks deployed: _________
Bugs fixed: _________
PRs opened: _________
Any other metrics worth mentioning:

A couple of things are worth explaining briefly in this template, namely, in the metrics section. My team uses a task management system within two-week sprint cycles where at the beginning of each sprint, we prioritize tasks that need to get done and ascribe “points” to each task. These points range from 1 to 8 and serve as guesstimated markers for scope and how much effort any given task will take. A ‘one’ could be something as simple as updating the verbiage of a copyright statement. An ‘eight’ is a task large and/or complex enough that it is very likely going to spawn a few additional tasks to keep the scope of the needed deliverable reasonable as progress is made. Tasks for bugs in existing projects are not given points as it is much harder to quantify the level of effort required for unexpected and undesired results in a feature.

I wanted to track the number of times I paired with a teammate or collaborated on a task, as sometimes, the time I spent paired with colleagues wouldn’t translate directly into tasks I could claim responsibility for but were still work that I contributed to. I wanted to track the total number of task points I worked on and the number of tasks I was able to deploy. I also wanted to track the number of PRs I opened, as sometimes PRs get closed without deploying to production, but that doesn’t mean that work wasn’t still valuable to the company or wasn’t an opportunity for me to learn. I also wanted to keep track of which tasks were bugs I worked on, since their scope can be widely varied in complexity and can take a long time to isolate and solve. I iterated over this template as I was using it the first few weeks to get it to a place that was useful for my day to day developer experience and easy to use. To help me remember to set time aside for doing these regular reflections, I added a recurring 30 minute event to my work calendar on Fridays that included the URL to this Google Doc reflection template. (Substituting “copy” for “edit” in the URL of a google file allows one to quickly and automatically make a copy.)

Feel free to use this template as a starting point for your own reflections to support your own growth as a junior developer. Since I have started doing weekly reflections, now, when I do 1-on-1’s with my manager, I am able to regularly provide them with evidence of my growth as a developer and demonstrate the increasing complexity, breadth, and quality of my work while I work towards getting promoted. Just as importantly if not more, clearly identifying my growth and accomplishments, especially while I was struggling to see or feel like I was getting better in my first developer role, was invaluable to boosting my confidence and morale. And making a practice of reflecting on and tracking one's work and accomplishments as a developer isn't just valuable as a junior dev; this practice can continue to provide benefit throughout one's career and evidence of one's growth over time.

Getting your first job in tech as a developer is an incredible accomplishment. Dealing with the reality of the growing pains in that first role isn’t just technically challenging, however; it is also emotionally challenging. Finding ways to ease that transition, like making a point to regularly track one’s accomplishments, can make a big difference in a developer’s emotional well-being, as well as encourage professional and technical development.

#GettingBetter at PRs and Code Reviews as a Junior Developer

Danielle Thompson — Thu, 17 Nov 2022 06:46:52 +0000

When I started my first job as a software developer, I felt like a fire hose of information was being sprayed at my brain. There was so much to learn, especially because I hadn’t ever worked with the main language (Ruby) that I would be coding in everyday outside of some V basic “hello, world”-type beginner projects. Most days in my new career felt overwhelming to say the least, but I wanted to do everything I could to succeed.

One way I had to orient myself in my new environment was pull requests (PRs). Documentation has always been my bag, so figuring out how to write useful PRs was less of my problem, although there was still a learning curve involved. For months, my biggest struggle with PRs as a newly minted developer was giving meaningful code reviews to colleagues and seniors. Half the time I felt my eyes glaze over trying to read through and understand code that was still quite literally a foreign language to me. Plenty of times I didn’t understand the syntax, what I was reading, what change was being implemented, or why it was important - sometimes I didn’t understand all three at once. I wanted to feel like I could actually contribute to conversations held and issues raised in PRs, but for a long time, felt like I didn’t have the knowledge base to do so.

Over time, I started to dial in how I, as a junior engineer, could meaningfully contribute to PRs. I asked senior engineers for feedback on how I could improve my PR processes, and what I could do to better understand and engage in technical conversations. I learned when I should ask questions about code or syntax I didn’t understand, and was reminded “oh yeah, (sometimes) documentation exists for something I don’t understand.” I learned that I don’t always have to have a fully working solution to be able to spin up a new PR. I learned how to use tools like automated tests, commit history, tailing logs in Heroku, etc. to get a more thorough understanding of what I was reading and to raise questions and concerns about how that code worked.

However, I was still getting frustrated that I couldn’t always remember what I could do to better review code written by other developers, or what I could do to more thoroughly check my own code for errors or refactoring opportunities that I could have caught in my own PRs to save my colleagues time in their reviews. Even just remembering what all I could try and do to push myself further into blockers I was having without senior support and implementing better debugging techniques during the review process was still a struggle.

This might seem unrelated, but stick with me here - I worked for many years in the service industry before going back to school at a coding boot camp. When I worked in bars and restaurants, there was always a laminated checklist somewhere behind the bar or in the server station waiting for someone to walk through all the opening duties, closing duties, and what’s called “side work” - things like polishing silverware, folding napkins and so forth that keep the restaurant prepared and staff busy in slow moments. Even if I had done the same opening or closing duties 100s of times, some days I still used those lists to guide me at the beginning and end of my shifts. I knew I could still forget something on the list, or my ADHD brain would not be a pal and squirrel away my focus elsewhere.

Harkening back to my years in the service industry and recognizing the limitations of my neurodiverse brain, I remembered that these workflow checklists were wildly valuable to me in my former career. Even if I had done a process a hundred times over, having a list in front of me to keep me on track and ensure I didn’t accidentally skip steps was incredibly beneficial for my brain to be more systematic. I realized I could apply this same principle to my new job. So, I started building a checklist to work with when both writing and providing code reviews.

Knowing other new and burgeoning developers like myself would likely benefit from the knowledge I have gained in my first few years of experience writing and reviewing PRs, I wanted to share what I’ve learned, so that others can contribute more in their own first developer roles and hopefully level up faster in their careers. I’ll share what I’ve found to be useful tools both for submitting my own code in PRs, as well as reviewing PRs.

Submitting Better PRs for your Code.

A good PR starts with a meaningful commit history that tells the story of what change you have made from beginning to end of your changes. a. Commit messages should be with a quick, concise synopsis of the change expressed because of the character limit that will be displayed in commit history. b. However, you can think of the character-limited commit as the “header”; you can also add additional “body” information inside a commit with more in-depth knowledge sharing about why you made that change, links to the resources used, the original task’s ID if you use a task management system, etc. Adding more body to a commit can provide valuable insights into a change when inspecting git history, and can be easier than trying to find an obscure, closed PR in the annals of your org’s repositories. If you use VS Code’s source control or a tool like Tower to make commits, their UI for adding body to your commits is really straightforward, but the Git CLI also allows you to do a simple carriage return to add this body in as well. (And pro tip, the git CLI recognizes Markdown syntax!) For example:

git commit -m "Add this specific feature ...

This specific feature used to do A, but now it does X, Y, Z after we realized A was limiting our <insert business or technical reasoning here>. This change in the feature now provides <insert value here>. You cannot make this feature do B like we originally set out to do in task [CU-#a3s3d4](www.your-task-link-here.com) since B is incompatible with the version of <insert tool here>. For further information on this incompatibility, please read [this piece of documentation](www.documentation.com)."

A good PR includes a clear written description. a. If writing a new feature, describe what this new feature does and why it was asked for - i.e explain the purpose of your change. b. If refactoring or adjusting an existing feature, describe why this change is necessary or useful. c. If you had to deviate from the original requirements of the task, explain your reasoning and describe how your solution to the problem is/could be preferable. d. If you started trying to solve a problem in one way but realized that solution wasn’t going to do what you needed it to or wasn’t a solution at all for the problem at hand, describe your process. e. If your org tests PRs in testing environments, i.e. in a review or test application that is a replica of a production environment but is used for internal testing purposes only, include links to the review app that demonstrate the changes you made. f. Include corresponding links to your production app for comparison to the new changes in your testing environment - before & after shots, if you will. g. Explain what people should look for and test in the live links. h. If the change is not a visual one, include some form of evidence if you can; e.g. include stats about a performance change, provide a CSV of a script of the results, etc. i. Include any questions, pain points, or blockers; PRs do not have to be perfect working examples. They can be a forum for requesting help and feedback on issues that have presented themselves during your development process. j. Learning some basic Markdown syntax can be really beneficial to include even things like headers, bullets, hyperlinks, checkboxes, tables, and so on in your PR description. k. Include before and after screenshots if the changes you’ve made are visual.
Do some science and test that the links you have included demonstrate your changes in the review apps yourself before asking for reviewers. Sometimes, a change will work in your local environment, but things go haywire in a testing environment, or you may have just simply missed a detail or two.
Before adding reviewers, take the opportunity to read through your own code in PR format to see if there are any missing details or refactor opportunities. Reviewing your own code in a different environment outside of your code editor can be incredibly beneficial to help you see things you weren’t seeing before. Viewing code in a PR format cuts out all the extra noise from other files you’re not working with to give a condensed snapshot of the change you’re working on, too.
Similarly, before you add reviewers, you should also consider if there is anything you can refactor, DRY up, clean up, make more readable, name more clearly, etc.

Providing Better PRs for Others

Some of the same rules apply across the board, whether you are asking for reviews or providing one for someone else.

Test the feature change if there is something that can be tested in a review app (e.g. submit a new form, compare visual changes between prod & review, etc.). When you’re looking at visual changes, does anything seem off? Remember that you can inspect a page through your preferred browser’s dev tools, and see if something funky happening in the markup or CSS is an attributing cause.
Go through all steps of testing that a change works. So you see that the new form doesn’t throw errors in the browser and exists as expected? Cool. Can you interact with everything in that form in the manner that you would expect? What happens on submission of the form? What happens if you re-submit or edit something in the form? What happens when you delete a new entry entirely? Put your Quality Assurance hat on for a bit and see what you can break. Look for tiny details like incorrect punctuation and big details like an entirely new page working.
Do some science to confirm with evidence that what you’re seeing works as it looks like it will work at face value. a. If the change is architectural in nature, e.g. updating a gem or Docker file or updating the version of your operating language, pull that branch into your local environment and play around with how this change works in your environment. Can you still build your Docker container? Can you still access the main landing pages of your application? Can you still run tests successfully? b. If a PR description doesn’t explicitly say, and you don’t exactly know what you could be looking for or testing out in an architectural change, ask. Understanding and anticipating the ins and outs of software architecture should not be an expectation of understanding in your junior role. c. If the PR is for a new script (e.g. a rake task if you’re a Ruby/Rails person like me), run the script line by line through your local environment’s console to confirm that the results are what you expect. *Bonus - if you don’t yet understand what a script is doing, this is a great way to get hands on and walk through the code line by line until you do better understand. Learning opportunities!
Ensure code abides by established conventions. a. Does your company have styleguides for HTML + CSS/Sass? Compare existing styleguides to the markup in a new feature to ensure consistency. b. Are accessibility and security best practices like OWASP’s Top 10 set out by your company or general industry standards being followed? c. Does your company have specific code language styleguides or best practices? For example, do they want to avoid hard-coded text in favor of translatable I18n dictionary entries? Are there internal methods (or even in-built methods to your language/framework) that you could be using instead of doing something from scratch? Look for small details like this to ensure code is meeting company quality standards. d. Does the code meet the language’s best practice standards? E.g. if you’re working in Ruby, are you using single quotes consistently unless there is a string that needs interpolating? Is indentation correct?
Ask questions. If you don’t understand something, don’t be afraid to raise a hand for help. Challenge yourself to find and learn the answer yourself first, but know that it is expected that everyone will have questions and need help sometimes, especially when first starting out.

Learning how to write cleaner, more thorough PRs takes time, and so does being able to give meaningful code reviews for your teammates. Working more procedurally with a checklist of deliverables and items to review every time you submit or review a PR can be significantly less stressful and more effective. Doing so can reduce back and forth reviewing with teammates, help you level up your technical skills, and get you contributing a higher level of code and feedback for peers. I hope you’ll find some of these tips helpful and can use them to level you up in your technical career faster.