Introduction to hiring great teams

Hiring can be one of the most stressful, time-consuming, and expensive investments a business makes. That goes double in a niche as small as NetSuite development. But it’s also the most critical decision any organization makes. When it’s done well, hiring is truly transformative.

The right person in the right role with the right support can dramatically improve their team - or the entire business.

It’s hard to talk about hiring in isolation, though, because it has so many facets. The job title and expectations depend on the role(s) you have available, the career paths you have defined, and the organization’s goals. The salary depends on the business value that the role brings to the organization. The interview process varies wildly by organization and by interviewer. The team structure influences who performs the interviews.

To alleviate that complexity, I’ll cover many of these topics in their own separate articles, and in this one, I’ll focus on how I design the interview process for NetSuite developers.

Create and Align the Interview Team

Because hiring is such an important decision for the entire business, I don’t want that decision in the hands of only one person - even myself. I want that decision made by the team who will be working with the new employee. When I’m hiring, I’m building a team, not a reflection of myself.

When I was a development manager for a small NetSuite partner, we split our personnel into multi-functional teams: one project manager, one consultant, one quality assurance analyst, and 1-3 developers.

Whenever we needed to add a developer to a team, we wanted one person from each role on the team to conduct an individual interview. As hiring managers, we coached each interviewer on their role as interviewer (using many of the Dos and Don’ts you’ll find later in this article).

The hiring manager would conduct a brief phone screen based on the resume. If that went well, we’d bring candidates on-site for a series of one-hour interviews with each team member. I do not advise panel interviews, as those can be wildly off-putting for candidates and chaotic for interviewers.

At the end, we’d take the candidate out to lunch with the whole team to thank them for their time and give a little back to them. I continue to advise that teams offer this to candidates, but make it clear that it’s not part of the evaluation. Lunch with strangers who you feel are evaluating you can be even more off-putting than those panel interviews.

Sound like a lot? It definitely is! But we knew that we couldn’t continue cycling through developers every 3-6 months. Turnover destroys morale, which increases turnover, which destroys morale, and round and round we go.

We needed stability, which meant we needed to make better hiring decisions. We went about making better decisions by introducing form and rigor to our decision-making process and coaching for our interviewers. In doing so, we tripled our developer headcount from 7 to 21 inside of a year, while at the same time extending our average developer tenure from 6 months to 24 months for those new hires.

Two years later, when I left to start my own business, many of the developers we had hired were still there, and stayed there years after I left. Another benefit of taking the decision out of solely the hiring manager’s hands: the people you hire automatically feel more loyalty to their team than to their manager, because their team were the ones who decided to welcome them in.

There were many other factors influencing the retention metric, which I’ll cover in future articles, but coaching our interviewers to make better decisions was a huge factor.

Define a Framework for Decision Making

Interviewing is a skill. Not everyone automatically knows how to do it, or how to do it well. Just think back to any of your own worst job interviews for evidence of this. Once you have your interview team in place, bring them all together to define or adopt a framework for how you will all make hiring decisions together.

In the past, I’ve used Joel Spolsky’s Smart and Gets Things Done as this framework, but there are many published examples you could use that may better fit your organizational mindset. I won’t give away all of Spolsky’s “secrets” here, but the book lays out specific criteria to assess during software development interviews, and a process for making the decision afterward - one which is crystal clear:

It’s a Unanimous “Hell Yes”, or it’s “No”.

Each interviewer conducts their interviews, then immediately returns to their desk to record their decision on an index card. On one side, they write “Hell Yes” or “No”, based on their individual reaction to the candidate’s performance and fit for the team. On the other side, they can write notes supporting their decision.

We used physical index cards so that the decisions and the notes remained focused, clear, and concise. No novels or soliloquies allowed.

Interviewers are not allowed to discuss the interview or the candidate at all until all interviews are completed and all reactions recorded, to avoid biasing the other interviewers towards any position.

Once complete and recorded, then all the interviewers convene in a time-boxed conversation to reveal and discuss their individual reactions.

• If everyone’s reaction is a Hell Yes, then no discussion is needed; that candidate should receive an offer.
• If everyone is a No, then no discussion is needed; that candidate should receive their rejection notice, and we move on to the next candidate.
• If the reactions are mixed, then a conversation should occur to see if all opinions can be swayed to the Unanimous Hell Yes. That conversation cannot last more than 15 minutes to avoid endless, fruitless debate. If reactions are still mixed, that candidate should receive their rejection notice, and we move on to the next candidate.

Over time, I relaxed almost all of the specific criteria that Spolsky lays out, but the one thing I continue to hold on to is the “Unanimous Hell Yes, or No” decision-making mindset. It’s fast, it builds real team ownership, and it has yielded fantastic results for the teams I’ve worked with - though not perfect of course, as no system is.

You might decide that 15 minutes is not enough time and 30 is more appropriate, or that 75% Yes is enough for your team, or that you like legal paper instead of index cards. All of that is great, as long as you explicitly make and agree on those decisions as an interview team.

The important takeaway here is that you define clear, simple decision-making criteria that fits your organization, and you stick to that criteria in your hiring decisions.

Don’t bend the rules “just this once” for someone you really liked but the team didn’t; you’ll undermine the team’s buy-in.

Don’t wing it with each new role or candidate; the decision is too important. Defining your shared hiring mindset together is how you avoid winging it. That mindset can be defined through a list of Dos and Don’ts when interviewing.

What Not to Do When Interviewing NetSuite Developers

For the purposes of this article, I’m going to focus on a technical interview for a NetSuite developer, as this is where I have observed the most mistakes.

My job as a technical interviewer is to assess the candidate’s problem-solving ability, collaboration potential, and fit for a specific role within my team or organization.

My job is NOT to:

• Identify the Greatest Software Developer
• Prove I’m smarter than the candidate by stumping or tricking them with GOTCHA! deceptions or FAANG exercises.
• Test that their solution matches my solution, or is “right”, or even “works”
• Throw obscure computer science puzzles from already-solved problems at the candidate
• Get free labor out of a candidate

Do not seek to stump the candidate with obscure questions or code. The candidate is not your enemy to be vanquished or dominated. They’re exactly the opposite; they’re potentially your teammate, who will be fighting alongside you in the trenches. You want to collaborate with them, not turn them against you.

Do not find a list of FAANG (Facebook, Apple, Amazon, Netflix, Google) interview questions and throw those at your candidates. The FAANG companies and their ilk get equally lauded and mocked for their interview questions, often pulled straight from computer science academia. It’s gotten to such a degree that there are books, blogs, and web apps dedicated to helping candidates prepare for these types of questions. But NetSuite developers are not FAANG engineers or computer science academics. We don’t need to define new sorting algorithms or design more efficient heaps or implement our own linked lists. We solve an entirely different class of problems for real-world businesses. Test your candidates for understanding and solving business problems, not for a computer science degree.

Do not make them write code on a whiteboard. Restricting them to a whiteboard or similar is like evaluating a race horse on its racing ability by watching it sleep in a pen in a stable. Let them use all the tools they would have at their disposal in their real job - their computer, their IDE, stackoverflow, and whatever else they want. Let them ask you questions and converse with you about the problem. Observe them in their natural habitat. The more tools I leave available to a developer in an interview, the more I can assess their resourcefulness and their habits.

Do not force them to stay for the entire interview process. Be respectful of their time and your team’s time. Make it clear up front that if a candidate reaches a point in your process where they just aren’t feeling it, for any reason, that they can simply elect to leave, to bow out of the process, and they don’t owe you any explanation. If you haven’t made a good enough impression on them, there is no point in wasting their time or your team’s time. Let them go, and everyone can move on.

Do not turn the interviews into some sort of endurance gauntlet. We’re not building Olympic athletes; we just need good software developers and teammates. Conduct the interviews remotely whenever possible to avoid long commutes. Make sure the candidate knows they can take breaks when they need to. If necessary, spread the interviews out over a couple of days, but never more than that to avoid long decision windows and drawn out feedback cycles.

Do not pull tasks from your backlog and use them as interview problems for the candidate to solve. Interview candidates are not your free labor. Their ideas or code are not yours to steal.

Questions I Ask When Interviewing NetSuite Developers

As I said previously, my job as a technical interviewer is to assess the candidate’s problem-solving ability, collaboration potential, and fit for a specific role within my team or organization.

I do that by developing a battery of applicable questions used for assessing various areas based on the candidate’s stated experience and expected role on the team.

I document these questions, the intent behind them, and good follow-up questions in a knowledgebase. The knowledgebase then allows our internal interviewers to retrieve them at any point, adjust them with each interview, add insights or observations to them.

Over time, this group knowledges evolves with the team, helps to reinforce the team’s hiring mindset, and makes interviewing infinitely smoother. Busy interviewers don’t have to scramble to come up with a question 2 minutes before an interview; they can just pull up the list, present a question they like, and observe.

An exhaustive list of specific questions would turn this article into a Brandon Sanderson novel, so I’ll spare you that. Instead I’ll focus on the areas a team can evaluate a candidate on:

• JavaScript Experience
• NetSuite/SuiteScript Experience
• Technical Solution Design

Note that every interviewer doesn’t need to assess all areas. That effort can be split up across your interview stages however you see fit.

JavaScript Experience

SuiteScript is simply a JavaScript library, so I typically want to assess a candidate’s JavaScript experience. I don’t treat JavaScript as a prerequisite for hiring, especially for junior positions. However, I do want to know where we’re starting out. Also, if a candidate’s resume tells me they have JavaScript experience, I want to quickly confirm that as a spot check for trust.

To that end, some of my favorite JS questions are:

• What are JavaScript’s primitive types?
• What does “falsy” mean in JavaScript?
• Can you write me a function that accepts two numbers and outputs the sum of those two numbers?

These might seem like nitpicky trivia questions that can easily be looked up, because they are exactly that, intentionally.

If a candidate can explain them off the top, if they immediately know where or how to look them up, or if they don’t already know, but start asking great questions, that’s all fantastic. In any of those cases, I can rapidly move on to something else.

If they stare at me blankly, we can likely end the interview process right there.

In the aforementioned NetSuite partner days, I was interviewing a candidate who stated on their resume that their JavaScript knowledge was “an 8/10”. When I asked the candidate to write the summing function - a trivial task for an 8/10 - they stood up, apologized for wasting my time, and walked out.

To be clear, I only use these when the candidate states they already know JavaScript. If they don’t, it’s a waste of time to test them on this knowledge.

What I love about these questions is that they have simple initial answers that can then be evolved with complications. I can often spend a full interview iterating on any or all of these questions, and get a great assessment of the candidate’s initial knowledge and their adaptive problem solving.

NetSuite/SuiteScript Experience

Unless I’m hiring for an extremely senior position, I do not require or test for specific NetSuite or SuiteScript knowledge, and even then, I still don’t think it’s a strict requirement. The available talent pool that meets those requirements is just way too small, and that technical knowledge is far easier to teach than good communication or effective troubleshooting habits and other intangibles are.

I do, however, love to show developer candidates about 100 lines of complete, valid, clearly written SuiteScript, and then start a conversation to see if they can reason out the purpose of the code. The purpose of this exercise is to observe how the candidate reacts to unfamiliar code in an unfamiliar environment. If the candidate claims and has SuiteScript knowledge, this phase should go pretty quickly.

I like this code to be realistic and straightforward - perform a search and email the results, or run a query and perform some common math. A huge part of our job as NetSuite developers is inheriting someone else’s code and exploring the dark corners of wildly varying accounts, so I want to make sure candidates don’t just fold when they experience something they’ve never seen before.

I might give the variables/functions vague names like a, b, etc, but otherwise I don’t try to obscure the logic through poor coding practices or bad formatting or syntax errors or anything nefarious like that. We have IDEs that fix that stuff for us automatically.

I do introduce a subtle bug in the logic somewhere. Maybe a loop goes too far, or a variable starts out undefined when it should have a value. The specifics of the bug are unimportant, as long as it’s nothing extremely obscure. It should be something we can identify just by reading the code, without even running it. I explicitly let the candidate know there is a small bug in the logic. I also explicitly tell them it’s not a syntax error. I’m not trying to trick them; I want them to showcase their troubleshooting process.

I keep two or three of these samples on-hand in the same knowledgebase as the other interview questions, to be updated and evolved with each interview cycle.

All throughout this exercise, the candidate has full access to me for questions, to their browser to look stuff up, to test code in the console, whatever they think they need to do to be confident in their questions and solutions. If they ask me a question, I give them a clear, honest answer. If they’re really stuck, I give them a hint or a question to prompt them on their way. I’m not trying to make them feel awkward or foolish; I want them to succeed. I want them to want to work with me, not to feel alienated by me.

Technical Solution Design

For assessing solution design and system architecture, once again, I do not require any specific NetSuite knowledge. Instead, if the candidate has their own portfolio of code they’re willing to share and discuss, we do that. If not, I ask them about a project they’ve designed in their past.

If they’re junior and don’t have any of those under their belt, then I typically prompt them to talk through how they might design a common, well-known system. Popular games work really well for this - games like poker or checkers or anything else the candidate is already familiar with. Something with straightforward rules.

I have them walk me through their code or the system, explaining the architectural decisions and design tradeoffs they made. I ask questions about their reasoning, their priorities, the parts that were the most fun, the parts that made them want to quit.

I’m feeling out their thought process, but I’m also looking to hear some passion in their problem solving. Code does not have to be their whole life; I don’t expect my developers to write code outside of work, because I don’t write code outside of work. When I say passion, I don’t need them leaping out of their seat and putting on a show; I’m not evaluating their charisma. I simply want to give them an opportunity to showcase their personal interest and investment in solving problems and communicating through code.

I don’t need them to complete a fully functional design. I just want to listen to them talk through their reasoning, showcase their software engineering skills, and prod them with follow ups to keep the conversation going.

No-Code Interviews?

You might notice that I don’t ask developers to write much code - if any - during an interview. How can I possibly evaluate a developer if I don’t watch them write any code

I don’t believe the act of writing code is the most important job of a software engineer. These days, IDEs, code completion, linters, and (increasingly) generative AI do most of the heavy lifting of writing the code. The engineer’s job is to design a system that meets the business requirements and is understandable by a machine/computer, and to communicate that system to stakeholders and other developers using those aforementioned tools.

In order to evaluate an engineer’s ability to solve problems, design systems, and communicate solutions, I communicate with them about systems and problems and solutions. I have a conversation with them about systems and challenges and tradeoffs. We explore problems and iterate on potential solutions, just like a team of developers does in their day-to-day work.

Typing out code is the least important task a NetSuite developer does, so it’s the thing I spend the least amount of time on in an interview.