Justin, the campus director, addressed the entire squad today. We rarely get a speech from the head honcho–one welcoming soliloquy on the first day and the occasional off-the-cuff when Caitie was out of the building and a company was in for a showcase. Though brief, his talks have always had a clear and practiced structure to them. The point of this one: everyone needs to chill out.

The vibe at Tech Elevator since the matchmaking has been intense and strange. And it’s a vibe that Justin has experienced twice before. It’s not too bad yet, but the storm is brewing. The rumors are flying–somewhere between eight and ten people have heard back from companies in one way or another. Those who have not heard anything are doing their best to remain cool.

As Justin’s speech gave way to Caitie’s presentation on what to do follow-up-wise with the companies from matchmaking, Jason sat next to me with his eyes closed, breathing deeply. When there was a pause in Caitie’s presentation, I leaned over and asked, “Are you ok, buddy?”

He said he wasn’t. Why, he wondered, when a third of the group got a callback, he hadn’t. Had he said something wrong in the interviews? Did he screw them all up?

It made me feel terrible. The thing is, Jason is a really, really good coder. I hit him up for help all the time. He’ll certainly be snatched up by a company, and when he does, he’ll be extraordinary, particularly for a junior level programmer. But I know it doesn’t seem like that to him now.

All of us are experiencing more than our fair share of anxiety this week. Those of us fortunate enough to get an early callback had some of that burden lifted from our shoulders. The bad thing is, that weight was put directly onto the shoulders of our comrades.

Yes, I did.

And I’m very relieved by it.

Today was another odd day at Tech Elevator. Some people had interviews and others didn’t. I didn’t have one. Instead of canceling the whole day, Tom decided to give a tutorial in the main room on BootStrap. More on that later.

I got in early and everyone around me was suited up and geared for more interviews. I set up my computer, wearing jeans and a T-shirt. It made me feel anxious. I sorta got the sense, as ridiculous as it sounds, that I was being left behind and not doing enough. Before Tom’s lesson I applied to another job and that made me feel a little better. But with all the hustle and bustle going on around me, the tense air of an interview room, I was distracted the whole time.

Luckily, I’ve used BootStrap before, albeit briefly. BootStrap is a way to make your website look nice without having to deal with the greased-up-crocodile which is CSS. It’s a helper to keep your website looking neat and centered. Part of the training material for Tech Elevator contained some things on BootStrap and, though I had trouble focusing, the information that Tom covered seemed familiar. I took some notes and Tom will send out his lecture code, which always helps me more than any tutorial or youTube video.

I stood up from the lecture, looking over my notes, feeling full of anxiety and basically exhausted by it. When I got back to my computer, I found an email from the top pick on my wish list, telling me that they enjoyed our conversation yesterday and asking would I be interested in discussing further opportunities. Yes, please.

What a weird day.

Here’s the set up: There were nine companies stationed all around the classrooms and offices of Tech Elevator. Each company sent two representatives to ask questions and have conversations with the students. All of the students were in the Java classroom, suited up and waiting around nervous as hell. My first interview wasn’t until 3:30 and I thought I was a being a spazz by showing up at 1:00. But Jason, who’s first interview was also at 3:30, had been there since 9am. I assume he was alone.

When my fated time drew nigh, I stood by the door of the Java classroom with the other students who were scheduled at 3:30, like a pen of farm animals about to be thrown some grain. On Caitie’s go, we wobbled anxiously to whatever office where our interviewers were housed and sat down to have a chat.

I had half a dozen stories prepared to deal with any behavioral questions that were thrown my way, but I don’t think I used even one of them. The interviews were more like conversations. They flowed without a ton of structure, hitting points sometimes technical sometimes behavioral. I suppose I dipped into my stories for a factoid here and there, but I went through three sessions without once being asked to tell someone about a time when (fill in the blank).

It went really well. All of them. I’m not sure how they could have gone much better. I seemed to connect with each interviewer in a different way, each meaningful on some level.

However, these interviewers met with a slew of students before and after me and overconfident-sunny-sidedness has always been a fault of mine. Do I expect callbacks? Yes. 100%. Will I get them? That remains to be seen.

What a weird day.

For the last few days we have been covering APIs. It’s a subject that has loomed in the background of almost every technology we’ve covered thus far, particularly the MVC apps that we were building a few weeks ago.

It’s been difficult. Today, I went to Tom’s office and confessed that I’ve been having trouble, basically asking for a personal lesson. I don’t do this often. Or ever, really. I try to figure out as much as I can on my own and only hit up Tom if I know I’m stuck on something stupid. I figure when I’m on my own (hopefully in less than a month), I’m going to have to figure out a lot of this stuff through my own google searches, so I may-as-well figure out how to do it earlier rather than later. But today, I felt pretty lost.

The thing is, I don’t think that APIs are that difficult to figure out. API stands for Application Programming Interface. It’s a way to get a lot of data without keeping your own database. Think of it as one application connecting to another application for the means of accessing info. Almost every website you use either has an API or connects to someone else’s. It’s a little tricky, because we’re using Vanilla JavaScript for the front end, a language which I’m learning at the same time as I’m learning about APIs. But, really, you just have to put in the right lines of code in the right order and everything will work. There isn’t a ton of tricky logic to it.

I think my difficulties are really an aggregate of several things. JavaScript is new to me, I’m more adept at C#. We’re not doing as much homework and, though I know I should be pleased with this, the lessons aren’t being pounded into my head with repetition like the lessons from week’s past were. I have three interviews tomorrow and those seem more important than learning the daily lesson. And, when it comes down to it, I’m probably experiencing some burnout.

I remember a speaker from one of our showcases. He was a former TE graduate who is now working at a company. When asked what the most challenging thing about his new job was, he said, “Probably dealing with the APIs, because when we learned about them it was the end of the program, I was looking for jobs, and I was totally burned out. I couldn’t focus on anything. “

At the time I thought, “That’s not going to happen to me. I can keep pushing and pushing and pushing. It’s only fourteen weeks. I could do this for a year if I needed to.”

To a degree, it’s true. I can keep going. I can keep putting in long hours. I can keep completing the homework and focusing on everything Tom says during class. But things just aren’t sticking like they did a few weeks ago. Sometimes when Tom’s talking, I’m listening to each individual word and it seems like they don’t fit together into a logical sentence. Maybe my brain is all filled up.

I have interviews and no class for the next two days. So there won’t be new information and there won’t be new assignments. This is good. The interviews are anxiety-inducing, but, really, I look forward to them. They’re a long time coming. And maybe two days of behavioral interview is just the rest the logical side of my brain needs.

Many things are happening at once to the monks of Tech Elevator and we must react to each the best we can.

Two matchmaking events will happen next week–one on Tuesday and one on Wednesday. Tuesday will be a mix of companies and Wednesday will be only Dick’s Sporting Goods, here to interview all who are interested. There’s a ton of preparation that goes into handling this event. We have to prepare ourselves for the behavioral questions by coming up with examples of our good work habits from years past. We have to bone up on our vocabulary and technical processes to deal with the programming questions that might get thrown our way. We have to research each company so that we can ask sensible and pertinent questions of our interviewers. And we have to quell the anxiety-monster raging in each of us, disrupting our sleep and making our voices timid and shaky when speaking with strangers.

Oh, and there’s still class too. Still three-hour lectures and accompanying homework to contend with. And it’s important stuff. If you want to sell yourself as full stack, you better know your JavaScript.

Today we covered Event Handling with JavaScript. Much like TE students must prepare for the upcoming blitzkrieg of interviews, a web page must deal with the nonstop events that occur in their domains. Each click, each highlight, each move of the mouse can change what is happening on a web page. Tom taught us how to do this today, setting surprises all across our HTML, like booby traps in the forest, waiting for users to scroll across them.

It was fun. It’s my favorite part of JavaScript so far. And it feels good to keep adding to the rubber band ball of knowledge I’m building, band by band, to bounce during the upcoming matchmaking events.

Still in the throws of learning JavaScript, we had a second round of mock technical interviews today. Our last technical interviews were with the teachers at Tech Elevator and these ones were with people from outside companies.

It certainly put a different spin on it, having someone we don’t know ask us these questions. It was a bit more nerve-wracking, but most likely closer to the scenarios we will soon be experiencing in the non-mock interviews. The same questions were there–object versus class, the three pillars of OOP, describing the MVC method. These queries are beginning to feel familiar.

But one thing was new and one thing was missing from our first interview. There was no white board test. This was nice, I suppose, but I could have used on more (Though, it’s my understanding that getting an actual white board test in an interview is unlikely). The new question was one of architecture. I was told there was a website of real estate properties. They wanted to have users be able to log on, peruse the properties and add favorites to a list which would be remembered for them. On top of that, they should be emailed whenever the properties were updated (price dropped, sale pending, ect).

It was a different way of interviewing and, though I think I did all right, I found it difficult. It would almost be easier to write it down than to simply say it out loud. I think that if I get a situation like that in a real interview that I will write it down and explain it as I do so.

So, the mock interviews are worth it, in that I learned this lesson in a place of no consequences and can apply it in real life. Score.

Our instructor, Tom, is not a fan of JavaScript. He’s a C# guy. But this week he has found himself teaching a room with 16 eager programmers bent on warding off the anxiety of the job search with a few hours of coding. We want to learn. We’re ready for the distraction.

Though Tom doesn’t often use JavaScript in his professional life, he knows it inside and out. And if he stumbles across an issue he doesn’t understand, it’s solved within seconds. But there is an element of exasperation in his teaching tone as he discusses some of the rules of JavaScript and their differences with his beloved C#. He refers to many of these differences as “Black Magic”. Mysterious, chaotic code which yields dubious outcomes.

It’s funny. It gets a laugh every time.

C# is can be called a “strongly typed” language. You have to declare a number as an “int” before you use it in a variable, you must declare text as a “string”. Not so with JavaScript. Make a variable and it can be whatever. Yes, no, true false, 5, banana. Doesn’t matter. JavaScript doesn’t care (another Tomism on the subject of JS).

Whereas in C#, you must tell your methods exactly what variable types they should be expecting, JavaScript will deal with anything you throw it. How does it deal with it? Black magic. It will assume certain elements. Used correctly, its an easier language to learn. When things get complicated though, it will often end up doing things you might not have intended.

For example if you pass two parameters and you think they are 2 and 5 and you want to add them together, you might expect to get 7. However, if the parameters happen to be strings and you didn’t know, it will concatenate them instead of add them and you will end up with 25. Poof! You’ve been black magicked!

There are certainly some advantages. I mean, it’s the main language that programmers write front-end in, so there must be something to it. And also, it’s the first thing I learned in my programming journey. I studied JavaScript just after HTML and CSS when I was prepping for TE. So it has a soft spot in my heart.

Just like anything else, the more I study it, the more I will like it. Black Magic upon closer inspection will often yield good outcomes. We just have to be more diligent wizards.

Today is the first day that we are allowed to apply for jobs. The idea that I could be sitting down to discuss with a stranger what I know about programmer is nerve-wracking to some degree, but not so much. After the prep interviews, both behavioral and technical, I feel fairly confident in speaking with a hiring manager.

I don’t feel terribly confident about taking coding tests online. This weekend I took the coding test for Dick’s Sporting Goods and it did not go too well. Although I would have said the opposite just a few days ago, I think I would prefer the white board to a link in an email. At least on the white board, if I’m struggling I can explain to the interviewer what my thought process is and why I’m running into a road block. Alone, with nothing but a web page in front of me, a missed answer is nothing more than a missed answer. I have no opportunity to spin it.

All that aside, Caitie had an interesting stat. They crunch a lot of numbers on Tech Elevator grads and have come to some conclusions as to who gets jobs and why. They know who is more likely to get a job and when by gender, education level, skill as a student, and age. However, the variable that factors in the most is how often you apply for jobs. Students who applied for 1.5 jobs a week took more than 2 months to find a job. Students who applied to 3.1 jobs a week found one within 1-2 months. 4 applications a week? 1 month. And those who applied to 4.4 jobs a week or more were employed before TE graduation.

I’ll be applying to 50,000 jobs this evening.

Well, maybe not.

The issue is that applying takes time. Not only filling out applications, but the results of doing it. If you apply to 10 jobs in a day and then three of them send you a coding test or try to schedule interviews, you could hit a real time crunch. So you have to plan this thing just right.

I’m thinking about hitting up 6 or 7 a week. That should work. I think.

It’s 7:23 pm and I’m still at Tech Elevator.

It’s partially my fault, but mostly the fault of the capstone. We’re tasked once again with the development of a site for the national parks, but this time we have to make a fully functioning website.

The first day (yesterday) went fairly well. Brandon and I made all of the different views (think web pages that are glued together on the same site) and got all the appropriate data out of the database. The first day was challenging but fun. The second day was challenging.

So, our problem was that our user can see the daily forecast. And, on top of that, they can see it in either Fahrenheit or Celsius, depending on what they choose from a drop-down menu that we supply. But the rub is, their choice must stick with them for as long as they are perusing the website. For this, you need to write a session.

A session is a piece of code that lets the website remember choices you’ve made or rights that you have so long as you stay within that session. Think of when you log in to your bank account. You go to XX-bank, you log in, and all of your information appears. If you would bring up another browser and go to XX-bank, your information wouldn’t be there. It’s only on the one where you logged in. Only on the one where you created a session.

So, we need to create a session where the user chooses between Fahrenheit and Celsius and their choice need to stick with them for as long as they are on the website.

It took us all. Freaking. Day. Like, literally all day. From 9 am till around 5:30. But we got it. We got the session. Success, I suppose.

I’m going home now.

It went just fine.

We started our third capstone today (more on that in another entry) and I was working on it from 9 am right up until my my mock technical interview at 3:15.

Actually, that’s not totally true.

I’m paired with Brandon on this capstone and I told him around 2:45 that I needed a break because my interview was coming up and my brain had turned to oatmeal. But there really are no breaks at Tech Elevator. I paced around in the main room trying to clear my head and ended up helping Argun figure out how to write a Session in his code. And, actually, I didn’t help him. I tried. But I have no idea how to write a Session unless I look it up.

At 3:15, Matt came out of the interview and I went in, to speak with Tom (Java) and the teacher-in-training Beth (who is sometimes referred to as Not-Tom (or, in code !Tom). They started role-playing immediately when I entered the room. They were no longer Java Tom and !Tom, but two HR Reps from StruggleBus Software. We had a conversation about why I like tech, what my plans are career-wise, and some basic drilling on computer science theory. I would say I basically aced it.

Actually, not aced. I wasn’t sure what Tom meant when he asked about data-structures and he had to prod me on with a hint.

Then the whiteboard. Tom shuffled the deck of questions thoroughly and then looked at each card as he picked out my problem specifically. I read the question a few times, wrote my answer and got it right. Basically.

Actually, I had a return inside the for-loop and it should have been outside, but I moved it to correct place after a hint.

Then, upon a re-reading of the question, my interviewers rephrased it slightly so that it became much, much harder. I sort of crashed and burned on that one.

Actually, that’s not entirely true. Yes, I didn’t get the second iteration of the question right, but I was able to explain how I wanted to go about solving the problem in a logical way and to describe exactly what the challenges were in the problem in a manner that made me seem competent.

And Java Tom and !Tom told me so. Once they broke character.