Tech Interview Preparation with Aaron Scruggs:

Create a Web Presence:
Future employers will look at Twitter, blogs, Git, LinkedIn, etc and ask these 3 questions:
1. Is she smart?
2. Can she get shit done?
3. Do I wanna have a beer with this person?

Research the Company + the Interviewer:
Spend the time to read the job description and get to know about the company.
First question Aaron asks, “How did you hear about us, what do you know about us?”
Check their online presence also and find out who you’ll be interviewing with, “Who will I be interviewing with, I’d love to know their name.”
Find out what they’re interested in; an interview is a conversation and like dating, can be awkward
Find opportunities to stand out by knowing what the company needs and finding the intersection between what interests them and what interests you.

Interview Basics:

Being on Time:
Look up the address, look up time it will take to get there, have phone number on hand of interviewer. This is the most avoidable problem, so just figure out a way to be on time.Showing up on time shows that you understand time management, which is very important in software building, hugely important when it comes to estimating deadlines.

Coding on the Fly:
Bring your laptop, fully charged. Be ready to code on the fly in a dev environment that you’re comfortable with.

Note-taking:
Be prepared to take notes with pen/paper during the interview:This can also help with details during the technical portion. Also shows that you’re interested, invested and engaged in the convo.

Resume:
Bring a few copies; helps facilitate convo. “Just in case you wanted one, I’ve got an extra copy of my resume.”

Dress code:
Business Casual.
–> Consider context, larger the company, more formal the attire.
–> Overdressing is possible.

Nerves:
– Manage fears with honesty and understanding that it isn’t personal. It doesn’t mean that you aren’t qualified, it just means the needs and fit might be off at that moment.
-Aaron passed up on many now Ruby stars because at the time it didn’t make for a good fit.
You can only choose one company to go work for; you have to make sure it’s a good fit.

Questions to Ask the Company:

Questions to ask:

The first job is a leap of faith for employer, we have no work experience.

What will help maximize career in the long run? Could work for bigger company for more with less work but will it build up your experience as much as it should for future roles? Less exposure, more time to pursue other/coding interest outside of work. Smaller companies will allow for learning more about the full dev experience and possibly accelerate your career more quickly. Either way, 0 work experience in dev = not much room to negotiate. There are tons of Ruby jobs available and not so many Ruby devs looking for jobs BUT the first company we work for will

Ask About the Basic Work Environment
Ask about parking, perks/features of the office (snacks, showers, etc.), and where you’ll be working inside of the office. Example of beautiful building, but office in a closet.

Ask about the Code
When you start talking to peers / coding supervisor, ask, “Hey, can I see the codebase?” –> shows level of interest in your profession that most of your other peers interviewing will not be showing. Also, shifts some focus away from you, while making you look really good.

What are some of the first things you’d have me do?

Ask About the of Development Environment
VCS and other details of projects, version of Ruby, version of Rails, rackware, own servers, etc. Helps you check the list of companies closer to the tech stack you know now will help you hit the ground running because they will be closer to what you know.

Ask About a Continuous Integration Server
Keeps us honest by testing any new commit and sends email with person’s name who broke the build.

Ask if they use it and how they use it –> looking for a company that uses it and has a strategy with it. Raise an eyebrow to anyone who says, “Yeah, I wouldn’t worry about that.”

Ask About the Coding Process, Support System and Feedback Methods
What kind of tip tracking do you use? *great question to ask.
fugbuzz, pivotal tracker, asana, Lean, Agile, Scrum

How will your work be evaluated and how will they let you know if you’re doing a good job, if you’re not, how will they let you know? How often will you get one-on-one feedback – weekly? quarterly? annually?

*The first job is the most important for getting feedback, because it will be shaping our future dev skills.

Questions not to ask:

No need to try to determine if a company has funding. Instead, try to determine if they will be worth the work. If they want free help or sound sketchy, don’t bother.

Salary + Benefits:

-Should be talked about at the right time; don’t jump into this one. Wait towards the end of the interview process, there will be a clear time toward the end where salary will be brought up. Or, some employers might say, “Is there anything we haven’t covered that you’d like to know about the job?”

Others might ask what your expectations are. Respond with, “I’m new to this industry, I’d like to know from you, when it comes to a junior developer, what is the salary rate that I should expect?” This pushes the salary expectation question back onto the employer, while still being honest.

Prior experience can affect the rate we can expect. But mostly, no way to really know.

Work / Life Balance:

Nights, weekends? What’s the expectation for weekly hours? This is an uncomfortable question for employers to be asked.

It usually varies and no one wants to be held to a number or misrepresent the hours. You can try, “Inside of the last year, how many weekends has your team had to work?” Or try to be honest, “I’m new to this field and this role and I’d like to just understand what to expect.”

***Asking about salary, benefits and how hard you’ll be expected to work are the main red flags to employers.***

Technical Questions:

There’s no real list of technical questions; the last two months have been our preparation.

Get comfortable not knowing the answers. Be able to stay confident.

Overcome natural reactions and responses to not knowing: – Rambling on forever, taking the convo in a different direction -Trying to outsmart the interviewer; using bullshit and fluff answers instead of saying, “I don’t know.”

The 3 Appropriate Answers for When You Don’t Know the Answer:
– Show parts of your personality that will make you a great fit for that company
– Show how graceful are you when figuring out a problem. Show that you can be positive and constructive, even when you don’t have the answer.
– Exude curiosity and hunger for knowledge.
– Show your critical thinking ability by

1. Venture a Guess:
– If you have some idea, “You know, I’m not entirely sure, but I would guess _____________.
–> Don’t ramble, don’t overuse these one.

2. Ask for the Answer:
– “Man, I’m not sure. What is the answer to that?” or “You know, honestly, I’m not sure about that one.”
– Continue the conversation and learn in the process.

3. “I’m not sure, I’m going to have to look into that.”
– Write down the question, look up later and email the interviewer with the answer plus your thoughts on it later. **The element of surprise and follow up goes a long way here.

Soft Questions:

These are basically questions interviewers ask as, “Help me lead this conversation to something technical that you know the most about.”

Direct the conversation to the subject of your choice but answer with key things that interviewers want to know, like your specialties, and if you can be taught a skill to meet a need.
–> Spend the time to form opinions and specialties so that you can go for depth (versus breadth) on one thing, which will demonstrate the ability to learn something very well in order to solve a problem at hand.

Example questions:
What technologies are you interested in  right now?
What are you passionate about?
What was your main passion or focus at MakerSquare?
Recently, what’s a problem you’ve had to figure out?

Fizzbuzz:
– No idea what this is but Aaron said he’d 20x more impressed with some who were to say, “Yeah seems to make sense, let me read back over the reqs, let me know if I missed anything,” versus a candidate saying the understand fully and then leaving things out, not following requirements to a tee.

When to Start Job Hunting and Interviewing:

– After Thursday, Career Day.
– Don’t think of it as, “I need more time to get better at this one thing, etc.”
– Better to go for feast philosophy, than famine philosophy. Don’t put all your eggs in one basket; each interview is  practice and the positions that seem less desirable might actually lead to a cool role because you don’t know what’s in the works or who they might talk to about you, and what’s the worst that could happen? You could be offered multiple jobs?
– Keep coding. Keep going to tech meet ups. Don’t “take time off for laundry and family.”

When to Take an Internship:

– Look for an internship until you find the right position; reflects better than just job hunting for weeks.

– If they’re going to allow you to grow, to code, to work on cool projects they can’t justifiably pay staff to work on.

Recruiter Relationships:

– Take advantage of the free connections to possible jobs but feel free to end the relationship/conversation, politely, at any time.

– “Thanks for the interest. I’d like to pursue _____ right now, but I’ll touch base with you if something changes.”

Jobs in Other Languages:

– This is how I’d solve it in [ Insert Language You Do Know ], but I’d love to know how you solve it in [ Insert Language They Want You To Know ].

Q&A:

How common are some of the best practices we’ve been learning?

-Varies, but definitely holds more value for the learning process than coding alone at home.

-Talking about code and listening to others discuss it has helped Aaron grow.

-Don’t stay stuck on a problem for more than 15 minutes; pair program on an ad hoc basis, but this is subjective.

–> Would be wary of a situation where no one is around to bounce of off or ask for help.

-Usually better to write too many tests than not enough.

-Those who only use TDD don’t usually solve the real problem at hand; they have passing tests. Necessary to test to in a browser and use tests.

Are we qualified for junior dev jobs? How do we determine impostor syndrome from just being an impostor?

Job listings typically ask for way more qualifications than they are necessarily looking for – HR is a litigious area, and this covers them, legally, if subjective reasons are factored into a hiring decision.

If we can read and understand code, we aren’t impostors. There isn’t a need to know how to code without a computer and internet.

From Bonnie, “Oil painters take a picture of what they want to paint; they don’t just pull it out of their head, and the same is true for coding.”

Should we limit the amount of companies we talk to?

No. Get your name out there.

How many no’s should we expect before we get a yes?

1000.

Maybe a dozen? It was about that many when Aaron applied in DC 10 years ago. We’re more advanced than where he was but no one can say how many interviews it will take.

Key Takeaways:

Don’t be late.
Answer soft questions well.