Interview Questions Template

How does your day-to-day work look like?
What do you know about software testing? How about being a scrum master?

What is your most favorite part of the work? Your least favorite?
Have you taken part in a project that you’re really proud of?

What made you decide to apply for this position?
Why not apply for a programmer job?

What three skills do you think matters most to a tester? To a scrum master?
How do you rate yourself in those skills?
What skill would you say you’ve actively pursued recently?

Are you familiar with the following?

  • Risk
  • Exploratory testing
  • Automation
  • Test-driven development
  • Behavior-driven development
  • Agile
  • Pairing
  • Retrospective

Do you have hobbies that are important enough to waste time on?
What is one of your favorite movies? A favorite book? A favorite TV series?

Do you have specific goals in mind that you want to achieve when you get this role?
In what ways do you think we can help you achieve those goals?

Do you have questions for me or for your employer?

 

(Because I’ve been scheduled to interview a number of applicants in the coming week and I often forget to ask some of the important questions when I go at it head-on, I thought I needed some sort of template I can always grab and bring)

Advertisements

A 7-Year Run

It’s been seven years since I got employed at the private company I currently work for. I didn’t set out to be employed for them this long but the pay was okay and there was a lot of freedom in the testing work so I stuck around. That freedom allowed for opportunities to learn and improve on the testing (and software development) craft consistently, even though there really wasn’t any in-house training available, as long as I managed myself well year in and year out. At that time, I thought that all I needed was time to train myself and so that’s what I did. I managed my tasks well, I asked people and the world wide web questions and tried their suggestions one at a time, and that pattern continues to this day.

Don’t know where to start testing? Look at what’s available, see which ones could be interesting, and then just dive right in to those. Too many things to test? Find which features are most important and start with those, not worrying too much about testing everything. Found something odd? Ask the customer whether it’s something worth exploring. Think a particular task isn’t worth doing over and over again? Automate it, if there’s really some value in automating it. Not technically savvy? There’s tons of materials out there you could study a little at a time. Something troubling the team? Ask and listen to what they have in mind. Is a certain process annoying? Find out why that is and think whether there’s something you can do about it. Bored? Do something else. Tired? Take a break. Want to get better at a particular skill? Read books and blog posts, watch webinars or take courses, and build projects with what you’ve learned. Day in and day out, the fun is in hunting for intriguing problems to solve and testing one possible solution after another. And the trick in having the most fun is in finding out what problems are worth solving for, both for your customer and for yourself.

Yes, it’s been an extraordinary seven years. I got the growth spurt that I wanted while performing valuable work on time. Now thinking about it, I’m actually not sure if there will be many years more to add to that record, but all is well because it’s been a great run.

Lessons from Kent Beck and Martin Fowler’s “Planning Extreme Programming”

The first edition of “Planning Extreme Programming” by Kent Beck and Martin Fowler was published about 18 years (that long) ago, and already it says so much about how planning for software projects can be done well. It talks about programmers and customers, their fears and frustrations, their rights and responsibilities, and putting all those knowledge into a planning style that can work for development teams. It doesn’t have to be labeled XP, but it does need to help people be focused, confident, and hopeful.

Here are some noteworthy lines from the book:

  • Planning is not about predicting the future. When you make a plan for developing a piece of software, development is not going to go like that. Not ever. Your customers wouldn’t even be happy if it did, because by the time the software gets there, the customers don’t want what was planned; they want something different.
  • We plan to ensure that we are always doing the most important thing left to do, to coordinate effectively with other people, and to respond quickly to unexpected events.
  • If you know you have a tight deadline, but you make a plan and the plans says you can make the deadline, then you’ll start on your first task with a sense of urgency but still working as well as possible. After all, you have enough time. This is exactly the behavior that is most likely to cause the plan to come true. Panic leads to fatigue, defects, and communication breakdowns.
  • Any software planning technique must try to create visibility, so everyone involved in the project can really see how far along a project is. This means that you need clear milestones, ones that cannot be fudged, and clearly represent progress. Milestones must also be things that everyone involved in the project, including the customer, can understand and learn to trust.
  • We need a planning style that
    • Preserves the programmer’s confidence that the plan is possible
    • Preserves the customer’s confidence that they are getting as much as they can
    • Costs as little to execute as possible (because we’ll be planning often, but nobody pays for plans; they pay for results)
  • If we are going to develop well, we must create a culture that makes it possible for programmers and customers to acknowledge their fears and accept their rights and responsibilities. Without such guarantees, we cannot be courageous. We huddle in fear behind fortress walls, building them ever stronger, adding ever more weight to the development processes we have adopted. We continually add cannonades and battlements, documents and reviews, procedures and sign-offs, moats with crocodiles, torture chambers, and huge pots of boiling oil. But when our fears are acknowledged and our rights are accepted, then we can be courageous. We can set goals that are hard to reach and collaborate to make those goals. We can tear down the structures that we built out of fear and that impeded us. We will have the courage to do only what is necessary and no more, to spend our time on what’s important rather than on protecting ourselves.
  • We use driving as a metaphor for developing software. Driving is not about pointing in one direction and holding to it; driving is about making lots of little course corrections. You don’t drive software development by getting your project pointed in the right direction (The Plan). You drive software development by seeing that you are drifting a little this way and steering a little that way. This way, that way, as long as you develop the software.
  • When you don’t have enough time you are out of luck. You can’t make more time. Not having enough time is a position of helplessness. And hopelessness breeds frustration, mistakes, burnout, and failure. Having too much to do, however, is a situation we all know. When you have too much to do you can prioritize and not do some things, reduce the size of some of the things you do, ask someone else to do some things. Having too much to do breeds hope. We may not like being there, but at least we know what to do.
  • Focusing on one or two iterations means that the programmers clearly need to know that stories are in the iteration they are currently working on. It’s also useful to know what’s in the next iteration. Beyond that the iteration allocation is not so useful. The real decider for how far in advance you should plan is the cost of keeping the plan up-to-date versus the benefit you get when you know that plans are inherently unstable. You have to honestly asses the value compared to the volatility of the plans.
  • Writing the stories is not the point. Communicating is the point. We’ve seen too many requirements documents that are written down but don’t involve communication.
  • We want to get a release to the customer as soon as possible. We want this release to be as valuable to the customer as possible. That way the customer will like us and keep feeding us cookies. So we give her the things she wants most. That way we can release quickly and the customer feels the benefit. Should everything go to pot at the end of the schedule, it’s okay, because the stories at risk are less important than the stories we have already completed. Even if we can’t release quickly, the customer will be happier if we do the most valuable things first. It shows we are listening, and really trying to solve her problems. It also may prompt the customer to go for an earlier release once she sees that value of what appears.
  • One of the worst things about software bugs is that they come with a strong element of blame (from the customer) and guilt (from the programmer). If only we’d tested more, if only you were competent programmers, there wouldn’t be these bugs. We’ve seen people screaming on news groups and managers banging on tables saying that no bugs are acceptable. All this emotion really screws up the process of dealing with bugs and hurts the key human relationships that are essential if software development is to work well.
  • We assume that the programmers are trying to do the most professional job they can. As part of this they will go to great lengths to eliminate bugs. But nobody can eliminate all of them. The customer has to trust that the programmers are working hard to reduce bugs, and can monitor the testing process to see that they are doing as much as they should.
  • For most software, however, we don’t actually want zero bugs. (Now there’s a statement that we guarantee will be used against us out of context.) Any defect, once it’s in there, takes time and effort to remove. That time and effort will take away from effort spent putting in features. So you have to decide which to do. Even when you know about a bug, someone has to decide whether you want to eliminate the bug or add another feature. Who decides? In our view it must be the customer. The customer has to make a business decision based on the cost of having the bug versus the value of having another feature – or the value of deploying now instead of waiting to reduce the bug count. (We would argue that this does not hold true for bugs that could be life-threatening. In that case we think the programmers have a duty to public safety that is far greater than their duty to the customer.) There are plenty of cases where the business decision is to have the feature instead.
  • All the planning techniques in the world, can’t save you if you forget that software is built by human beings. In the end keep the human beings focused, happy, and motivated and they will deliver.

Questions on Releasing Daily

What if?

Do we think we can do that?

Is that a goal worth something for us to reach for, or are we satisfied with weekly, monthly, or yearly project releases?

If we do decide to release to live daily, is it going to take a lot of work?

For what reasons do we have to put in the effort for?

What changes should we have to make so we can push as early and as often as possible?

How does that affect our existing software development process?

Does our team have sufficient expertise to follow through?

Do sprints even matter in that case? What about daily stand ups and retrospectives?

Should we push to live our long-running projects? What happens to feature branches?

How much testing is enough for us to be comfortable with daily releases?

Do we still need as many test environments as we do before?

What happens to our testing when we don’t have plenty of time to manually check everything?

Are our customers supposed to be delighted if we release daily?

Will the team be more pleased with a presumably increased efficiency or are we happy where we are?

If we decide to forego a daily release schedule, where else do we want to focus our attention to?

Welcome Back, Selenium IDE!

I was browsing my Feedly news feed recently, as I routinely do once a week, and saw this particular bit of cheery bulletin:

Click to redirect to the official announcement from Selenium HQ

Long live Selenium IDE! 🙂

Nostalgia hits. I remember the days when the only automation I knew was Selenium IDE’s record-and-playback. It’s easy to install, is relatively fast, and isn’t difficult to pick up as the Selenese commands are straightforward. It was possible to run a test individually as well as to run tests as a suite. There was a way to manually change test steps, and, of course, save tests, as needed. It only worked on Firefox at the time, but that for me back then was good enough. At least until I eventually craved for the re-usability, maintenance, and customization advantages that programming has over record-and-playback.

This is what it looks like now:

And some delightful things about it (that I don’t remember – or perhaps forgot – having seen in the Legacy IDE):

  • Command dropdown options in English
  • Control flow commands baked in
  • An execute async script command
  • A run command to run tests headlessly! 😮
  • Google Chrome extension and Firefox add-on versions out of the box

Although I don’t see myself going back to record-and-playback tools for my automation needs, I’m still glad Selenium IDE is back for everyone to try. It’s still a great tool for recording quick automated browser scripts, for demo purposes or otherwise, as well as for learning automation in general.

Takeaways from Kim Scott’s “Radical Candor”

There’s a lot I don’t know about being a kick-ass boss, or being a great manager. I’m pretty much still a work-in-progress in that area. Thankfully, Kim Scott’s “Radical Candor” points me to the questions I need to ask myself about it, and suggests steps I should consider taking in order to do better.

Some memorable lines from the book:

  • Relationships don’t scale. But the relationships you have with the handful of people who report directly to you will have an enormous impact on the results your team achieves.
  • You strengthen your relationships by learning the best ways to get, give, and encourage guidance; by putting the right people in the right roles on your team; and by achieving results collectively that you couldn’t dream of individually. When you fail to give people the guidance they need to succeed in their work, or put people into roles they don’t want or aren’t well-suited for, or push people to achieve results that are unrealistic, you erode trust.
  • It turns out that when people trust you and believe you care about them, they are much more likely to 1) accept and act on your praise and criticism; 2) tell you what they really think about what you are doing well and, more importantly, not doing so well; 3) engage in this same behavior with one another, meaning less pushing the rock up the hill again and again; 4) embrace their role on the team; and 5) focus on getting results.
  • We are all human beings, with human feelings, and, even at work, we need to be seen as such. When that doesn’t happen, when we feel we must repress who we really are to earn a living, we become alienated. That makes us hate going to work. To most bosses, being professional means: show up at work on time, do your job, don’t show feelings unless engaged in motivation or some such end-driven effort. The results is that nobody feels comfortable being who they really are at work.
  • It’s about finding time for real conversations; about getting to know each other at a human level; about learning what’s important to people, about sharing with one another what makes us want to get out of bed in the morning and go to work – and what has the opposite effect.
  • Challenging others and encouraging them to challenge you helps build trusting relationships because it shows 1) you care enough to point out both the things that aren’t going well and those that are and that 2) you are willing to admit when you’re wrong and that you are committed to fixing mistakes that you or otherwise have made. But challenging people directly takes real energy – not only from the people you’re challenging but from you as well – so do it only for things that really matter.
  • If nobody is ever mad at you, you probably aren’t challenging your team enough. The key, as in any relationship, is how you handle the anger. When what you say hurts, acknowledge the other person’s pain. Don’t pretend it doesn’t hurt or say it shouldn’t hurt – just show that you care. Eliminate the phrase “don’t take it personally” from your vocabulary – it’s insulting. Instead, offer to help fix the problem. But don’t pretend it isn’t a problem just to try to make somebody feel better.
  • If we have the data about what works, let’s look at the data, but if all we have are opinions, let’s use yours.
  • What growth trajectory does each person on my team want to be on right now? or Have I given everybody opportunities that re in line with what they really want? or What growth trajectory do my direct reports believe they are on? Do I agree? And if I don’t, why don’t I? Sometimes people really want to grow and are capable of contributing more than they have allowed to; at other times, they simply want more money or recognition but don’t really want to change the way they work or contribute any more than they do already. As the boss, you’re the one who’s going to have to know your direct reports well enough to make these distinctions and then have some radically candid conversations when you see things differently.
  • There’s nothing wrong with working hard to earn a pay check that supports the life you want to lead. That has plenty of meaning. Only about 5% of people have a real vocation in life, and they confuse the hell out of the rest of us. Your job is not to provide purpose but instead to get to know each of your direct reports well enough to understand how each one derives meaning from their work.
  • You don’t want to be the absentee manager any more than you want to be a micro-manager. Instead, you want to be a partner – that is, you must take the time to help the people doing the best work overcome obstacles and make their good work even better. This is time-consuming because it requires that you know enough about the details of the person’s work to understand the nuances. It often requires you to help do the work, rather than just advising. It requires that you ask a lot of questions and challenge people – that you roll up your own sleeves.
  • It won’t get better all by itself. So stop and ask yourself, how exactly, will it get better? What are you going to do differently? What will the person in question do differently? How might circumstances change? Even if things have gotten a little better, have they improved enough? If you don’t have a pretty precise answer to those questions, it probably won’t get better.
  • If you never ask a single question about a person’s life, it’s hard to move up on the “care personally” axis. probably the most important thing you can do to build trust is to spend a little time alone with each of your direct reports on a  regular basis. Holding regular 1:1s in which your direct report sets the agenda and you ask questions is a good way to begin building trust.
  • The platinum rule says, figure out what makes the other person comfortable, and do that.

One Month with Flutter: Some Notes

Wait, what, it’s already been a month? 😮

It apparently took me an exciting month to build a moderately intricate multi-page mobile app, powered by Flutter, with custom calendar and credit card views. The designs for the pages already existed, which was good because I did not want to worry about designing an app for my first try with Google’s SDK and the Dart language. I only wanted to test-drive writing the code for the user interface and find out what tools and structure I could use for managing state and data, given a relatively short span of time. A month isn’t enough to understand everything about the framework but I did learn a lot from the experience. A realization: I can totally write mobile apps now if I want to.

Some notes I’d like to remember from the exercise: