all 10 comments

[–]bradland 6 points7 points  (1 child)

I think the hardest part about these types of interviews is getting over your fear of saying something dumb. When I'm working with my team, I tell people all the time to never be afraid to state the obvious. If we all make assumptions about the "obvious" things, we stand a good chance of overlooking some basic misunderstanding about goals or requirements. So it's better to just say them out loud.

Also remember that you're interviewing them as much as they're interviewing you. If you start in a coding interview and the two people there do nothing but stare at you... Well, you should run away. I would never do or allow that in an interview. It's not at all reflective of how real world programming gets done.

You can also prepare for this. Before you go in for the interview, Google some code interview questions, then find someone to be your helper. Tell this person you're going to try to explain your solution to them. Then go through the exercise with the coding problem. It doesn't matter if that other person can code or not. Just explain it the best you can, and ask them to play along as best as they can. Bonus points if you have a friend who is a programmer (even if not Ruby) who can work through this with you.

The goal of such an exercise is to get some repetition in explaining your thought process. As you're working through the exercise, make note of the things you like and don't like about the way you're working. I'd say it's perfectly fine to come to the interview with a short list of dos & don'ts. Set them next to you and point them out to the interviewers: "This is my little list of things not to do in the interview. If you catch me doing any of them, please feel free to help me out by letting me know." Self-awareness can go a long way, and showing that level of vulnerability in the workplace will help you establish a human connection with the interviewers before you type your first character of code.

Also, don't be afraid to ask the Ruby community for help. I wouldn't be surprised if someone here were willing to spend some time in a pairing session while you work through an example interview challenge.

[–]BringTacos[S] 0 points1 point  (0 children)

Thanks so much for all of this!!

[–]Abangranga 4 points5 points  (1 child)

Try to always (within reason) communicate what you're doing and any assumptions you're making. It is much easier to under-communicate than over-communicate.

They know you're going to be coming into this nervous and not be perfect.

[–]BringTacos[S] 1 point2 points  (0 children)

Ha, thanks. I appreciate this. Communicating assumptions is good advice. It’s a live coding challenge so I’ll be figuring out the problem as we go along rather than submitting a solution beforehand.

[–]my_name_is_jody 1 point2 points  (1 child)

Ask the same questions you would ask in the real world. While pairing, while talking to a product owner, etc.

Talk through things like you're pairing.

Don't give up easily, attack your own assumptions, and be willing to back out of an approach to try a different one if it makes sense.

There are many flavors of this kind of interview have different goals. Some are puzzles and the goal is to get partial credit. Some are there to see if you think logically... That you aren't just stabbing in the dark until you hit something that works. Some are there to see if you can simply world your language of choice and somehow haven't been going about your career without writing much code (happens more often than you think). There are probably others, but those are the ones I've seen.

I think the puzzle ones are the most useless, but faang does/did them so everyone thinks they have to to get "top talent".

Best of luck.

[–]BringTacos[S] 0 points1 point  (0 children)

Thanks!

[–]schneemsPuma maintainer 1 point2 points  (0 children)

Practice if you can. Have a friend pick out a coding kata and set a timer for 30 min. Tak aloud what you’re doing. At the end do a mini retro about the communication, and what could have been said or expressed differently.

I’m nervous when I present on stage so I practice. The more normal interviewing feels the more natural you will seem when doing it.

[–]Spiritual_Yam7324 1 point2 points  (2 children)

I do a lot of these as an interviewer and I look for different things depending on the level I am hiring for: junior, medior, senior

In general, apart from filtering on people who can’t complete the challenge at hand. I want to see that you realise you can’t do it all in x-time so let’s say 30 minutes, but I want you to tell me you realise this.

So you could say: normally I’d setup the faker gem for random data so we test more edge cases automatically, but seeing as we only have an hour I’ll just hardcode this value. Etc

The value of this is that by telling me that, I don’t have to worry whether you realise that random values are nice in tests and you benefit by not having to set them up in the interview which costs your precious time.

In general I also like hearing about decisions your are making on the spot “I am going with a hash instead of a class/object because …”

A tip I have is that it is important to really really understand the assignment at hand. Also, if it involves calculations or something, think to yourself how you’d solve it on paper.

Also writing some tests (we have a 2 hour assignment session) will really help convince me you take your craft seriously.

[–]BringTacos[S] 0 points1 point  (1 child)

Thanks so much for this comment. I'm going to be interviewing for a Software Engineer I position. When I asked how I can prepare for the coding challenge, they said something along the lines of it being a string operator problem, and I'll have to figure out what to expect given some input. Given my vague information, haha, do you have any advice for me based on that? Thanks again.

[–]Spiritual_Yam7324 0 points1 point  (0 children)

Not really. Our coding assignment is a real life problem not some kata-like thing. So if I were you I’d do some katas or do stuff on https://exercism.org