Jordan: I thought that one of the best ways of understanding this is to actually perform an interview. In this video, what we're going to do is Stephanie is going to talk to me exactly like I am a job candidate.

I just graduated from code school and I've come to her office for a company that I'm interviewing for. We're going to run through it exactly like we would in a normal job situation.

Stephanie: Absolutely. Thank you so much for coming in today. I really appreciate it.

Jordan: I greatly appreciate the time.

Stephanie: So tell me a little bit about yourself.

Jordan: I've been developing for a number of years. The technology stacks that I focus on are Ruby, and then Rails on the back-end for API development. I've used both Vue and React on the front-end for a number of projects that I've built through the years.

Stephanie: Awesome. Tell me what do you know about Bottega?

Jordan: For Bottega, I have seen online, I've read quite a few of your blog posts, and I've seen some of the technology stacks that you teach, and that you use to build your systems with.

I've also looked, and I was really excited, to see some of the new projects that you're currently building right now. Especially, the new React project for being able to communicate in real-time with students.

I was really excited about both, some of the things I've heard about Bottega corporately, but also I'm really excited about some of the projects you currently are building.

Stephanie: Awesome. So tell me, how do you keep up to date in the latest tech?

Jordan: That's a hard thing because the latest tech is changing constantly. I try to take a pretty systematic approach to it. I attend local meet-ups all in the area. I hear from other developers where they're talking about new technology stacks and tools that they're using.

The thing that I've found to be the most effective for me personally is I have a number of side projects that I work on. Their goal isn't really to make money or to do anything real, it's more so they give me the ability to practice some of the new technologies.

So whenever a new version of React comes out, I can go to one of those projects. I don't have to be afraid of making customers mad, or anything like that. I can go, I can upgrade to the latest version, add some of the new features.

That gives me hands-on in a production environment because it's a real live application. While also kind of giving me training wheels to be able to practice it without risking losing a company's money, or hurting the experience for users. Those are some of my top approaches to it.

Stephanie: Great. So what beta technologies are you currently testing out.

Jordan: I would say the very latest one is Vue CLI. A few weeks ago, they released Vue CLI version 3, where they've completely re-did the entire architecture that gets built automatically.

So the Vue CLI, I know Bottega doesn't use it, but what it usually does is it gives you the ability to scaffold your application. In the latest version, they completely re-did the entire code base to the point where it gives you a different result than you used to have.

It allows for easier deployment to tools like Heroku. You can manage your environments and your environment variables a little bit better. I've really been enjoying that.

Stephanie: Okay. Tell me what you're passionate about in the world of software development? Why do you do what you do?

Jordan: I absolutely love, and for years what's really drawn me to software development, is being able to take something from scratch and be able to build something that other people love to use.

So being able to take something from an idea, all the way up through all the steps of development, and watching the project evolve, adding features, being able to clean it at different stages, and then have a fully functional product that hopefully makes people's lives better.

Stephanie: Wonderful. So here's the scenario. You say that you are working on a team of four, you get your assignment, you look through it, and you realize that you're in way over your head. What do you do? What's your protocol?

Jordan: Well, that only happens on days that end in a 'y'. Whenever that happens, because I know everyone runs into those scenarios, I would say I would first go and I would try to break up what was given to me in pieces.

Because if my first reaction would be simply to go and tell my supervisor or manager that I don't understand it, that's not really helpful for anybody. So what I try to do is break up the problem or whatever I need to build into pieces.

More than likely I will know how to build certain parts of it. So say it's building an authentication system. I would go, and maybe I don't know how to build the full thing, but I do know how if I break into pieces I may know how to build the API portion of it. I may know how to implement session management.

From there, I just need to know the parts I'm missing. If this was the approach that the system architect gave, they most likely it know more than I do. So they could very well after I've shown them how I understand pieces 'a', 'b', but I need help with 'c'.

That would get a lot closer to the finish line, both in me understanding it, but also in being able to go and build it.

Stephanie: Great. OK. Tell me about a project that completely failed. It's dead. It's not coming back from the dead.

Jordan: There have been a number of projects I've worked on that simply didn't work. I would say one of the worst ones, one the worst projects I've had the opportunity to learn from, I should say was: we as working for an energy services company, and they were built on a Microsoft stack.

So half of their projects were all built using things like ASP.net, C#, and that kind of technology stack. They hired me and wanted me to build rails applications. At first, they were going to be standalone projects, they liked those projects, and so they decided you know what we want you to make all of them interact.

The twist was that those old legacy applications didn't have any kind of API. There was no way of directly interacting with them, and so what I had to try to do, which was very challenging, was to build out an authorization system that could be shared across all the systems.

It used Active Directory, and it built a session management system where you could have essentially, a single sign-on. You could sign in on one application, then you could access all of the others, and then they could interact.

The project actually worked, but it became so messy and so convoluted that the decision was eventually made just to move on to a completely different set up that was built a little bit better from a communication perspective.

We ended up getting rid of all the old legacy applications. We kept a few of the rails ones and then built a more cohesive system.

Stephanie: Okay, so what was the main thing that you learned from that project?

Jordan: There were a number of things that I learned from a technical perspective. Things that turned out to be much more challenging than they may have appeared in the very beginning.

The main thing that I learned was if we would have taken a smaller approach, so instead of us going and spending a year trying to build out this system, if we would have just tried to connect one thing to this system and just had one application then it still would have failed, but it would've failed very quickly.

We would have seen that there would have been no reason to continue on in trying to connect all these big systems, and we would have saved a lot of time and resources. Once we tried a little bit of a smaller approach.

Stephanie: Okay great. Tell me about source control. What kind do you use, and why is it important?

Jordan: I've used git for a number of years. That is vital for pretty much every project. Every other command I seem to enter in the terminal is using git and version control to make sure that I'm always managing my commits.

It's vital not only for my own projects and when I'm working by myself, but it becomes simply required when working with the team. So whenever I'm working with a team of other individuals, that's how we can manage to make sure that what I write doesn't overwrite someone else's code, and vice-versa.

As far as the technologies and repository management systems, I am most familiar with Github, so I've used Github the most. You can see my profile for all of my open source projects on there. I've used bitbucket as well, which connects to Jira and some of those tools. and then I've also used Gitlab on a few projects.

I'm very familiar with any of the popular git hosting systems.

Stephanie: Great. Tell me about the documentation. How do you document or do you document?

Jordan: Well, documentation comes in a number of forms. I am not a big fan of code comments. I've actually written a few blog posts, specifically on that topic. One of them made it on the home page of "Why Combinators Blog" because it was such a controversial topic.

There's a rift. There are people some people say all your code has to be commented on, and other people say that you shouldn't comment any of your code. I personally feel I lean more towards not using comments that often.

One of my favorite quotes is that "code never lies, but comments sometimes do." So comments, if you build and build these gorgeous comments explaining all the inputs the outputs, and explain the behavior for a function, and then later on you go and there was a bug in that function.

You change the function, you change the behavior, maybe you changed the required input, but you don't go and change that comment. The program works, but anyone else coming back and looking at your code, later on, is going to read the comment, expecting that it's accurate, and then they're going to go follow its instructions and then break the system.

That's where I try to not use any kind of comments as a crutch. I feel like a lot of times the comments you write are simply you being lazy in how you're naming your variables, your methods, and your classNames. So I try to be very good.

In fact, I have my thesaurus on speed dial. So my variable names and class names. I try to make them so descriptive that myself six months later or team members who never even see the code, can look at it and instantly know what the goal of that function is.

Stephanie: Great. Do you test your own code, and what do you use to test your code?

Jordan: Yes I do. Whenever I'm building out rails applications, I use our rspec. I use rspec for test driven and behavior driven development. I do it for the APIs I build, along with the regular MVC applications.

I'm relatively strict with writing my tests first, watching them fail, and then building the implementation. The normal just TDD BDD kind of cycle. So that's what I do on the back-end. On the front-end, it usually depends on the project I'm working on.

If I'm working in a team and they want to use Jasmine for the testing framework, then I'll use that. I'm not as picky on the front-end, just because there are so many tools out there. I don't want to get locked into only one of them because with all the projects I've worked on, it seems like it's been a different one every time.

There's not a point in really focusing specifically on one, but what I've found is so many of them are so similar to tools like rspec, and some of these other testing frameworks that it doesn't take me much time to adjust from one to the other.

Stephanie: Great. So you know I think that you're a fantastic cultural fit for our company. You know you seem to follow the same practices as the rest of our team. I'd love to pass you on to our technical hiring manager. Before I do, tell me what value would you add to the team if we brought you on?

Jordan: I would hope that I would be able to bring a level of a transparent developer. So if I understand something I will be clear on it, but if I don't I'm also going to have the same approach.

Through the years what I've seen is if you have a developer who's not honest with what they understand and what they don't, they end up just wasting a lot of everyone's time as they try to kind of clobber their way through something. Usually, you end up in a worse situation.

Whereas, what my approach is, is I really try to focus on my strengths and then anything that I may not know. I try to tackle those right away. Whether it's asking someone for assistance on it or being able to figure it out myself but do it in a way where it's not wasting the organization's time.

Stephanie: Fantastic. Great. Do you have any questions for me?

Jordan: What is your, for this specific position, what does your dream candidate look like? Whether it's from a skill perspective or how you're looking for them to fit in culturally. what kind of things are you looking for?

Stephanie: Dream candidate would be someone who is technology agnostic, someone who keeps up to date on the latest trends, and knows what's going on in the industry. That way we can keep an eye out, and make sure that we're keeping up to date internally.

I'm looking for someone who will mentor the more junior members of the team, and be open with them about feedback. Not only taking feedback yourself but giving constructive feedback.

Jordan: That's important. Hopefully, I can be that. Thank you so much for your time, I greatly appreciate it.

Stephanie: Absolutely. Thank you.