Hacker News Reader

Comment by kstrauser | Hacker News Reader

I had a job interview question: "In Python, write a class to implement a state machine."

Me: So, each instance should represent a state, and include a list of states it could transition to, and methods to transition to them? Is that what you had in mind?

Them: Well, if that's what you think a state machine is, then sure.

Me: There are a million ways I could implement this. What context will this be used in? I can make sure I write something that meets those requirements.

Them: Do you not know what a state machine is?

Me: Of course. But how are you planning to use it?

Them: I can't believe you don't know what a state machine is.

So as far as I can tell, I have no idea how to implement one.

(I'm so glad I didn't get that job.)

View on HN

You're overthinking it. The first reply was basically a "go ahead and do what you think is right".

They're probably glad they didn't hire you either.

The first reply is passive-aggressive and is inappropriate in the context of an interview (assuming that's word for word what has been said).

A better answer would be either "Yep sounds good to me" or something along the lines of "Let's step back and first define what a state machine should do".

Even if GP was not getting the job it is the responsibility of a good interviewer that GP leaves the room having learned something. If GP left this interview still not knowing what a state machine is (or what the interviewer thinks a state machine is) or no closer to an implementation of a state machine then the interviewer has failed as much as the candidate.

it is the responsibility of a good interviewer that GP leaves the room having learned something. If GP left this interview still not knowing what a state machine is (or what the interviewer thinks a state machine is) or no closer to an implementation of a state machine then the interviewer has failed as much as the candidate.

I strongly disagree. An interview is an assessment, not a tutorial.

I’m a staff-level engineer with thousands of LoC on GitHub, and many times that inside my employers’ repos. I know how to program. I wasn’t asking them to teach me what a state machine is or how to write one. Instead, I was trying to narrow down a thousand possibilities to the ones that would meet their requirements. You know, like I’d be doing on the job if they’d hired me.

When the CTO says “we need a thing”, I don’t sit down and start writing. I try to learn what we’ll need so I can build something that satisfies my stakeholders’ needs.

If I were interviewing you, and said “hey userbinator, make a paragraph”, and you did that without asking WTF I was talking about, the rest of the session may not go well.

Or they realized in that moment they didn't feel confident enough in their own understanding of state machines to critique anyone who might take the opportunity to cut them down to size. It is a stupid reaction to a sensible request for clarification, there are tons of equally valid ways to implement a state machine in an object oriented python script - especially when there are zero constraints on expected use. If I'd asked such a question, and got no sense of pushback, I'd be a little nervous about hiring that person and having them need close supervision - because they were to scared to point out ambiguity in direction.

there are tons of equally valid ways to implement a state machine in an object oriented python script

...and chances are that the interviewer would be fine with any of them, or ask questions after you've shown a solution.

If I'd asked such a question, and got no sense of pushback, I'd be a little nervous about hiring that person and having them need close supervision - because they were to scared to point out ambiguity in direction.

That's the exact opposite impression I have; someone who doesn't need to ask many questions, as long as they can justify their decisions well, is definitely more preferable to someone who constantly asks and needs to be lead every little step of the way.

the question was about a state machine. could there be a more general task to give a programmer? certainly no task would ever be assigned to them on the job that would be anywhere near that general.

questions like that don't show you how they'll be on the job, they're an opportunity to see their thought process, but you won't get that without talking to them.

> ...definitely more preferable to someone who constantly asks and needs to be lead every little step of the way.

Asking for clarification before starting isn't anywhere close to "needs to be lead every little step". If you are hiring a work crew for roadside ditch digging than your interview method might be a good idea, but for a job where implementation details matter - bad idea. One of my more difficult professional experiences was fighting the urge to displace blame for a wasted week of work, which would have been avoided had I asked for the tasking to be described back to me - or had he spoken up and said "Do you mean this or that?"

i'm not so sure the first reply was, "go ahead and do what you think is right", it could've just as easily been, "guess what i'm thinking." actually, their refusal to talk about what they were asking for makes it more probable that it was the second one.

they may be glad they didn't hire them, it's hard to say how they feel, but i bet they're one of those companies out their complaining they can't seem to hire anyone at any price.

That sounds to me as if the interviewer had said "write a program". It seems rather natural to ask "OK. What do you want the program to do? Shall I write a program that takes some input, and outputs it reversed? Would that do?", and they said "If that's what you think a program is, then sure."

At that point, it's probably best to stop arguing, and code. They probably want to argue with you about your code, not their spec.

But when I got the reply "Do you not know what a state machine is?", I think I might have thanked them for their time, and left. I would have been sorely tempted to come back with "Yes, a state machine is an abstraction, and you seem to want a concrete implementation, but you don't seem to want to fill in the details of your requirement. Is it a good use of our time together for me to complete your spec, so there's something for me to code up?"

It sounds like they didn't want you; perhaps your face didn't fit. They say most interviews are decided in the first couple of minutes.

I recently did an interview that went something like this too. The questions weren’t state machines. But like your experience, they boiled down to “I have some interesting experiences that feel kind of unique to me, is it possible you’ve had them too?” It was a mid level relatively seasoned person, but they admitted interviewing was kinda new. So it really came back to that “do you think we could experience a sort of cohort chemistry here” vetted by a pretty arbitrary set of “let’s find some geeky things to get connect about.” And like you, I’m not disappointed they chose to keep looking.

How to implement a state machine in Python:

    def next_state(state):
      if state == 90000:
        return 0
      return state + 1

But more seriously; once I was asked to implement offsetof in an interview for an entry level C++ position. I didn't quite remember that this was impossible during the heat of the interview, but I did remember enough to not produce an incorrect solution that relies on undefined behavior. I didn't get that job.

Expected them to hand you over a formal specification so you could develop their systems as well? Dear God...

Reply on news.ycombinator.com