Monday

Tag: Technical Interview

Technical Interview Questions

Technical interviews are an attempt by a hiring team to ask the correct questions of a candidate to determine if they would be a good technical fit for the open position.

These questions can sometimes uncover missing segments of knowledge that might identify opportunities for the candidate, or even disqualify the candidate for the open position. That is good information to know before you initiate the hiring process, but it can also help identify specific talents or abilities in a candidate that are above and beyond the minimum knowledge expected.

One of the obvious pitfalls of the technical interview is if the questioning turns into more of a trivia contest than a verification of expected knowledge.

One way to determine if a candidate knows how to solve a problem is to give them a problem and ask them to solve that problem during the interview. Sometimes the problem can be a specific technical issue, or a theoretical problem that is just to see if they can determine a simple solution using just the facts presented.

I have asked a simple question to candidates in the past that doesn’t really apply to the job opening they are applying for, but does provide insight into how they identify the issue, think through the possible answers, and provide them an opportunity to present their ideas.

Why is a manhole cover round?

You may never have thought of this question before, but why is a manhole cover round? You want the candidate to consider the possibilities and try to provide possible reasons for this design choice. It has nothing to do with the position they have applied for, but it will give a hiring manager an idea of how this person will respond to a problem that seems to come out of left field.

Do they think though the question or just respond with “I don’t know.” and quit? Have them speak about what they think about the question. Do they have an opinion about why they aren’t square, hexagon, or even oval in shape? Have they seen a manhole or know what they are used for in everyday life? Why do they think some manholes covers are not round?

Hopefully they can speak to possible reasons, which gives you the opportunity to ask how they would find a suitable response. If they just want to Google the answer, maybe ask them what else you might do to get a suitable answer if there isn’t a consensus on Google.

The possible correct answers are:

  • Manhole covers are round because it is the best shape to resist the compression of the surrounding soil.
  • Round manhole covers are easier to manufacture, move, and place than square or rectangular ones. The heavy covers can be easily rolled into position.
  • Manhole cover the size to fit the opening cannot fall through the circular opening, unlike other shapes. No one wants a 100-pound manhole cover dropping onto their head.
  • The cover doesn’t have to be aligned in any specific angle to be placed back onto the exposed manhole. Other shapes would require precise alignment.

Years ago, there was a candidate that guessed the covers are round because the men accessing the opening are also round. While this is funny, I don’t think that was a design consideration.

I hate interviews that turn into trivia contests, so I’d much rather be asked a tough question that allows me to show my ability to use my brain to find solutions instead of just demonstrating my ability to memorize technical trivia that anyone could easily look up.

Sources:
(1) Why Are Manhole Covers Round? | Mental Floss. https://www.mentalfloss.com/article/60929/why-are-manhole-covers-round.
(2) Why are manhole covers round? | Live Science. https://www.livescience.com/32441-why-are-manhole-covers-round.html.
(3) Why Are Manhole Covers Round? – ScienceABC. https://www.scienceabc.com/eyeopeners/why-manhole-covers-circular-not-triangular-square-rectangular.html.
(4) The Surprisingly Technical Reason That Manhole Covers Are Round. https://www.envirodesignproducts.com/blogs/news/the-surprisingly-technical-reason-that-manhole-covers-are-round.

Your 10 Favorite SeniorDBA Blog Posts of 2016

Here’s the top 10 items you clicked on the most in 2016:

  1. 20 SQL Server DBA Interview Questions – Some sample questions you might be asked about in an interview for a DBA position. Also used by the hiring managers to make sure they have some relevant questions during your interview.
  2. Comparing SQL Server vs. Oracle License Cost – Looking at the difference in cost between SQL Server and Oracle.
  3. SQL Server and Windows 10 Compatibility – Quick instructions on using SQL Server Management Studio on a Windows 10 desktop.
  4. SQL Server Trace Flag List – List of available trace flags for use in SQL Server.
  5. Using PowerShell to Manage Audits – Using PowerShell as a powerful scripting tool that can manage your SQL Server audits.
  6. SQL Server TCP and UDP Ports – This post lists the ports and protocols required to communicate with an instance of SQL Server. This can be very helpful if you need to create or manage firewall rules blocking unauthorized access.
  7. SQL Server End-Of-Life Schedule – This is a useful reference if you need to know if your version of SQL Server is still supported, and when it will no longer be supported.
  8. Common Database Design Mistakes – I short list of common database design mistakes, and how to avoid them in your environment.
  9. Free eBooks from Microsoft Blog – A list of free ebooks from Microsoft, in a wide range of technical topics from SQL Server, Windows, Azure, etc.
  10. Reset Password and Disable SQL Server SA Account – With auditors wanting all user accounts to have passwords that change at least every 90 days, or the account must be disabled, this provides some guidance on how to make that work with the SA account.

Happy New Year! I hope you will continue to visit this site for helpful information on a variety of topics.

When to Abandon a Technical Interview

If you have talked to people about your history searching for jobs, they will usually ask about your worst job interview or even if there was anyone you interviewed with that you just wouldn’t take the job. Every company has their own issues, but some are clearly not as good as others. There are things that you like or dislike about a company based just on the brief interview process. You hope you asked the right questions during the interview to establish if this is a company you are going to enjoy working for, if the people you will be working with are going to annoy you, and if you will just have an enjoyable work experience.

There are a few items that are red flags for most people, and they are easy to find if you ask the correct questions, and actually listen to the answers.

Management Dysfunction

You don’t want to work for a company if they are operating under management that is confused, dysfunctional, or absent. When you are asked if you have any questions during the interview, ask the interviewer if the department has solid, written, widely-used documentation for external support, internal support, software development processes, system change control, and if they have recently updated management policies. If they seem confused by the question, change the subject, or maybe they just explain they don’t have those yet, you might need to apply the brakes and look for an exit from the interview (unless you are specifically looking for this type of opportunity).

While some very small shops can get by with a seat-of-your-pants approach to information technology processes, a shop of more than a couple of people needs written procedures and policies. A really strong manager can lead a small group without formal written procedures, but this is fairly rare.

Do you want to come into a department that is in chaos? A department without clear expectations, no written policies, and disorganized team procedures? What you are probably looking at is a deeply ineffective IT team. You shouldn’t be the one person hired to set the entire IT department on the road to written procedures, creating a solid development environment, creating a enhanced relationship with internal and external customers, and fixing everything that needs fixing while working with a management team that doesn’t have the knowledge, authority, or ability to do these things before you were hired.

No company is perfect. There will always be process improvements that can be made to get better results from any team. What we are talking about here is a really bad department with no formal processes or written documentation and a management team that doesn’t see an issue with that situation. An exception might be if you are specifically being hired to correct these known issues, but it is important to understand the exact status of the department.

Poor Interview

The art of the interview is something that you have to learn. Most interviews fall in the average range, but you have probably seen really bad interviews. You will be more impressed by the department leadership, and the entire company, if the interview goes well.

  • Are they excited about technology? Do they understand the technology being used by their company, why they use that technology, and what skills are required to maintain that technology?
  • Have they read your resume? If you can’t be bothered to read the candidates resume, are you really serious about the process and focused on finding the best candidate for the position? If you have ever been in an interview when the interviewer obviously hasn’t even looked at your resume, you know what I’m talking about.
  • The company can’t get the correct people into the interview, they are too busy and are using their phones during the process, or are confused about who you need to talk to next might be signs they ar not ready for your involvement.

Too Formal

A business is expected to be business-like, and that requires a certain amount of formal work-related items like standard work hours, dress code, cubicles, etc. You have to look around and ask questions to determine how strict are these basic business requirements. Some things are big turn-offs and you should really consider you options:

  • Strict 8-to-5 work hours – If they expect you to support the production systems 24×7, and still be present each morning at 8 am, that is a sign they are focusing on process over people. What is your acceptable work-to-life balance?
  • Community Involvement – If they don’t support time out of the office for local user group meetings and SQL Saturday’s, how hard will it be to get a week or two out of the office for training each year?
  • Old Technology – If they aren’t willing to try new technology, that could spell real long-term issues if you have to support aging technology because no one trusts or understands the new technology. Are they still running SQL Server 2000 and Windows XP?
  • Cubicle Hell – You ask about an office, but they tell you this position can’t have an office? If that isn’t something they are even willing to discuss, this could mean there are some fairly strict company policies that might be illogical or too formal and aren’t challenged by your team management. What else is out there that you will have to address after you take the job?
  • Suits and Ties – Are you willing to “dress up” for work each day, or are you more comfortable with a t-shirt? You have to consider the environment if you can’t compromise on dress code requirements. You also have to consider the extra cost of maintaining extra work-only outfits.

Ask Tough Questions

Other items that might set off your “bad company” radar are:

  • No computer, cell phone, or remote access definitions. Who supplies your technology? How often are you allowed to get a new laptop or cellphone?
  • They want to you to be on-call 24×7, but they don’t supply a cellphone?
  • Ask about vacation and sick days, Not just allowed vacation days. When was the last time someone on the team took a vacation? It might be a difficult subject to bring up in an interview, but if they haven’t been allowed vacation days in a long time, maybe you don’t want to work there either. You will have to think of a tactful way to bring up the subject, without making them worry about your intentions.
  • Who looks at new technology? If new projects are requests from other departments, is the analysis of new technology supported by IT management?

Sample questions you might want to ask during your interview:

  • Why is this position available?
  • What kind of turnover does this department/company have?
  • What happened to the person that held this position before? Was he promoted or fired?
  • What do you like the most/least about working for this company?
  • Can you describe the work environment?
  • Can you describe the opportunities for training and professional development?
  • What do you feel are the strengths/weaknesses of this company compared to the competition?
  • Who investigates new technology at this company?

Listen to the answers and don’t be afraid to pass on those jobs that don’t fit what you are looking for in a career. Can you think of additional questions you might ask to expose more about a company during the interview process?

I hope this helps you understand that the questions you ask during the interview are important.

Technical Interviews


Technical interviews are basically the process of conducting an interview for a person applying for a technical position. You need to make sure you ask questions in the interview that will help you determine if that person will be a good fit for the team, and if they have the correct technical skills for the position. While this seems easy, the problem is made difficult by reading a couple of hundred resumes and having to interview all the qualified applicants while you are also holding down a full time job.

In this article by Nicolas Bize, we learn how his interview process evolved.

The one question to rule them all
I can remember exactly when I first started programming. QBasic was shipped with MSDOS 5.0 way before windows 3.1 came out. It contained its own help screen with all of the functions and keywords of the language, like the perfect offline man page. To this day I distinctively remember the feeling that grasped me every time I hit F5 and saw my programs execute before my eyes. A single printed line, a prompt for a name, some colors, a puzzle… I was in heaven. I remember putting line numbers before each command, filling my code with horrible GOTOs, learning with excitement and fascination something new everyday. I loved programming. I would spend hour after hour creating games, solving problems, showing stuff to my parents and friends. Years went by, I went from qbasic to pascal to vb, wrote games for our BBS “Atomic BBS” that we ran from our home phone line through a 2400bps modem. I wasn’t really good. Well in fact I really sucked and my code was pretty horrible! But man did I love it!! I just couldn’t let it go… I guess some people feel that type of adrenaline the first time they fly a plane, sail a boat, smoke weed, eat at in n out… For me it was programming, compiling, executing. I gained that feeling 25 years ago, and it has never left me since. I was born for this. I’ve always been a programmer.

I have always been convinced that those who love code do not restrict their coding activities to their work. They take home that love and continue to create for fun as a hobby. How many times have I felt frustrated at work because of a struggling eclipse, only to find relief and joy when writing ruby on rails code back home!

And so it was, that after 1 year of trial and error, I completely stopped handing out technical tests. I would sit down with the candidate, read and comment his resume without asking him any questions for a good 5-10 minutes. And then I would flip over the resume, look at the candidate in the eyes and ask: “we have about 30 minutes left. Will you please tell me about the best project that you’ve ever created?”

That simple, unique and nonjudgmental question was the key. Some answered vaguely about their previous work or school project. And then some others became suddenly alive and excited, even those who appeared to be the shyest. They would talk passionately about the game they were creating, the website they had made, the open source projects they had contributed to, the utilities they made after being stuck in the middle of nowhere without any internet access. They were proud to show me. I was always fascinated by what I heard and would ask about all the details of the project they had treasured. They opened up and talked about the technical difficulties that they had overcome, about the little personal touch they added. It was their baby. And as they talked it was impossible to miss: I could see that light in their eyes, the excitement of a child that compiles and runs his first hello world. I would know right then that we had something in common. They were programmers too.

Most of them didn’t have a clue about struts or some other specific framework we were using. Yet once they got the job, they always ended up being golden developers. They learned faster, they produced better code, they inspired others with their creativity and positivism. They were coders at heart.

And in the end that’s all that matters.

%d bloggers like this: