Technical Interview Prep: Phone Screen Fun

So, I got some good feedback from my Prep for your interview post. So, I've decided to cover some more topics in this realm. Hopefully, it will help a person or two. I won't be giving away the secret code to land any job, but I may have a hint or two.

Technical Trivia / Useless Trivia

Let me first say, that I typically try and stay away from asking questions that need to be memorized. i.e. "What does the {insert_method_here} do in the {insert_random_library_here}?" Though, some interviewers like to ask them, so you better prepare just in case.

Object oriented programming is usually a nice topic to be quizzed on over the phone.
What is a class? What is an object?
I like to think of a class as a blueprint of something. The object is the end result you get from the blueprint.
What is the difference between an interface and an abstract class?
Think of an interface as a contract. It will only describe what the implementing classes should look like. That being said, there are only signatures in an interface and an interface cannot do anything.
Now as for the abstract class, it actually is a class. It can define some methods to group similar class actions. For example, you can have a Dog abstract class with walk(), bark(), eat() as abstract methods. Then, specific dog types can extend this Dog abstract class and add their own individual methods that are specific to each class. So for example, maybe you can extend the class to be YourDog. Your dog is smart, it can rollOver(), sit(), stay() as well as the walk(), bark(), eat() actions. Silly example, but you hopefully get the point!

Data structures
What is an array? What is a hashtable? Compare the two.
An array is a contiguous block of data that can be accessed via indices. A hashtable is a data structure that maps keys to values. It would be good to note that a hashtable is implemented with a hashing function to translate the keys into indices of a backing array to store the values.

Paired Programming

If you thought coding while someone is watching you was weird, you may feel that similar distaste for paired programming on a phone screen. It's awkward. You have to try and find a solution to a problem while keeping the awkward silences to a minimum. That basically means, talking through how you are going to approach the problem. If you are anything like me, that means you'll end up saying something completely nonsensical numerous times. To try and keep those to a minimum, try talking a little slower.
I love giving FizzBuzz to folks. It should be relatively easy for you to get through this problem within a couple of minutes. Practicing coding problems is the way to go as they'll help you to be able to identify how to approach other problems.

Lots to do, lots to review

Obviously, there is a lot of topics to cover. Interviewers all have their own style of interviewing. Prepare for the worst is always a safe bet and hopefully all will go fine!

By Adrian Cruz | Published Dec. 9, 2013, 5:12 p.m. | Permalink | tags: coding interview

Let a Baby Pick Your Passwords

Random Passwords Are The Way to Go

If you care about the security of any of your accounts you would be sure to pick a strong password. If you don't care, then sure, go ahead and set your Password1 or 1234567 password. But seriously, as a person who has worked in technology for years now, you would be surprised how many folks have the simplest passwords.

Use a Password Safe

Use a password safe and then you can probably get a baby to pick a nice random password for you. Really, I let my son play with my laptop for a bit (the fun stops when he starts pulling keys out) and this looked nice and random. But be wary of the spaces (not all systems support a large character set). Most password safes support creating random passwords for you if you don't have a baby handy!

If you want to take security a step further, memorize a part of your password and store the remaining part in your password safe. That way, in case someone manages to hack your password safe, they're left with random passwords that are meaningless.

Birthdays, Pets' Names, and Telephone Numbers

No, I am not recommending to use your birthday, nor your pet's name. Well, not really. You can do so, but change it ever so slightly. One suggestion is a Caesar cipher. If you have a dog named, "Fido". That can be converted to "Svqb". This can be your part of the password that you have memorized. The rest of the password can be in your password safe.

Obviously, you'll need to rely on your memory. But the key is to be secure while allowing yourself to remember how you have secured it. There are a lot of simple, yet effective tricks to creating strong passwords. If you want to be secure, start with strong passwords.

This text has been secured with ROT13 twice for maximum security. ;-)

By Adrian Cruz | Published Dec. 2, 2013, 7:47 p.m. | Permalink | tags:

Prepare for Your Interview!

So, We're Hiring

So, I've been interviewing candidates lately and'd be surprised about some of the candidates that come in. No, really. Maybe they had an off day, maybe they were super nervous. But, here's a guideline (more or less) on how to beat that technical interview.

Prepare to Solve a Problem

What I'm looking for when I interview is not silly trivia that you can search online. I honestly, hate questions like that. What I am looking for is to see what it would be like to work with you. No trick questions, no need to memorize all available methods in a specific class, et cetera, nothing but seeing your problem solving skills. That being said, practice solving some problems. There are a whole bunch of sites where you can find problems and sometimes their solutions.

Speak Up, Speak Slowly

So, I like to give small problems that can be finished within an hour. I purposely state the problem with minimal details as possible. Why? Well, I want you to ask questions! So speak up! I like to get to know how you think things through, so ask away! You would be surprised to see how many candidates that would just dive into coding.

tick. tock. tick. tock. Yes, the time is ticking, but that doesn't mean you need to start rambling on in a jibberish manner. So, if you are anything like me, you end up talking faster and sometimes blurting out things that don't make sense when you are nervous. Yes, I mentioned that you should speak up so I can know what you're thinking, but that doesn't mean I need to know everything that comes out of your mouth. Think about what you want to say and try and speak slowly.

That said, here is a small list of things to study:

  • Your CV!
  • The company you are interviewing for
  • Data Structures
  • Algorithms
  • Design

Regarding my short list...

I truly mean study your CV. Do not do a keyword stuffing just so your CV looks good. If it's listed on your CV, that means it's fair game to ask you questions about it.

Also, please do research a bit about what company you are interviewing for. It shows the interviewer that you show interest and you're not just sending out your résumé everywhere looking for a job. I mean after all, you're going to spend something like 70% of your time at work, you probably want it to be a place you enjoy coming to!

The remainder of the list is a given. I'm sure you knew that you should be studying data structures and algorithms already anyhow!

Cheers and good luck!

By Adrian Cruz | Published Nov. 15, 2013, 4:56 p.m. | Permalink | tags:

Today I Learned: Bootstrap Has Built-In Code Blocks

I was thinking about how I was going to handle sharing code on this site. While I can surely use a GitHub Gist, it is obviously not ideal for sharing small snippets of code.

So for example: This is code. No, that really wasn't code, but you get the point!

To use it, just use: <code>{your_code_here}</code> Look at that, I got to show another example! ;)

By Adrian Cruz | Published Oct. 16, 2013, 3:42 p.m. | Permalink | tags:

Interview With a Stranger

So, I recently met a bunch of guys at a meetup. They were discussing the way their respective companies do interviews. I became intrigued, introduced myself, and we began to chat. For the majority, they either gave "homework" problems to solve or do some pair programming. So then, the fun part: interview questions.

For the most part, the questions were fairly easy; especially since some interview questions were so common that even I have used them when interviewing a candidate. But then, one of the guys wanted to test out an interview question and singled me out. He even wrote out on pen and paper the expected input and output of the program. I was really surprised! But most of all, I was now ridiculously nervous!

The Problem: Write a function that takes an input String array of names to pair up participants in "Secret Santa". The function should return a two-dimensional String array of the chosen pairs. Sounds easy, right! Yea, it should have been, but for whatever reason, my mind went blank.

I stumbled around with my words; probably said, "uh um" a dozen more times than I usually do. It was like I totally forgot how to program. It was humiliating!

The fellow was nice enough to give me hints as I finally started to find the right approach, but the solution was pretty sub-par. I hang my head but laugh it off. Me as an interview candidate: FAIL.

Now at home, that problem bugged me, so of course I took to an actual implementation. I finally was able to sit down and take my time with the problem. My issue was that I didn't attack the problem with the correct data structure. I was too busy fiddling with getting a random integer to get pairs, while I should have just shuffled the list, and used that list as a queue. Sheesh!

TL;DR When you are interviewing, try and relax, breathe; if you think you are over-thinking something, you probably are. Remember all of your data structures you have at hand!

Here is what I find a more acceptable solution than what I originally wrote out. So, to that fine gentleman that I met the other day, please excuse my poor coding the other night!

By Adrian Cruz | Published Oct. 11, 2013, 9:04 p.m. | Permalink | tags: coding interview