Crazy Interviews

  • Comments posted to this topic are about the item Crazy Interviews

  • Is it a modern thing to require homework for an interview? In forty years in the software industry, the only interview that has asked me to prepare and present anything was the one for my current job. The interview was via Teams at the height of Covid lockdown and I put the effort in because I really wanted the job - right location, right industry, right skills... and it paid off. The fixed term contract has become permanent and the job has been enjoyable.

    Maybe it's a way of weeding out those who aren't serious about the role but those who want it will try to do their best at whatever is asked.

  • The last job application I undertook required 2 interviews and then, prior tor the 3rd interview I had  to prepare a 40 minute presentation based on high level and sparse requirements.  It took 3or 4 long evenings to write that 40 minute presentation!

    It was tough because they were looking for me to present as if they were a client.  Unfortunately they didn't specify that in the brief so everything I had prepared was as if I was presenting to them in their professional capacity and for the company they worked for.  A presentation you give to internal architects is very different to one you give to an external business client.  This torpedoed my presentation in the first 5 minutes and I was asked me to present as if I was presenting to personas.  The effect was that I was presenting on the fly.

    Needless to say I didn't get the position.

     

     

  • Heh... GETDATE(). 😀

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • I think it's a modern thing, especially for competitive companies in the tech world. I haven't ever had to prepare things, but testing and random questions haven't worked well, so I think this is an evolution of hiring.

  • I've been in my career for several years, so I've interviewed several times. I'm a software engineer. The interviews I've been in are all over the map. For example the interview I was in for my current position lasted only an hour. I was applying for a senior level position. The technical question they asked me was trivial. I did get the job and am still in it, but it didn't really test me to see what I was capable of doing.

    Some other jobs I've interviewed for were all day affairs. And I've had a few where I had to do a homework assignment. Those have always been hard.

    The interviews I've had which I don't like, are those which require you to NOT use any external resource, like Google or Bing, to check on something. That is so artificial. Who doesn't consult a search engine, or now a Gen AI chat app, to get an answer or check something?

    I've also sat in interviews where I was one of the interviewers. Most have been good, but some have been weird. For example, I've sat in two interviews where everyone knew who was going to get the job before anyone said anything. We were just going through the motions, because we had to.

    Looking back on my career and all the interviews I've sat in either as an interviewee or interviewer, I'd say that less than half of them have really been good. Good in the sense that I had a good feeling for how good the fit would be between myself or the job and company; or the candidate and the team, was going to be. I wish it were better. And I'll admit I don't really know how to make it better.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • Recruiting is expensive both timewise and monetary.  Coming up with a good recruitment methodology is an art as much as it is a science.  I've seen weak interviewees being star performers and star interviewees being poor performers.  That probably reveals something uncomfortable about us as interviewers.

    It boils down to an interview being a poor model of the real world job.

    I  think it helps if there are two interviewers with different personalities and perspectives on the candidate.

    If an interview went seriously off track we, as interviewers, had a bail out phrase that we used to signal to each other that we'd heard enough and didn't want to proceed. No point in wasting the candidates time or ours.

  • I'll agree with a lot of the above - interviewing others is somewhat of an art. I want to know how people think and what sort of personal learning/growth they do. I'll dig into topics they say they're "experts" in or are their strongest areas. I'll ask about projects they've done. But overall, if someone isn't growing in some way, I'll likely pass. I know some work environments don't really afford an opportunity for growth, but you should have some way of keeping up with your field of work to see what's coming that could be useful or affect the job.

    I will admit I start cutting things out of my "standard" questions as people show no real skill in an area. I will also note when candidates start making up answers, which is a _huge_ red flag for me. I'll usually ask something like "how does that work" or "tell me what you did next" in those cases just to make sure I wasn't misunderstanding something. Sadly, I'm usually not at that point.

    As for the "give a test" or "show some work" - I've seen that done a couple of times. We used to have a dev team that had a project to write some code against our public API, with links to a documentation site. The task was pretty straightforward - get the people, do an update, do an insert. Bonus points for anything above/beyond. Many candidates stopped at the "got a task" part. Some did some pretty good work to differentiate themselves. (They were hired and were great employees.)  We wanted something similar for db dev work, but that's really hard to do - as take-home or even in-office. I'm personally okay with what should be a short take-home assignment to show that you can write queries or such and use whatever resources you have. The key there being "short".

    I was in one interview and the interviewer dropped in a denormalized schema and before they even finished the scenario, my db dev hat went on and I was normalizing the design at a high level. (it was really basic, but was a good example of a way to handle that) Other times we've been asked to explain a backup/restore scenario or similar - high level. And a lot of that is to show that you've done those things. I've dug in a bit on automation scenarios or SSIS design or similar to see what people have done and what they know. Sometimes that leads to "well, I really just run a script someone else wrote" and other times it leads to "yeah, this is what I put together and how it works".

  • Nothing offers insight into the true culture of an organization like their recruitment process. If the interviews are informal and friendly,  and the questions are relevant and thought provoking, then your boss and coworkers will probably be that way too. However, if the interviews are uptight and stupid, then that will be your day to day experience on the job as well, assuming you accept the offer, which I would not.

    Has anyone ever had a crazy interview, accepted the job anyway due to circumstances or just higher pay, but then the job actually turned out to be great?

     

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Jeff Moden wrote:

    Heh... GETDATE(). 😀

    SELECT SYSDATETIMEOFFSET();

    🙂

  • jasona.work wrote:

    Jeff Moden wrote:

    Heh... GETDATE(). 😀

    SELECT SYSDATETIMEOFFSET();

    🙂

    exec xp_cmdshell('date /t')

     

  • Eric M Russell wrote:

    Nothing offers insight into the true culture of an organization like their recruitment process. If the interviews are informal and friendly,  and the questions are relevant and thought provoking, then your boss and coworkers will probably be that way too. However, if the interviews are uptight and stupid, then that will be your day to day experience on the job as well, assuming you accept the offer, which I would not.

    Has anyone ever had a crazy interview, accepted the job anyway due to circumstances or just higher pay, but then the job actually turned out to be great?

    well said

  • Also, this month's T-SQL Tuesday responses: https://twitter.com/hashtag/tsql2sday?src=hashtag_click

  • Steve Jones - SSC Editor wrote:

    jasona.work wrote:

    Jeff Moden wrote:

    Heh... GETDATE(). 😀

    SELECT SYSDATETIMEOFFSET();

    🙂

    exec xp_cmdshell('date /t')

    😛 It IS a great litmus strip test.

     

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

Viewing 14 posts - 1 through 13 (of 13 total)

You must be logged in to reply to this topic. Login to reply